On Tue, Nov 1, 2011 at 6:43 PM, Howard Chu <hyc@symas.com> wrote:
Meike Stone wrote:

time ago, we installed a Linux Guest with OpenLDAP (db size appox.
650MByte / ) server in a ESXi environment.
Maybe because of a read/write ratio 100:1, the hard discs where heavy
used by writing bdb backends memory mapped files.
The CPU in that Linux system had iowait (top) between 80% and 100% and
the other VMs on the ESXi went slow down.

After changing to shared memory (shm_key), all problems with disc IO where gone.

I read in the mailing list and on "OpenLDAP performance tuning" guide,
that it does not matter if using memory mapped files or shared memory
until the database is over 8GB. But why we had such problems?

Please note, the OpenLDAP was operating very fast with the memory
mapped files, because of using indexes and proper caching.

Now, I want install more than one OpenLDAP server on one Linux system
(now real Hardware).
Every OpenLDAP server will be bind on a separate IP and DNS host name.

So in this scenario it is hard to calculate the shared memory and
assign each LDAP server to the right shared memory region (key).

?? Just pick some key numbers that are spread out "enough" to not overlap. 10, 20, 30, 40, etc.

Therefore I want go back to memory mapped files. Are there any
recommendation for sizing the Linux system like:
 - type of file system (ext3, ext4, xfs, ..)
 - parameters of file system (syncing ->  commit=nrsec, data=*, ... )
 - swap using (swappiness, dirty_background_ratio)
 - ???

Probably the most important setting is to mount with noatime or relatime.

Disabling write barrier is a big win and ext4 or perhaps xfs is a good choice (http://www.ep.ph.bham.ac.uk/general/support/raid/raidperf11.html).

 -- Howard Chu
 CTO, Symas Corp.           http://www.symas.com
 Director, Highland Sun     http://highlandsun.com/hyc/
 Chief Architect, OpenLDAP  http://www.openldap.org/project/