[Dovecot] ext3/ext4 performance issue
Wonder if anyone else has actually noticed this and has some kind of statistics?
- Timo Sirainen tss@iki.fi:
Wonder if anyone else has actually noticed this and has some kind of statistics?
I could run stats here, with 12.000 users to see what the average size is...
-- Ralf Hildebrandt Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.computerbeschimpfung.de "People demand freedom of speech as a compensation for the freedom of thought which they seldom use."
On Fri, 2009-05-15 at 22:58 +0200, Ralf Hildebrandt wrote:
- Timo Sirainen tss@iki.fi:
Wonder if anyone else has actually noticed this and has some kind of statistics?
I could run stats here, with 12.000 users to see what the average size is...
It would be interesting to have some kind of statistics for cur/ directories and get <cur directory size> divided by <number of files in cur> and then see how many users have values that are much higher than average (i.e. how many users have had tons of mails that have since been deleted).
On Fri, 2009-05-15 at 17:13 -0400, Timo Sirainen wrote:
I could run stats here, with 12.000 users to see what the average size is...
It would be interesting to have some kind of statistics for cur/ directories and get <cur directory size> divided by <number of files in cur> and then see how many users have values that are much higher than average (i.e. how many users have had tons of mails that have since been deleted).
I wrote an ugly script for it, just change the "find ." path to wherever your maildirs are and run in some temp directory:
### total.sh #!/bin/sh
find . -name cur -exec ./diravg.sh {} \; > log
count=cat log|wc -l
avg=cat log | awk '{print $2"+"}'|tr -d '\n'|sed 's/^/(/'|sed "s,+\ $,)/$count\n,"|bc -l
echo "average: $avg"
echo "3x higher:" cat log | perl -ne "@l = split(/ /); print if \$l[1] >= ($avg*3);"
### diravg.sh #!/bin/sh
dir=$1
files=/bin/ls $dir|wc -l
if [ $files = 0 ]; then
files=1
fi
ls -ld $dir|head -1|awk "{print \"$dir \" (\$5 / $files);}";
on 5-15-2009 11:59 AM Timo Sirainen spake the following:
Wonder if anyone else has actually noticed this and has some kind of statistics?
One could always run the mailstore on LVM and then you could snapshot the mount and then fsck it while still technically in use. It would probably slow down the filesystem, but it is still live.
Hi Scott,
One could always run the mailstore on LVM and then you could snapshot the mount and then fsck it while still technically in use. It would probably slow down the filesystem, but it is still live. Uhm, and then you have a nice and fsck'd snapshot, but your live filesystem will still be untouched? Or do you propose replacing the mailstore with a (readonly?) versioned mounted from the lvm snapshot? I'm not aware of anything that can swap filesystems like this online (ie, with files open) and that would also mean that while fsck'ing, you can only read mail, not receive, move or delete mail?
Gr.
Matthijs
Matthijs Kooijman wrote:
Hi Scott,
One could always run the mailstore on LVM and then you could snapshot the mount and then fsck it while still technically in use. It would probably slow down the filesystem, but it is still live. Uhm, and then you have a nice and fsck'd snapshot, but your live filesystem will still be untouched? Or do you propose replacing the mailstore with a (readonly?) versioned mounted from the lvm snapshot? I'm not aware of anything that can swap filesystems like this online (ie, with files open) and that would also mean that while fsck'ing, you can only read mail, not receive, move or delete mail?
Changes made to a snapshot will never been seen by the fs it was snapshotted from and vice-versa. It uses copy on write which will get progressively slower as the snapshot and the origional diverge until you end up with a performance disaster.
http://www.nikhef.nl/~dennisvd/lvmcrap.html
~Seth
on 5-18-2009 8:46 AM Matthijs Kooijman spake the following:
Hi Scott,
One could always run the mailstore on LVM and then you could snapshot the mount and then fsck it while still technically in use. It would probably slow down the filesystem, but it is still live. Uhm, and then you have a nice and fsck'd snapshot, but your live filesystem will still be untouched? Or do you propose replacing the mailstore with a (readonly?) versioned mounted from the lvm snapshot? I'm not aware of anything that can swap filesystems like this online (ie, with files open) and that would also mean that while fsck'ing, you can only read mail, not receive, move or delete mail?
Gr.
Matthijs I re-read the howto on using fsck on LVM snapshots, and it is only good if the FS passes. Then you can update the fsck details in the filesystem. If the FS doesn't pass, you would still need to schedule a fsck when inactive.
My bad.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 15 May 2009, Timo Sirainen wrote:
on my production system, I've scanned 97559 dirs in total, including 'tmp's, Maildir & homedirs. Control and Indexes are located elsewhere.
There a total of 97406, 5238 of them use more than one block, hence, 92168 are skipped from the stats below.
Then I compared the size of the directory file with this:
filename size = sum of length of all entries in the directory
- 10 * number of entries in the directory
The ratio is calculated: size of directory file divided by filename size
ratio num of dirs <2 1593 3 810 4 228 5 129 6 122 7 65 8 56 9 31 10 30 11 27 12 21 13 18
Top ranks are: fnamsiz dirsiz ratio 23 1417216 61618.09 23 1089536 47371.13 23 872448 37932.52 23 839680 36507.83 23 802816 34905.04 23 684032 29740.52 23 684032 29740.52 23 655360 28493.91 70 1847296 26389.94 23 593920 25822.61 23 581632 25288.35 23 536576 23329.39 23 532480 23151.3 23 516096 22438.96 23 503808 21904.7 23 471040 20480 23 446464 19411.48 23 425984 18521.04 287 5005312 17440.11 23 376832 16384
There are 2175 dirs with a ratio >= 10.
There are 1613 directories with a ratio >= 100, 747 "/cur" 492 "/new" 372 "/tmp" 1 Maildir itself 1 .dovecot.rawlog
Nearly all of them are: INBOX, Trash & SPAM folders. The two last ones with various names depending of the IMAP client used.
I used this Perl script: http://www2.inf.fh-brs.de/skdata/dovecot/cntDirsize.bz2
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBShK+t3WSIuGy1ktrAQJRdQf/UGv6Z/zzcqK88SZ9Axgx2PAmU8kH498w w7enifmjKpPMw0NOv2a4uPf1BNaVdTC/Ln/MMILSnZIqWYYo1RyB35HdXylFH2NQ wtOkYDJuowtcdw8JXz3lxlDNpuWJLCjIRFSoodihmPVdwEvsEScbyOb9QH90F3Yb DUK/VrI9M63fOggushVNr8iROoP4D3U+C/G0DLkPSdBfRXIBkNUldmrRiBAsMvMf /1seK3bQPsPHsSQrGG4zi4j4NXYcLXmyuvmS/V7QmBAUaA2lzLXAI8da5AokD947 SLrvUA9BQTlwldisossY2YbpX+4dtBTbVNULsCKF//tY9UXvFu1NKg== =3TPJ -----END PGP SIGNATURE-----
participants (6)
-
Matthijs Kooijman
-
Ralf Hildebrandt
-
Scott Silva
-
Seth Mattinen
-
Steffen Kaiser
-
Timo Sirainen