[Date Prev][Date Next]
Re: File descriptor leak, slapd hangs and runs out of file descriptor
--On January 2, 2008 5:14:25 PM -0500 Sam Tran <firstname.lastname@example.org> wrote:
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
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
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.
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration