[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: slapd memory and performance problems
I'm thinking now after reading yours and Matthew Backes' explanation of
memory utilization, and also since doubling the server RAM this morning
to 1GB and discovering that the performance problem still exists, that
this is not a memory problem but some other issue for which I yet have
no explanation. CPU utilization is very low. Disk writes are numerous
to the var partition where the ldap log file and the openldap database
are, but reads to that partition are very low. So am I correct in
assuming that much data is cached (thus the high memory utilization by
the threads)? Then might the problem lie in the network connections? I
am currently seeing right around 100 connections, most in TIME_WAIT. Is
this something that could be corrected, at least in part, by unix
sockets (ldapi:// url)? If so, can you point me to docs describing its
use?
Quanah, in another response to this thread suggested the possibility of
RedHat threading issues. Have you or anyone else run into any problems
with RedHat's threading implementation?
Thanks,
Mike
-----Original Message-----
From: Howard Chu [mailto:hyc@highlandsun.com]
Sent: Tuesday, April 01, 2003 6:31 PM
To: 'Mike Denka'; OpenLDAP-software@OpenLDAP.org
Subject: RE: slapd memory and performance problems
> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Mike Denka
> After experimenting with threads (max number and idletimeout),
upgrading
> to v.2.1.16 and applying Howard's new cvs version of tpool.c, I am
still
> experiencing some performance issues with slapd. The most immediate
> problem I see is that the response time for a query under peak loads
is
> very slow. The most obvious oddity is that the slapd threads are
> growing in size over time.
> Upon starting slapd, each thread has a size of about 4800KB. This
> thread size seems to double after 8 hours or so and grows to about
15M.
> Also, the total memory available on the box seems to degrade over
time,
> not just from the increased thread size, but from what appears to be a
> memory leak somewhere since just restarting slapd does not increase
the
> available amount of system memory. Only a reboot recovers system RAM.
If the system memory is not recovered after the slapd process has been
killed, then clearly the problem is not in slapd itself. If this is
truly the
situation, then your kernel has a leak, and there's nothing we can do
about
this. However, before arriving at this conclusion, bear in mind that
memory
consumed by the filesystem buffer cache generally remains in use, but
will
flush out as the system needs more for other purposes. So, programs like
top
may show very little free memory, but in fact there's some amount still
available on demand.
> I'm running RedHat 8.0 on a platform with an Intel 1G processor and
> 512MB of RAM. Processor idle time never dips below 90%, no swap space
> is ever used but memory, as I said, diminishes over time. However,
> performance stays constant and doesn't change as memory degrades
(until
> memory drops to below 5M or so, at which time the server must be
> rebooted).
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support