[Linux] exim (mailserver) & filesystem performance vraag

[B-Man]

Ik ben bezig met het inrichten van een stel nieuwe servers (Dell poweredge 2950 machines).

Korte toelichting:

Oude situatie: P4 3Ghz, 1GB geheugen, SATA schijf
Nieuwe situatie: Woodcrest Xeon 1,6 Ghz, 2GB geheugen, SAS schijf

Qua 'rauwe' performance (gebaseerd op een eigen java benchmark) is de nieuwe server minstens 2x sneller. Disk performance is ook 2x zo hoog.

Nu loop ik tegen het volgende aan: een installatie van exim op de nieuwe machine is veel trager (denk aan 10x trager).

Het eerste wat ik zelf bekeek is natuurlijk: wat is er naast hardware veranderd:

- Nieuwere kernel (2.6.9 vs (ik meen) 2.6.17)
- Nieuwere versie van exim (4.43 vs 4.63)
- Ander filesystem (XFS vs ext3)
- Andere partitionering (5 partities, exim op andere partitie als /, versus alles nu op een partitie)

Performance verschil is meetbaar door een java benchmark die meet hoeveel tijd er in verschillende stappen van een SMTP sessie verloopt. Dit uiteraard na 'opwarmen' van de JVM.
Na het DATA command, zenden van de mail, en dan het zenden van een CRLF DOT CRLF sequence is de oude server 10ms 'bezet' in de SMTP sessie. De nieuwe server doet over precies hetzelfde 100-150ms.

Nu ben ik zelf al verschillende dingen aan het onderzoeken (aparte partitie voor exim, XFS partitie, oudere versie van exim) alleen vraag ik me af of ik in die hoek moet zoeken.
De oudere versie van exim (4.43) was namelijk niet sneller of trager, dus daar lijkt het niet aan te liggen.
Het lijkt me daarnaast sterk dat een bestandssysteem of partitionering dit effect kan hebben op een systeem dat overall minstens 2x zo snel is.

Het duurt nog even voordat ik hier concreet info over heb, en mijn vraag aan jullie is nu: wie heeft er ervaring met verschillende filesystems, en de performance daarvan? Tevens: wat is de invloed van losse partities hierin? Exim creert vooral veel kleine files (queue op schijf), en XFS schijnt daarin (uitgebreid over gelezen) geen ster te zijn. Ik las dat Ext3 wat achterblijft qua performance, maar een factor 10 lijkt me op een 2x zo snelle schijf (dus absoluut gezien 20x trager) raar?

Het belangrijkste verschil is mogelijk de schil om het OS heen. De oude machine is een suse 9.1 machine, terwijl ik de nieuwe machines op LinuxFromScratch draai. Heeft suse optimalisaties doorgevoerd in de kernel filesystem handling? Ik kan verder namelijk niets spannends ontdekken, zowel op het oude als de nieuwe systemen draai ik _zonder_ 'noatime'.

Een zoektocht door google news, de exim mailinglists en ook ons aller GoT leverde geen bruikbare info op. Wel algemene performance tuning (die ik zeker meeneem), maar die helpt me niet met het verklaren van dit verschil in performance.

[B-Man]

Puur om te testen of Disk I/O de bottleneck is in deze situatie, heb ik op een van de nieuwe machines ter test de spool directory van exim op een tmpfs mount gezet. De bottleneck is dan compleet verdwenen.

Ik heb daarom binnen de spool directory gekeken welke map het probleem is, en de mappen 'db' (hints) en 'msglog' (bericht historie) hebben geen invloed, het is enkel de 'input' map waar de daadwerkelijke queue instaat.
Als ik de input directory op tmpfs heb staan is de verwerkingstijd ook rond de 10ms op de nieuwe server.

Morgen maar eens de hoofdpartitie verkleinen, en er eentje van een paar GB naast zetten, daar de exim spool directory op, en dan nogmaals testen.

Ik weet (las het gisteren) dat exim na ieder ontvangen bericht deze altijd op schijf in de 'input' directory wegschrijft, en dan fsync()-ed. Kan het feit dat exim op de /-partitie staat i.c.m. de vele fsync()-s ervoor zorgen dat ondanks de veel snellere schijf de performance inkakt?

[Verwijderd]

Ik snap niet echt waarom je op productie servers LinuxFromScratch zou draaien?
De debian package maintainers hebben waarschijnlijk echt wel meer verstand van de diverse packages dan jij, en zij zorgen ook voor security updates...

