PS: During the first search, the disk is heavy used (iotop) by writing from slapd.conf ... why it - should only read ...?
This does not make sense. slapd should not *write* to slapd.conf.
Soryy, the correct sentence is: "During the first search, the disk is heavy used (seen with iotop) by writing from slapd, why - it should only read ...?" I apologizes for this mistake!
You should probably learn how to use strace to find out what really happens on your system.
I also used strace to catch the problem, but i did not find where the slapd write to disk. It seems, it comes via set up the futex write locks? I'm not a kernel programmer and the code from openldap is hard to read. But strace I use for several years to find errors, it was also the first choice for me, to find the error. It is not a normal file that will be written...
This behavior can be reproduce:
=> Large Database (eg. 500.000 objects/DN's) => put the one (same) Objectclass to >100.000 objects/DNs => turn of logging => start iotop (+ hit "o") => search for this objectclass and look what will happen during the first search with your disk
You should also install the same LDAP database and the same config on another physical server to see whether it behaves equally there.
I checked this problem on several machines, openldap versions (2.4.11, 2.4.21, 2.4.23) and Distribution (Debian 5, and Opensuse 11.1 and 11.3)
I investigated a lot time till now to find the error, but nothing helped ...
Good luck with your troubleshooting,
Thanks