On Mon, 10 Mar 2003, Paul Warren wrote:
> On Mon, 2003-03-10 at 11:03, Juri Haberland wrote:
> > > I have been experimenting with a few things, and have noticed that imapd
> > > is almost unbearably slow when moving (actually, COPY 'ing) messages to
> > > a Maildir that is 'large'. By 'large' I qualify that to mean roughly
> > > 9000 messages. I am running under Linux 2.4.20, and use the ext3
> > > filesystem, although I've run my experiments on both the IBM jfs and the
> > > ext3 filesystems. The filesystem is not the issue here, however.
> >
> > Ext3 as a filesystem is most certainly an issue if it comes to many
> > entries in one directory. Here a quote of a recent message by Andreas
> > Dilger, one of the ext3 developers on the ext3 mailing list:
> >
> > > Yes, you will see this as a significant increase in system time for
> > > directory access. The stock ext2/3 directory code doesn't work so well
> > > past about 5000 entries in a single directory (it survives up to about
> > > 10000 entries, but basically dies after that.
> >
> > I don't know about JFS, but I use XFS and it works quite nice.
>
> Before switching to Courier, I did a bit of benchmarking of mbox vs
> maildir, and ext3 vs reiserfs. The results are here:
>
> http://www.decisionsoft.com/pdw/mailbench.html
Using the numbers at that website, I feel your conclusions are incorrect
or hastily drawn. I'm not going to include the 'ReiserFS2' numbers here
because they can't be compared to the ext3 numbers -- you performed no
tests with ext3 and the noatime,nodiratime flags -- thus the most
comparable are the ext3 and reiserfs columns as indicated.
Then, simply comparing the numbers shows that ext3 beats or meets
reiserfs in SELECT.2, DELETE.1, FETCH.1, SEARCH.1 and SEARCH.2, making
ext3 slower in SELECT.1 and FETCH.2. That doesn't add up to (quote),
"Maildir + ReiserFS is a win on pretty much every front".
I would also caution you to be careful about drawing any kind of
conclusions from statistical variances that are very small -- the
difference between X seconds and X + 0.1 is hardly significant.
==
That being said, I *really* don't want this to degenerate into a "my
filesystem is better than your filesystem", because it's a pointless and
annoying argument.
For interesting comparison, however, I ran a test of my own, which
splits digests into individual messages and delivers them to a maildir
via maildrop. Running exactly the same way, the only difference being
the location of the maildir (test 1 is on ext3, test 2 is on jfs 1.1.1),
the total times are as below:
test1 (ext3):
real 19m53.774s
user 4m24.580s
sys 3m8.310s
test2 (jfs):
real 8m19.768s
user 4m24.840s
sys 2m45.820s
Note that the 'user' time is nearly identical -- that's to be expected,
because the only thing that was changed was the filesystem underlying
the maildir, not the process itself.
There are 8806 messages in total.
Using the following command, here is the total size in bytes:
find gpz2/new/ -printf "%s\n" | awk 'BEGIN { tot=0; } { tot = tot + $0
} END { print tot }'
13190542
12,881 KB.
Not huge.
--
Applying computer technology is simply finding the right wrench to
pound in the correct screw.
Jon Nelson <[EMAIL PROTECTED]>
C and Python Code Gardener
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
