Hi,
On Fri, 8 Nov 2013, richard lucassen wrote:
On Thu, 07 Nov 2013 06:51:40 -0800 Howard Chu hyc@symas.com wrote:
I wonder whether switching to back-mdb would be a better solution.
If the machine is 64 bit, yes absolutely. If the machine is 32 bit, depends on how large the DB can grow, since there's a 2-3GB limit on the address space.
Also while the main DB file would be 99% read-only, the lock.mdb file would not. In an application like this it's a good idea to symlink the lock.mdb file to a RAM filesystem/tmpfs.
Let me put things more clear: it is a 32 bit Ubuntu-8.04 (yes I know, very old) with this version:
2.4.9-0ubuntu0.8.04.5
There is a master and two slaves. I prefer not to upgrade for some non-ldap reasons. All config is AFAIK in slapd.conf, there is no slapd.d directory. The database contains *tens* of entries, when I open the database with ldapvi I find 93 entries. IOW: this is a very very small database.
Let me put it this way:
The only files that are regularly altered are these files:
__db.001 __db.002 __db.004
What happens if I symlink these files to a RAMDISK? And what happens after a reboot or power outage? Do I get a corrupted database?
as others have said before configuring a shm_id would prevent those files from being generated in the first place as berkeley db locks, cache and such would then be in sys v shared memory and not in file backed shared memory.
Greetings Christian