From: 389-users-bounces(a)lists.fedoraproject.org [mailto:389-users-
bounces(a)lists.fedoraproject.org] 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(a)lists.fedoraproject.org [mailto:389-users-
>> bounces(a)lists.fedoraproject.org] 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:
>>> 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 ;
> 0.5; done
> Watching the performance figures in the console does not highlight any
> 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
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.
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.