imap clients leggen server plat

[Multispeed]

ik heb een redhat 7.3 servertje met 20 mensen die via imap hun mail ophalen elke 5 minuten. Zodra een imap verbindign word gemaakt staat de CPU load op 100%. Als je dan bijv. de webserver probeerd te benaderen duurt het een eeuwigheid. Alle andere dingen duren ook lang (pop, ssh etc.)
Met nice heb ik al wel zitten testen, maar voor elke client word een nieuwe sessie opgezet met eigen imap proces.
Is er een andere optie die ik over het hoofd zie?
Ow ja, waar het dus helemaal fout gaat is met webmail (horde), zodra je mail box geopend moet worden (imap) dan ligt de rest (ook je webmail html-gedeelte) plat en duurd het dus erg lang.

[The Jester]

Welke hardware heb je??
'K kan me voorstellen dat e.e.a. op een Pentium-133 met 32Mb niet écht wil vlotten

[Wilke]

Hoe lang is de CPU load 100% ?
Welke imap-server draait er?
Op wat voor hardware draait dit alles?

Zo kunnen we nog niks met dit topic...

[Steven]

Horde is ook wel een vrij heavy webmail oplossing overigens. Vooral als je PC wat ouder is kan je beter denken aan Iloha-webmail. Draait hier perfect op een P166 met mailboxen van een paar 1000 mailtjes.

[DiNo!]

De redhat 7.3 imapd is dusdanig langzaam dat een mailbox met 500 MB eerst geparsed moet worden op alle headers, en dat duurt lang. De enige oplossing die ik weet is of een andere imapd server gebruiken of meerdere imappen gebruiken zodat je INBOX leeg blijft (weinig MBs)

[Multispeed]

het is een server met een athlon 2100, 256Mb en een ide harddisk. Verder redhat 7.3 volledig ge-up2dated.

Kan met grotere mailboxen ook de harddisk de bottleneck zijn en hoe kan je dat zien...

Ook als je geen horde gebruikt maar outlook express dan komt ie op 100% voor de volledige tijd dat de imap sessie duurd. Met top zie je dan iets als imapd-gebruikersnaam met daarachter 100% cpu.

[ralfbosz]

Al eens aan een andere imap-server gedacht?

Aan je info te zien draai je met maildir (dus alle post in /var/spool/mail/<username>), misschien eens overstappen op een ander systeem.

Gebruik zelf qmail + vpopmail + courier imap + squirrel webmail en geen problemen op mijn 450Mhz server .

[Coen Rosdorff]

ralfbosz schreef op 03 augustus 2003 @ 16:06:
Aan je info te zien draai je met maildir (dus alle post in /var/spool/mail/<username>), misschien eens overstappen op een ander systeem.

Redhat heeft standaard mbox formaat.

Zelf overstappen naar maildir is opzicht wel te doen, maar meestal is de reden dat je een bepaalde distributie draait dat je juist al dit soort dingen niet zelf wilt installeren.

DiNo7 schreef op 03 August 2003 @ 13:11:
De redhat 7.3 imapd is dusdanig langzaam dat een mailbox met 500 MB eerst geparsed moet worden op alle headers, en dat duurt lang. De enige oplossing die ik weet is of een andere imapd server gebruiken of meerdere imappen gebruiken zodat je INBOX leeg blijft (weinig MBs)

Om mijn eigen server merk ik trouwens niets van traagheid (PII 300) met mailboxen tot 20 á 30 MB. Hoe het gaat met grotere boxen weet ik niet.
Een mailbox van 75MB met 12000 berichten (lkml) staat in 30 seconden op het scherm.

[Wilke]

Aan de hoeveelheid mail zou het niet moeten kunnen liggen; ik heb een mailbox van 67 MB met daarin meer dan 11000 messages (Bugtraq), en die staat in kmail binnen een seconde op het scherm (ook via imap). Ik vraag me af of DMA wel aan staat op die computer? Dat is te checken met hdparm.

[igmar]

Gouldian schreef op 02 August 2003 @ 18:38:
ik heb een redhat 7.3 servertje met 20 mensen die via imap hun mail ophalen elke 5 minuten. Zodra een imap verbindign word gemaakt staat de CPU load op 100%. Als je dan bijv. de webserver probeerd te benaderen duurt het een eeuwigheid. Alle andere dingen duren ook lang (pop, ssh etc.)
Met nice heb ik al wel zitten testen, maar voor elke client word een nieuwe sessie opgezet met eigen imap proces.

Even een op het oog niet relevante vraag : Indien je een DNS server op die bak het draaien, begint named te loopen (en dus CPU te hoggen) indien je gewoon een aantal maal een query opvraagt ?

Indien ja : Dit probleem wordt op een of andere manier veroorzaakt door een cache alignment probleem in de kernel, en is oplosbaar door met bepaalde opties in de kernelconfig te spelen.

[ Voor 1% gewijzigd door igmar op 04-08-2003 11:41 . Reden: bah, tags, ik heb dus de pest aan HTML ]

[Multispeed]

dit is een gedeelte van de uitkomst van hdparm -I

non-removable ATA device, with non-removable media
Model Number: MAXTOR 6L040J2
Serial Number: 662221641146
Firmware Revision: A93.0500
Standards:
Used: ATA/ATAPI-5 T13 1321D revision 1
Supported: 1 2 3 4 5
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
bytes/track: 32256 (obsolete)
bytes/sector: 21298 (obsolete)
current sector capacity: 16514064
LBA user addressable sectors = 78177792

is er net zoals top voor CPU drukte een tooltje voor harddisk drukte?

[Multispeed]

ik gebruik trouwens de volgende RPM voor imap: imap-2001a-18.i386.rpm

[Multispeed]

dit vond ik later, hier staat dma op off

hdparm -v /dev/hda

/dev/hda:
multcount = 0 (off)
I/O support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 0 (off)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 4866/255/63, sectors = 78177792, start = 0
busstate = 1 (on)

[Verwijderd]

Probeer eens de volgende switch voor hdparm, zou al iets horen te helpen:
hdparm -m16 -d1 -u1 /dev/hda