On 05/23/2012 10:27 AM, Russell Beall wrote:
I've been doing a lot more testing to try to flesh out the issue here.
I upgraded to the latest stable version from the rmeggins repo, but
found the same memory growth behavior in that instance.
I have a few more details which clarify much better what I'm experiencing.
Unbounded memory growth for an endless chain of ldapmodify operations
is seen in both cases where the cache size limit is reached as well as
when the maximum cache size is well above the total data size of all
entries and all entries are loaded.
But based on what you say later in the post, it's not unbounded, it's
just not bounded by what you set as the cache size?
On the contrary, when I reduce the cachememsize to nothing, (which
then is reset for me to the minimum value of 512000), I see no memory
growth at all, and the only memory consumed is just slightly larger
than the DB cache size set.
I found that I can use some cache and still get a stable configuration
by setting a cache size of only 3GB, and then the memory usage reaches
a plateau of 24G (including a DB cache size that I don't remember).
A similar ratio is seen when setting a cachememsize of 1GB. The
server starts out grabbing 4GB (including the 2GB of DB cache I set),
and then grows to 9GB and then goes up and down between 8 and 9 GB
It seems that the server believes it can have an in-memory workspace
equivalent to (6 * cachememsize), and this behavior seems directly
linked to the cache management code.
I need to be able to set my server to use cachememsize=12GB or more,
but I can't have the server believing it then has a right to 72GB of
working memory. With 12GB set, the server quickly eats up the 32GB
RAM, and goes well into the 16GB of swap before finally crashing.
Is this something I should just go ahead and file as a bug?
Programmer Analyst IV
Enterprise Identity Management
University of Southern California
On Apr 24, 2012, at 6:53 AM, Rich Megginson wrote:
> The thing in common is this - when the cache usage hits the cache max
> size, you see unbounded memory growth.
389 users mailing list