Le 7 nov. 2013 à 12:04, "richard lucassen" <mailinglists(a)lucassen.org&gt; a écrit : Hello list, I want to migrate some OpenLDAP servers from 3.5" disks to CF-disks. The data in the OpenLDAP is only updated once a month or so. It is just an "99%-read-only" LDAP implementation. However, with a standard Debian install, some files in the /var/lib/ldap directory are updated upon each query: # ls -altr -rw-r--r-- 1 openldap openldap 96 2008-11-19 11:45 DB_CONFIG drwxr-xr-x 28 root root 4096 2008-12-03 15:03 .. -rw------- 1 openldap openldap 8192 2013-04-08 10:50 cn.bdb -rw------- 1 openldap openldap 24576 2013-09-29 13:49 objectClass.bdb -rw------- 1 openldap openldap 180224 2013-09-29 13:49 id2entry.bdb -rw------- 1 openldap openldap 8192 2013-09-29 13:49 entryUUID.bdb -rw------- 1 openldap openldap 8192 2013-09-29 13:49 entryCSN.bdb -rw------- 1 openldap openldap 36864 2013-09-29 13:49 dn2id.bdb -rw------- 1 openldap openldap 1168654 2013-10-17 09:40 log.0000000001 -rw------- 1 openldap openldap 24576 2013-11-07 05:45 __db.005 -rw------- 1 openldap openldap 98304 2013-11-07 05:45 __db.003 -rw-r--r-- 1 openldap openldap 4096 2013-11-07 05:45 alock drwx------ 2 openldap openldap 4096 2013-11-07 05:45 accesslog drwx------ 3 openldap openldap 4096 2013-11-07 05:45 . -rw------- 1 openldap openldap 565248 2013-11-07 11:30 __db.004 -rw------- 1 openldap openldap 2629632 2013-11-07 11:30 __db.002 -rw------- 1 openldap openldap 8192 2013-11-07 11:30 __db.001 Apparently the cluster is doing some synchronizing at 05:45 in the morning, but that's once a day. My concern is the files called __db.001 __db.002 __db.004 Is there a simple way to prevent OpenLDAP from updating these files at each query? R. -- ___________________________________________________________________ It is better to remain silent and be thought a fool, than to speak aloud and remove all doubt. +------------------------------------------------------------------+ | Richard Lucassen, Utrecht | +------------------------------------------------------------------+

"Maucci, Cyrille" <cyrille.maucci(a)hp.com&gt; wrote: > You should be specifying shm-key to benefit from shared mem vs memory mapped > files I wonder whether switching to back-mdb would be a better solution.

Ciao, Michael. >> Le 7 nov. 2013 à 12:04, "richard lucassen" <mailinglists(a)lucassen.org&gt; a >> écrit : >> Hello list, >> >> I want to migrate some OpenLDAP servers from 3.5" disks to CF-disks. >> The data in the OpenLDAP is only updated once a month or so. It is just >> an "99%-read-only" LDAP implementation. >> >> However, with a standard Debian install, some files in >> the /var/lib/ldap directory are updated upon each query: >> >> # ls -altr >> -rw-r--r-- 1 openldap openldap 96 2008-11-19 11:45 DB_CONFIG >> drwxr-xr-x 28 root root 4096 2008-12-03 15:03 .. >> -rw------- 1 openldap openldap 8192 2013-04-08 10:50 cn.bdb >> -rw------- 1 openldap openldap 24576 2013-09-29 13:49 objectClass.bdb >> -rw------- 1 openldap openldap 180224 2013-09-29 13:49 id2entry.bdb >> -rw------- 1 openldap openldap 8192 2013-09-29 13:49 entryUUID.bdb >> -rw------- 1 openldap openldap 8192 2013-09-29 13:49 entryCSN.bdb >> -rw------- 1 openldap openldap 36864 2013-09-29 13:49 dn2id.bdb >> -rw------- 1 openldap openldap 1168654 2013-10-17 09:40 log.0000000001 >> -rw------- 1 openldap openldap 24576 2013-11-07 05:45 __db.005 >> -rw------- 1 openldap openldap 98304 2013-11-07 05:45 __db.003 >> -rw-r--r-- 1 openldap openldap 4096 2013-11-07 05:45 alock >> drwx------ 2 openldap openldap 4096 2013-11-07 05:45 accesslog >> drwx------ 3 openldap openldap 4096 2013-11-07 05:45 . >> -rw------- 1 openldap openldap 565248 2013-11-07 11:30 __db.004 >> -rw------- 1 openldap openldap 2629632 2013-11-07 11:30 __db.002 >> -rw------- 1 openldap openldap 8192 2013-11-07 11:30 __db.001 >> >> Apparently the cluster is doing some synchronizing at 05:45 in the >> morning, but that's once a day. My concern is the files called >> >> __db.001 >> __db.002 >> __db.004 >> >> Is there a simple way to prevent OpenLDAP from updating these files at >> each query? >> >> R.

> 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.

> 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.

> 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.

set following in slapd.conf shm_key 100