[Date Prev][Date Next]
Re: slapd memory and performance problems
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.
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
This sounds very very strange. Since your problem persists after
halting the process, it is clearly not related to slapd itself. I'll
discuss this though as I suspect other people may encounter this
problem when tuning their systems, linux or not.
How are you measuring the remaining memory? There is "Free" memory,
"Cached" memory, "Used" memory, and on some kernel versions, "shared."
(2.4 doesn't count shared correctly as it takes too long)
"Free" memory really only means Wasted memory, and ideally this number
should be as Low as possible. On a healthy system it will only be
large at boot or after a massive process has just exited. Free memory
does not include swap; it's just the amount of RAM not being used for
anything at all.
Available physical memory touching the filesystem causes disk pages to
be copied to otherwise Free pages. These are then known as Cached
memory. Future disk reads and writes go to that Cached memory instead
of disk. This is generally a large performance improvement.
If a process starts requesting memory, the kernel first pulls from Free
pages, then starts tossing out cache in order to make room. "Cached"
memory should therefore be considered as Available ram that is
currently being borrowed to improve I/O performance. (but is still
available should a process need it)
If this explanation was beneath you, then I humbly apologize. I
provide it as I've seen many, Many people get confused about this and
think their (otherwise healthy) servers were out of ram.
As for swap, it is normal for the kernel to page unused "Used" memory
out to swap to improve the space available for caching.
You said the processes grew to 15MB in size. Even if you forced the
old default of 32 threads, that yields something significantly less
than the 512MB of ram available to your machine. If you have enough
swap to push the other unused daemons out of the way and you tune your
database layer correctly (heh), then this should be workable. If you
plan on using the server heavily for anything else at the same time
though, you will probably want to adjust entry caching and the
DB_CONFIG so that slapd consumes no more than half of physical memory
or you'll be battling the swapper. A dedicated directory server will
let you get away with far more outrageous abuses of the vm system,
You said no swap was being used. That would be extremely abnormal for
the conditions you describe. How much swap do you have configured?
What kernel release?
You say free memory keeps diminishing and is not fully returned when
the process exits. This Really sounds like Free ram getting replaced
by Cached pages. How are you determining that a reboot is necessary?
I.e., what happens if you don't? What does the output of vmstat 1 10
look like during these conditions?
Having 5MB "Free" would be normal for a system with that amount of ram.
(And this scales fairly linearly; our 2GB servers generally have 20MB