Hello, Monday is nearly over here and neither today nor over the weekend any corruption or inconsistencies were observed (and I checked each record that was modified in the last 3 days).
So using BDB instead of LDBM indeed seems to have fixed things for me. I guess the choice as far as the Debian package is concerned is now to either get a working LDBM backend from upstream or forcibly migrate users away from LDBM when Sarge hits the limelight... Even with the default 256KB cache of BDB things worked quite well and db_stat -m showed pretty nice cache hit rates. For the record and in case somebody wants to use this data, my DB_CONFIG now reads like this (after many tests on my test server): --- set_cachesize 0 134217728 1 set_flags DB_LOG_AUTOREMOVE set_flags DB_TXN_NOSYNC --- Yes, these servers have 2GB RAM and so I was very generous with the cache. It helps quite a bit, that alone made full load with ldapadd 6 times faster. The DB_TXN_NOSYNC speeds that up another 8 times, so instead of 53 minutes it takes 1 minute to load the entire LDIF. Inserting it with slapcat -q now takes 22 seconds, I'm reminded of the god ole ldif2ldbm days. I know that DB_LOG_AUTOREMOVE doesn't work the way it should for the moment, but here's hoping for the future. ;) I'm unsure about DB_TXN_NOSYNC in production, basically only writing out changes when the server gets shut down is somewhat hair raising. OTOH it speeds up things and I never had either slapd or the whole server crash. In which case I could create a good instance in the 22 seconds mentioned up there. Regards, Christian Balzer -- Christian Balzer Network/Systems Engineer NOC [EMAIL PROTECTED] Global OnLine Japan/Fusion Network Services http://www.gol.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
