[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: htree stabilitity and performance issues



On Thu, Dec 18, 2003 at 08:26:28AM -0700, kwijibo zianet com wrote:
> would go into the DW state.  From what it looked like NFS was waiting
> on the filesystem to stat and list peoples Maildirs that had lots of files.

With htree on the nfs server, it should lower the cpu usage of reading the
directories, but will cause different disk access patterns.

I'm surprised courier doesn't have an index, and only stat the new files to
populate the index (keyed on filename).

I hear that cyrus is supposed to handle large quantities of mail well, that
might be an option.

> Another strange note is that kswapd would be using 99 percent CPU during
> these NFS storms, not sure why, since I wasn't swapping.  All of this was
> happening while I had plenty of disk IO left on the storage box. 

What kernel version?  Is is stock or distro?  How much memory do you have in
the nfs server?

> Eventually we just started to nuke old mail out of the larger dirs to get
> them down to a sane size and things have cleared up. 

Sounds like all of the waiting nfs clients waiting for directory processing
to respond were helping to cause a VM imbalance (which is why I ask about
your kernel version).

> Now from what it sounds like htree will actually make things worse in
> this type of situation, is this correct?  Is there a patch somewhere
> or a filesystem out there that is good at doing this stat and list
> type of load.  Or is it just NetApp time? :)

So the pop & imap servers are on freeBSD?  Theo, will this preload work with
FreeBSD's libc?

I'd suggest you put the preload on your pop & imap servers and use htree on
your nfs server.

xfs, jfs, reiserfs, and ext3 with htree all use indexed directories, but I
don't know any details about xfs or jfs as to how they relate with mailDir.
Reiserfs has the same issues as current htree (without the reordering patch)
IIRC. 

Mike




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]