(2013/01/02 05:24), Jim Finn wrote:
logconv.pl <http://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
On Jan 2, 2013, at 6:01 AM, Balaji P <bala...@juniper.net
<mailto:bala...@juniper.net>> wrote:
Hi All,
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.
Thanks in advance,
With Regards,
Balaji P.
--
389 users mailing list
389-users@lists.fedoraproject.org <mailto:us...@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users