On 11/24/2010 07:36 AM, Gerrard Geldenhuis wrote: > Interesting statistics when running ldclt... > > On the problematic server I see: > ldclt[16390]: Average rate: 7.10/thr ( 7.10/sec), total: 71 > ldclt[16390]: Average rate: 6.80/thr ( 6.80/sec), total: 68 > ldclt[16390]: Average rate: 6.90/thr ( 6.90/sec), total: 69 > ldclt[16390]: Average rate: 7.00/thr ( 7.00/sec), total: 70 > > and on the functioning server I see: > ldclt[16420]: Average rate: 1397.00/thr (1397.00/sec), total: 13970 > ldclt[16420]: Average rate: 1336.70/thr (1336.70/sec), total: 13367 > ldclt[16420]: Average rate: 1387.20/thr (1387.20/sec), total: 13872 > ldclt[16420]: Average rate: 1387.80/thr (1387.80/sec), total: 13878 > ldclt[16420]: Average rate: 1332.70/thr (1332.70/sec), total: 13327 > > > clearly one server is much more capable than the other.... what could be the cause of that? I don't know. > They both have identical hardware and were configured identical as far as I am aware. Then there must be some difference you are not aware of. > Regards > >> -----Original Message----- >> From: 389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx [mailto:389-users- >> bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Gerrard Geldenhuis >> Sent: 24 November 2010 14:09 >> To: 'General discussion list for the 389 Directory server project.' >> Subject: Re: [389-users] Slow response from server >> >>> -----Original Message----- >>> From: 389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx [mailto:389-users- >>> bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Rich Megginson >>> Sent: 12 November 2010 18:45 >>> To: General discussion list for the 389 Directory server project. >>> Subject: Re: [389-users] Slow response from server >>> >>> Gerrard Geldenhuis wrote: >>>>> -----Original Message----- >>>>> From: 389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx [mailto:389-users- >>>>> bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Rich Megginson >>>>> Sent: 12 November 2010 16:32 >>>>> To: General discussion list for the 389 Directory server project. >>>>> Subject: Re: [389-users] Slow response from server >>>>> >>>>> Gerrard Geldenhuis wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> We are getting a slow responses from one of our LDAP servers and I >>>>>> am not sure what is causing the problem I have run a logconv.pl -j >>>>>> and the following is interesting: >>>>>> >>>>>> >>>> > >>>> >>>>>> Connections Reset By Peer: 0 >>>>>> >>>>>> Resource Unavailable: 136 >>>>>> >>>>>> - 136 (T1) Idle Timeout Exceeded >>>>>> >>>>>> >>>>> does logconv.pl -V show anything like unindexed searches, admin >>>>> limit exceeded, long operation times? >>>>> >>>>>> >>>> No admin limit exceeded or long operation times. >>>> >>>> Stricly spoken we don't have unindexed searches but my test bash >>>> script >>> caused quite a number of. We are seeing random timeouts to this >>> specific server when doing a search like the following: >>>> while true ; do ldapsearch -h ldapserver.company -ZZ -x -W -D >>>> "uid=johndoe,ou=people,dc=company" -b "dc=company" -L -y pwd ; >> sleep >>>> 0.5; done >>>> >>>> Watching the performance figures in the console does not highlight >>>> any >>> specific problems. >>>> I am fairly certain that it is an internal network issue but I need >>>> to have >>> proof which is why we are currently doing tcpdumps. >>> You're using TLS - if you remove the -ZZ, do you still have the same >>> problem? >> We are seeing the same problem with or without TLS based searches. At the >> moment I am not seeing the error... >> There is no retransmits or packets errors so most likely not a networking >> issue. I have compared the config between this non-working server and >> another working server and there is very little difference between them. >> The normal timestamp change differences and order of some entries but >> nothing else. >> >> Any suggestions on where to look next...? >> >> To refresh what the thread was about. We are seeing timeouts against a 389 >> server on occasion when doing a very simple bind. The servers is a provider >> server with chaining configured. Password policy is configured to be global. >> >> Regards >> >> >> >> ___________________________________________________________________ >> _____ >> In order to protect our email recipients, Betfair Group use SkyScan from >> MessageLabs to scan all Incoming and Outgoing mail for viruses. >> >> ___________________________________________________________________ >> _____ >> -- >> 389 users mailing list >> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >> https://admin.fedoraproject.org/mailman/listinfo/389-users > ________________________________________________________________________ > In order to protect our email recipients, Betfair Group use SkyScan from > MessageLabs to scan all Incoming and Outgoing mail for viruses. > > ________________________________________________________________________ > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
