On Jan 2, 2008 6:59 PM, Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: > > > --On January 2, 2008 5:14:25 PM -0500 Sam Tran <[EMAIL PROTECTED]> wrote: > > > Dear All, > > > > We are running OL 2.3.39 on Centos 5 i386 or x86_64. We have one > > provider and three consumers (LDAP-sync repl). > > > > Several applications perform LDAP write and read operations on the > > provider. > > > > For the second time in 2 months, we had what it looked like a file > > descriptor leak on the provider: file descriptors were not closed at > > all or fast enough. At the same time, slapd was unresponsive. Here is > > what the logs shows: > > > > I restarted slapd, which fixed the problem. > > > > The first time that problem occurred, slapd ran out of file descriptor. > > I don't know what triggered the problem. Prior to the problem there > > was no increase in load, all LDAP operations were performed > > successfully. > > > > I would appreciate it if anyone could give me some pointers on how to > > troubleshoot the problem. > > I don't see any issue here -- Every connection takes a file descriptor. > Most of the things opening connections aren't being closed in the log > snippet you show, so they hold onto the resource. The connections that it > does show closed, the fd is freed, and then the next incoming connection > uses it. I.e., no evidence of a leak. One of the first things I always do > with my LDAP servers is to bump up the number of file descriptors available > to slapd (usually to 16k on 64-bit boxes). Many things uses persistent > connections, which uses up file descriptors. You could also implement a > harsh idletimeout (like idletimeout of 5 seconds) to kick off idle > persistent connections. How well clients handle that is variable though. >
Quanah, Thanks for the input. However this does not explain why slapd was hanging and unable to respond to any queries before the number of open file descriptors reached its maximum. -- Sam
