> 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
to crash?
I used slapcat without -l for two reasons:
usually i slapcat pipiing in gzip the stdout so i can realtime gzip
the ldif:
slapcat -f slapd.conf | gzip > out.ldif.gz
and also because on 32 bit slapcat, avoid the 2GB filsize limit on
output ldif
> slapcat -f slapd.conf
here the full command was:
slapcat -f slapd.conf > fulldump.ldif
However, I've retry with "-l file" on 32 bit linux and solaris (why
not ?)
Linux stops when reached 2GB file out; but there was a little bit of
memory available and the allocation rate was similar to previous trials
In Solaris, due to speed up the test I've ulimit -d 1024000, reached
2 GB file without stops itself (usually solaris continues, simply
throws out additional data)
then some time later:
ch_malloc of 16392 bytes failed
ch_malloc.c:57: failed assertion `0'
Abort (core dumped)
with a while/loop ps, last line was:
PID RSS VSZ %MEM TIME STIME COMMAND
18246 1652488 1656144 41.1 31:23 09:22:35 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
84M cn.bdb
618M dn2id.bdb
85M employeeNumber.bdb
3.2G id2entry.bdb
3.7M objectClass.bdb
85M uid.bdb
this runs I've tried a db like:
ldap@labsLDAP:/TEST_producer/openldap-data> du -h *.bdb
3,0M testCode.bdb
2,9G dn2id.bdb
600M entryCSN.bdb
545M entryUUID.bdb
15G id2entry.bdb
1,9M objectClass.bdb
270M testId.bdb
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.
In my trials, instead, allocation never stops :(
Perhaps due to a greater DB ?
Paolo