[Date Prev][Date Next]
openLDAP tuning: do large values of dbcachesize pose a problem
I'm currently doing tons of tests on Netscape vs openLDAP, and
one thing I ran into was that Netscape configures their
dbcachesize default value to be 10000000 (whereas openLDAP's
default is 100000). I've tried various things to make for a
"somewhat fair" test, tuning Netscape down to openLDAP (doesn't
work since Netscape will automatically upgrade 100000 to 500000)
and now I am trying upgrading openLDAP to netscapes level....
Somewhat bizarrely enough during the openLDAP test openLDAP
crashed and burned (so dramatically that it corrupted the db...)
and I wonder if enlarging the dbcachesize so much might have
caused the problem. Also is this cache setting used by slurpd
too- I ask because slurpd seemed to be holding on to 54 Megs of
ram after I loaded a master (with ldapmodify) with 100,000
entries and it pushed 50,000 over to the slave (the replication
seemed to be ok, but I would have thought that at the end of it
all slurpd would release its memory).
Also I still don't have an answer on how people bridge between
another DB and LDAP (where one wants data to dynamically be
pushed from another DB into the master LDAP server, but one is
not looking to change LDAP's back end database). I was thinking
of running a slurpd that would read a "changelog" that the other
DB would generate on the fly. This way changes would be
automatic, dynamic, and there would be a built in way to monitor
the progress (reject logs...). Is this a reasonable solution?
Is there something better?