On Thu, Dec 18, 2003 at 08:26:28AM -0700, kwijibo@xxxxxxxxxx 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 _______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
