In that case, strace/ltrace/dtrace/etc. on the slapd process will show you what the process itself is doing.
On Sat, Oct 29, 2011 at 08:22:38PM +0800, Adam Wale wrote: > iotop shows me that the slapd process is doing the writing, I'm trying to > identify what exactly it's writing, and if there's a way I can prevent it > > ________________________________________ > From: [email protected] > [[email protected]] On Behalf Of Christopher Wood > [[email protected]] > Sent: Saturday, 29 October 2011 11:30 AM > To: [email protected] > Subject: Re: Searches causing disk writes > > Perhaps use iotop while you do a big search? > > On Sat, Oct 29, 2011 at 11:11:44AM +0800, Adam Wale wrote: > > Hi, > > > > Thanks for the response, unfortunately we are already using loglevel 0, and > > are not using slapd -d. > > > > ________________________________________ > > From: Hallvard Breien Furuseth [[email protected]] > > Sent: Saturday, 29 October 2011 8:47 AM > > To: Adam Wale > > Cc: [email protected] > > Subject: Re: Searches causing disk writes > > > > Adam Wale writes: > > > I'm observing an issue where a large number of searches against an > > > openldap server results in a large amount of disk writes occurring. > > > > Maybe you have set a high loglevel in slapd.conf, or you are using the > > slapd '-d' argument. > > > > Loglevel is what gets logged to syslog. Default logevel is 'stats' > > (256), which gives a few lines per LDAP request. Some years ago our > > site had to set loglevel=0 because it could not handle all the > > syslogging, but a hardware upgrade fixed that. Default syslog > > user.level=local4.debug, see man slapd. > > > > > The hosts have plenty of free RAM and are not using any swap. I have > > > disabled the monitor backend but haven't seen much of an improvement > > > by doing this, given the monitor database is instantiated at startup > > > is this stored in memory? (if not, why not make that an option?) > > > > Yes, monitor is memory-only. > > > > -- > > Hallvard > > > > > > >