[B-Man]

Verwijderd schreef op zondag 15 oktober 2006 @ 16:29:
Ik snap niet echt waarom je op productie servers LinuxFromScratch zou draaien?
De debian package maintainers hebben waarschijnlijk echt wel meer verstand van de diverse packages dan jij, en zij zorgen ook voor security updates...

Dat is een discussie die al vaak gevoerd is, ook hier op GoT. Gelieve in dit topic in te gaan op mijn vraag over exim en filesystem performance.

Ontopic: na behoorlijk wat leeswerk @ google groups ga ik morgen eens een losse partitie aanmaken voor de mailqueue, daar xfs op draaien met noatime en nodiratime, en dan nog eens benchmarken.

[Verwijderd]

Buiten het feit dat het simpelweg geen goed idee is, is de kans groot dat het gebruik van LFS aan de oorzaak ligt van je probleem.
Installeer voor de geinigheid ff een gewone distro, en kijk wat het geeft?

[Verwijderd]

Verwijderd schreef op zondag 15 oktober 2006 @ 16:29:
Ik snap niet echt waarom je op productie servers LinuxFromScratch zou draaien?
De debian package maintainers hebben waarschijnlijk echt wel meer verstand van de diverse packages dan jij, en zij zorgen ook voor security updates...

Ik zie hier nergens dat er met Debian gewerkt wordt?

[Verwijderd]

Verwijderd schreef op zondag 15 oktober 2006 @ 23:55:
[...]


Ik zie hier nergens dat er met Debian gewerkt wordt?

Je mag debian ook door een andere distro vervangen, Ubuntu server, OpenSuse, Fedora Core, take your pick, daar gaat het hier niet om.
De TS heeft moeilijkheden met een bepaalde package, die waarschijnlijk veroorzaakt worden doordat hij LFS gebruikt. Daarom adviseer ik hem van een distro te gebruiken waarvan alle packages op voorhand door kennes in elkaar gestoken zijn, zoals bijvoorbeeld debian.
Dat kan je ook perfect configureren zoals je wil, je kan zelfs de packages recompilen zoals jij het wil.
Maar dan vertrek je gewoon van een degelijke basis.

[ Voor 40% gewijzigd door Verwijderd op 16-10-2006 00:05 ]

[B-Man]

Verwijderd schreef op zondag 15 oktober 2006 @ 17:57:
Buiten het feit dat het simpelweg geen goed idee is, is de kans groot dat het gebruik van LFS aan de oorzaak ligt van je probleem.
Installeer voor de geinigheid ff een gewone distro, en kijk wat het geeft?

Allereerst: ik zal het zeker uittesten. Ik heb behoorlijk wat ervaring met een varieteit aan distro's (redhat (voor de fedora tijd), fedora, suse, debian), dus zal eens kijken wat voor performance ik daar uit kan halen. Vermoedelijk pak ik de Debian stable, maar dan wel met backported zaken uit unstable, aangezien dit nieuwe Dell's zijn, en stable nog geen driver voor netwerkkaart bevat (bnx2 driver).

Offtopic:
Verder kies ik niet zomaar voor LFS, na jaren werken met allerhande distro's bevalt LFS me gewoon heel erg goed. Het zijn servers met een zeer klein aantal eigen services en ik ben verder enige gebruiker. Ik zou voor een 'public' server, waar anderen shell access hebben ook geneigd zijn een bekende distro te installeren, maar voor dit soort 'lean and mean' wil ik graag alles zelf finetunen.
Ja, distro bouwers hebben veel ervaring & kennis, maar tegelijkertijd is een distro wel een algemeen gericht systeem, niet gefinetuned voor een specifiek doel. Dat vind ik nu net de kracht van LFS.
Ik draai deze servers dan ook niet blindelings op LFS, maar vanaf een image wat ik zelf centraal beheer; zeer weinig dependancies, dus geen grootschalige security issues.
Het is verder gewoon persoonlijke voorkeur, dat jij voor een bekende distro kiest: prima, respecteer ik. Mijn voorkeur (na jaren werken met en sleutelen aan) linux & tools is LFS.

