Hi Noriko,
Thanks for your response.
We are using index based search operation which is poll the directory for a specific sub tree and check if there were updates within the interval of the last
update vs. current timestamp.
Also we are thinking out of system resources may cause this problem.
Thanks,
Balaji P
From: 389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx [mailto:389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx]
On Behalf Of Noriko Hosoi
Sent: Wednesday, January 02, 2013 11:28 PM
To: 389-users@xxxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [389-users] Search operation takes too much time for respond
(2013/01/02 05:24), Jim Finn wrote:
logconv.pl is your friend.
What is the filter & attributes you are searching? Are they indexed?
Right. If you see "notes=U" in the slow search result (access log), the slowness could be coming from there.
conn=65 op=1 RESULT err=0 tag=101 nentries=1 etime=0 notes=U
Also, there is a known issue in the range search.
https://fedorahosted.org/389/ticket/537
To work around the problem, we introduced a new config parameter nsslapd-rangelookthroughlimit, which is available on 389-ds-base-1.2.11.17 or newer.
Thanks,
--noriko
We are using 389 LDAP server which is having around <1000 objects. We have a control script which is running as a separate process to perform the search operation in the
particular DN.. From the access log around 98% Percentage the search operation estimation timeout value as 0 second. The remaining 2% percentage we got different estimation timeout values like (1-18) seconds. We did n’t observe any log error message in log
file. Also we have some other java process running on the same machine.
Any idea what could be possible reason for search operation taking more time? And how to debug this issue.
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
