IMAP very slow, "massive" harddisk activity

[TCWardrobe]

Hi folks,

access via IMAP seems to be somehow very ressource hungry and slow the first time you access a folder. Ok, this is noted in maildirs with several hundred or thousand mails. The more mail, the longer it takes. During that time the MUA (in this case Evolution) just gets about 5KB/s while the harddisks are quite busy, about 1-8MB/s (not much, this raid1 array can provide about 80MB/s), but the system is completely idle except for that only connection.
I access that server through a VPN DSL dialin (on both sides) but 40KB/s should be no problem. With other IMAP services I have no problem regarding speed... but even if due to massive tcp handshakes which would make it slow over fairly high latency connections... see the impact on the harddisks. If I extrapolate the speed factor of the harddisks to a 100Mbit or even 1Gbit connection, the disks would burn!

Code: Select all

groupie:~# iostat -k -d 2 /dev/md0
Linux 2.6.18-5-686 (groupie)    14.11.2007

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
md0             357,00       926,00      1056,00       1852       2112

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
md0             705,50       746,00      2654,00       1492       5308

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
md0             365,67      1315,42      1227,86       2644       2468

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
md0             749,25       376,12      2827,86        756       5684

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
md0            1007,43      2156,44      3700,99       4356       7476

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
md0            1621,61      3933,67      5931,66       7828      11804

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
md0             350,75       268,66      1237,81        540       2488


Any thoughts on this? Or did I make false assumptions above? As a side note, I noticed during PST import from old Outlook profile to scalix similar issues, just about 1MB/s, netspeed sometimes a bit more. Ok, here it may be because several thousand small files are the reason for this poor performance... but...

Anyhow, do you have some values to compare mine with? Please post!

greets
Michael

P.S.: it is a core 2 duo with 2GB ECC RAM with soft raid1

[stephan.klein]

Hi Michael,

could you please try this

http://www.scalix.com/wiki/index.php?ti ... mance_test

and post the ouptut?

Kind regards
Stephan

[TCWardrobe]

Hi Stephan,

thanks for the hint... so here it goes:

Code: Select all

mschmitt@groupie:~/scalix/disktest$ ./disktest
Test Started
Test file: disktest.data
File size: 100 Mb
Num write: 10000
PRO: 0.000      Create file: disktest.data
PRO: 0.252      Zero fill
PRO: 1.310      Sync data
PRO: 0.000      Seek to start
PRO: 0.000      Fill write buffer
Starting write tests
PRO: 49.419     Write tests complete
Test complete

compared to the "reasonable" value on the admin resource kit webseite rather disappointing, but as this box is just for 15 users and not for several hundred or thousand I think these setups / values may not be comparable at all, am I wrong?

greets
Michael

[stephan.klein]

Hi Michael,

thank you for your test results. They are indeed not really good, but opening a folder should not be that slow - at least if you open it for the second time and data is cached by your client.

Nevertheless, your disk subsystem is a bottleneck, at the latest, if your users start to move or delete more than 20 messages at the same time.

My old disc controller performed like yours, I replaced it a few month ago (with a 'simple' icp sata controller) and now I get signifacant better results.

Code: Select all

mail7:/compile# ./disktest
Test Started
Test file: disktest.data
File size: 100 Mb
Num write: 10000
PRO: 0.000      Create file: disktest.data
PRO: 2.641      Zero fill
PRO: 0.817      Sync data
PRO: 0.000      Seek to start
PRO: 0.000      Fill write buffer
Starting write tests
PRO: 8.868      Write tests complete
Test complete


Now moving 50 and more messages around and opening folders with up to 30.000 single messages is no problem

Sorry for not beeing able to give you any advice for a simple configuration tweak...

Regards
Stephan

[seankoshy]

Is there anything to speed up access? I'm currently just building a new server, running 2x 73GB SAS 15k for the OS, and 4 x 300GB SAS 15k for the /var/opt dir. I'm using a Perc 5i Raid card. I have disabled read ahead and write cache.

My results were quite dissapointing - if 19 isreasonable write speed ...

Code: Select all

caladan:/var/opt # ./disktest
Test Started
Test file: disktest.data
File size: 100 Mb
Num write: 10000
PRO: 0.000      Create file: disktest.data
PRO: 0.113      Zero fill
PRO: 0.787      Sync data
PRO: 0.000      Seek to start
PRO: 0.000      Fill write buffer
Starting write tests
PRO: 44.530     Write tests complete
Test complete


Anyone have suggestions? Thanks,

Sean

[Valerion]

This is on a single-disk SATA system

Code: Select all

[root@nightwolf sbin]# ./disktest
Test Started
Test file: disktest.data
File size: 100 Mb
Num write: 10000
PRO: 0.000      Create file: disktest.data
PRO: 0.403      Zero fill
PRO: 1.873      Sync data
PRO: 0.000      Seek to start
PRO: 0.000      Fill write buffer
Starting write tests
PRO: 31.582     Write tests complete
Test complete

On this server there are 16 mailboxes and we get good performance. I would suggest you look at your RAID-level setup. Scalix recommends a dual-channel system (like RAID-10) above a single-channel setup like RAID-5.

[seankoshy]

Now I'm really confused as to why my write performance is bad ... the OS is RAID 1, and the var/opt is RAID 10

[TCWardrobe]

Here it is also a raid1, even if it is a software raid the performance should be better I think. In theory the performance for single disc setup with the same hardware would be the same as this was one "transfer job".
And the sata controller should be ok too. It is a Intel server mainboard S3000AHV with a 82801GB/GR/GH (ICH7 Family) serial ATA storage controller onboard... I don't have experience with this board or chipset but I would be VERY disappointed if this chipset would be the reason for this poor performance.
Could someone elaborate on this? Maybe some more values to compare against mine? Just a few words on the general hardware specs of that system:
Intel core 2 duo E4500 @ 2.20GHz, 2*1GiB Kingston 667Mhz ECC RAM, 2*500GB Samsung HD501LJ 7200RPM 16MB Cache SATAII discs.

greetings
Michael