Overigens is LFS ook interessant in deze context: ik wil graag weten wat nu precies de oorzaak van dit performance probleem is, of het bijvoorbeeld aan ext3 ligt, of met name aan de partitionering, of beiden natuurlijk.
Met een volwassen distro heb ik die vraag vermoedelijk niet, maar een van de redenen dat ik op linux draai is dat ik hier juist de mogelijkheid heb om tot in detail te achterhalen waar de bottlenecks zitten, en kan uitvogelen welke parameters, tools en overige factoren er mee te maken hebben.
In mijn ogen is een distro geen wondermiddel. Ja, de default instellingen en packages zullen een solide basis vormen, maar op een bepaald moment moet ik ook daar aan het tunen gaan (been there, done that).

Zoals je mogelijk wel uit mijn verhaal kunt destilleren ben ik gewoon fervent LFS gebruiker, al jaren

Overigens: heb je enige ervaring met exim? Als je die mailserver namelijk zou kennen (ik vermoed van niet), zou je weten dat er bar weinig aan in te stellen valt bij het configureren + compilen, en dat er dus weinig verschil is tussen een package en een eigen compile. De 'package' op zich is dus niet zozeer het probleem.

[ Voor 6% gewijzigd door B-Man op 16-10-2006 00:45 ]

[_JGC_]

ext3 is een beetje trager dan XFS. Verder is het aan te raden bij mailservers je /var los te houden van de rest van je systeem. Ext3 kan je tunen met de "dir_index" optie, die kan je met mke2fs -O dir_index bij het maken van een filesystem aanzetten, of achterna met tune2fs -O dir_index, gevolgd door een reboot in single user mode en een fsck -D op je ext3 partitie.

Overigens vraag ik me af vanaf welke partitie je compileert, als dat gewoon vanaf hetzelfde fs is waar je /var ook op staat, dan wil dat nog wel eens wat gaan fragmenteren met al die kleine bestandjes die her en der neergezet worden tijdens het compileren. Ik merk dat op mijn eigen machine ook gewoon, na verloop van tijd zijn de build chroots die ik voor archlinux gebruik niet meer vooruit te branden en gooi ik ze weg om opnieuw te beginnen.

[B-Man]

_JGC_ schreef op maandag 16 oktober 2006 @ 08:19:
ext3 is een beetje trager dan XFS. Verder is het aan te raden bij mailservers je /var los te houden van de rest van je systeem. Ext3 kan je tunen met de "dir_index" optie, die kan je met mke2fs -O dir_index bij het maken van een filesystem aanzetten, of achterna met tune2fs -O dir_index, gevolgd door een reboot in single user mode en een fsck -D op je ext3 partitie.

Overigens vraag ik me af vanaf welke partitie je compileert, als dat gewoon vanaf hetzelfde fs is waar je /var ook op staat, dan wil dat nog wel eens wat gaan fragmenteren met al die kleine bestandjes die her en der neergezet worden tijdens het compileren. Ik merk dat op mijn eigen machine ook gewoon, na verloop van tijd zijn de build chroots die ik voor archlinux gebruik niet meer vooruit te branden en gooi ik ze weg om opnieuw te beginnen.

Aha. Ik ben bezig met het inrichten van een aparte (2gig) partitie voor de mail queue, dus fragmentatie op de andere partitie(s) zal dan minder van invloed zijn. Dan zit ik in ieder geval op de goede weg.

Als ik het me goed herinner is dir_index een manier om veel kleine bestanden in een dir op ext3 te optimaliseren, of niet? Zo ja, dan heb ik dat probleem reeds omzeild: exim biedt een optie om de mailqueue te splitsen naar 62 separate directories, waardoor er per directory veel minder bestanden zijn. Ik zal sowieso de optie nog even onder de loep nemen, ben nu toch aan het testen.

[B-Man]

Ik heb inmiddels verschillende filesystems getest: reiserfs en xfs, waarna bleek dat xfs ruim 2x zo snel is als ext3. Reiserfs zit er tussenin, terwijl ik eigenlijk verwacht had dat reiserfs sneller zou zijn.

Ik heb ter vergelijking alle bestandssytemen gemount met noatime,nodiratime en vervolgens nog twee specifieke tweaks getest, die beiden (volgens verschillende berichten op het net) optimaal zouden zijn voor mailserver IO (veel random IO die constant gesync()d wordt).

Reiserfs met notail maakte erg weinig verschil, en ext3 met data=journal maakt ook bar weinig verschil.

Het is nog steeds trager dan op de oudere server, dus er zijn nog andere factoren in het spel, maar met XFS zit ik in ieder geval veel dichter op de oude performance.