[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: slapd hangs doing large ldap (add|modify|delete)
There's a lot of good advice here. Just a couple notes...
Buchan Milne wrote:
If this is your level of experience with OpenLDAP, I would also
hesitate. Please review all the relevant sections of the FAQ-o-matic, at
minimum:
- -do some DB_CONFIG tuning
- -set up OpenLDAP caching (cachesize, idlcachesize)
- -set up checkpointing, and consider running db_checkpoint (the correct
version) as the user slapd is running as via cron or similar
The use of db_checkpoint is unnecessary in OpenLDAP 2.3, an internal
task will handle this automatically.
- -ensure database recovery will run if ever slapd dies unexpectedly
(power failure, hardware failure, OS failure, PECKAC)
OpenLDAP 2.3 will perform recovery automatically; external startup
scripts should not do anything here. For catastrophic failure, the
automatic recovery will probably fail, but it would have required manual
intervention regardless.
- -deal with your transaction logs sanely
This may require patching BerkeleyDB to get "sane" behavior.
- -ensure you have some sane means of backups of your data in LDAP (either
snapshots of the database and transaction logs, or slapcat the data as
the user slapd runs as via cron or similar).
slapcat in OpenLDAP 2.2.27 was fixed to prevent any
writes/flushes/checkpoints from occurring. As such, it no longer makes
any difference what user you run as, it will not accidentally change the
ownership of any database files. (In older releases, slapcat performed a
checkpoint before closing the database environment. If slapcat was
running as root, and the checkpoint caused a new log file to be created,
it would be created/owned by root, and other processes would be unable
to write to the log. This was ITS#3703.)
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/