(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 <balajip(a)juniper.net
<mailto:balajip@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(a)lists.fedoraproject.org <mailto:users@lists.fedoraproject.org>
>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users