[Date Prev][Date Next]
Re: (ITS#4702) out-of-memory on huge DB ?
--On Friday, October 13, 2006 1:57 PM +0000 Paolo.Rossi.firstname.lastname@example.org wrote:
>> No. As I already mentioned, there is no reason for slapcat to use
>> large amounts of RAM, it should use whatever size your BDB cache is
>> configured for and that's about it. It's possible there is a memory
>> leak, but since no such leak appears under Linux that would point
>> to either the Solaris C library or some other library specific to
>> your platform.
> Today I've finished a cross test on a suse 10.0 linux
> Athlon XP 2200+ 768MB RAM + 1GB swap
> loaded huge db with same config, shared mem and set_cachesize 0
> 384000000 1
> slapcat -f slapd.conf
So you understand that without the -l flag to slapcat, you are writing to
stdout instead of a file? Is it possible that is what is causing slapcat
On my linux 2.6 system (64 bit), with a 2.5 million entry db, which is:
ldap00:/var/lib/ldap/slamd/64-2.5mil-db42# du -h *.bdb
set_cachesize 0 384000000 1
# Automatically remove log files that are no longer needed.
# Setting set_tas_spins reduces resource contention from multiple clients
on systems with multiple CPU's.
Using slapcat -l ldif_file, I then ran a while (1) loop to check the OSS
and RSS sizes of slapcat. It reached the following size fairly quickly:
and then never grew past that. This means the resident memory maxed out at
1.1 GB, and the virtual memory maxed out at 1.1GB as well.
So, that does mean one thing -- It definitely outgrew the 366MB of BDB
cache defined. On the other hand, once it reached its max size, it stayed
steady there until completion was reached.
Principal Software Developer
ITS/Shared Application Services
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html