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? They both have identical hardware and were configured identical as far as I am aware. 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
