[Date Prev][Date Next]
RE: Searches causing disk writes
For anyone that was interested in the fix for this, moving to shared memory resolved the issue.
From: Philip Guenther [mailto:email@example.com]
Sent: Sunday, 30 October 2011 4:06 AM
To: Christopher Wood; Adam Wale
Subject: Re: Searches causing disk writes
On Sat, 29 Oct 2011, Christopher Wood wrote:
> 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
How do memory writes to mmap'ed file show up in iotop? The BDB library,
by default, uses mmap'ed filed for its shared-memory regions for its mpool
page cache, holding locks and the transaction data structures, etc. If a
search requires lots of pages to be pulled into BDB's page cache in those
mmap'ed files, will those show as writes to iotop.
If so, and those really are getting written to disk, then switching from
mmap'ed files to SysV shared memory may be the solution. The shm_key
option (olcDbShmKey in back-config) lets you enable that. Be aware that
on many OS's, the the default system limits for shared memory size were
fairly low, so you may need to bump that up. On Linux take a look at
/proc/sys/kernel/shmmax and/or the kernel.shmmax sysctl in
> In that case, strace/ltrace/dtrace/etc. on the slapd process will show
> you what the process itself is doing.
strace may confirm the above to be the problem by the *absence* of
syscalls writing data. dtrace might be able to show it directly...