[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: openldap versions and silent exit

Kirk,
	I do look at the memory usage of the slapd process quite regularly and I haven't noticed it growing excessively.  Actually, our new LDAP DB is smaller than our old one and that one ran for months without problems on RedHat 9.  Currently I'm seeing 57M of memory in use for slapd on the system which receives the majority of the LDAP traffic.  How big were your processes growing?  I've compiled all of the dependent libs myself as well (OpenSSL and BDB).

Thanks!

Jamey



-----Original Message-----
From: Kirk Turner-Rustin [mailto:ktrustin@owu.edu]
Sent: Wednesday, August 11, 2004 6:07 AM
To: James Courtney
Cc: Open LDAP Software List (E-mail)
Subject: Re: openldap versions and silent exit


On Tue, 10 Aug 2004, James Courtney wrote:

> I just wanted to ask my question again about anyone seeing
> OpenLDAP 2.1.25 backed by BDB 4.2.52 on RedHat 3 ES (or some similar
> combination) silently dying under load.  My thread and conn_max*
> settings are the defaults.  I'm going to mine my logs a bit to
> see how many nearly concurrent requests the server is seeing when
> it passes away as I know that I get spikes of requests (maildrop
> delivering to a distribution list).  I suppose these *COULD*
> maybe exceed some internal capacity of slapd (surely not the
> conn_max_pending_auth of 1000 though) and result in some misfortune.

Are you monitoring the size of slapd in memory?

We are running OL 2.1.25 + BDB 4.2.52 with back_bdb and simple
bind only (no SASL or Kerberos) under RedHat Linux 9 (soon to be
migrated to RHES 3.1). In our setup, conducting searches against
the directory causes slapd to increase its use of RAM without
ever releasing it back to the operating system. In this context,
I've observed that if slapd isn't monitored (e.g., via cron) and
restarted when it gets too large, then it just quits.

Under test conditions, I've compiled OL and the major dependent libs
(OpenSSL, Cyrus SASL, BDB) from scratch, eliminating the RedHat MIT
Kerberos libs, which are known to have problems, but I get the same
result. I've replicated this with OL 2.1.30 also. I believe that
it's a leaky RedHat library among the ones that I haven't built
from scratch; no one (that I'm aware of) running OL on any other
platform has reported this issue.  Fortunately, our data store
is small compared to others', and the rate of growth under our
use conditions generally requires restarting only once or twice
a week. (I haven't tried to isolate the leaky library since our
running platform is a moving target.)

-- 
Kirk Turner-Rustin
Programmer/Analyst
Libraries and Information Services
Ohio Wesleyan University
http://www.owu.edu