optimalizace IMAP serveru

24.1.2006 14:48 | Přečteno: 1405× | poslední úprava: 24.1.2006 15:59

V našem ústavu máme linuxový login server 2x XEON, 2GB RAM. Nějakých 300 uživatelů si na něm dělá leccos, nejvíc ale přístup k poště IMAPem. Hodně jich má stovky MB mboxů nastřádaných za ta léta. Hodně jich taky má soubor ~/mbox ve stovkách MB. Nebo jiné velké poštovní soubory ve formátu mbox. Používáme (zatím) WU imapd spouštěný pomocí xinetd. Poslední dobou přicházejí situace, že obsluha IMAP klientů je podstatně zpomalená, takže uživatelé si celkem právem stěžují. Stěžují si právem i ti, kteří mají poštu hezky roztříděnou do desítek nebo stovek malých mboxů, protože jim to v těch kritických chvílích taky běhá pomalu. V následující samomluvě se budu snažit o analýzu problému, aniž bych dospěl k hotovému řešení.

Když udělám

   grep  'imapd.*Login user=' | sort +6.0 -7.0

na log, tak se mi zdá, že vidím příčinu problému. Mnozí klienti na to jdou tak, že jakmile dostanou, co chtěli, ukončí IMAP relaci a během několika sekund se připojují znovu. Slušný člověk by zůstal připojen a další požadavek by poslal po pěti minutách. Ale tohle jsou většinou MS klienti, ti to takhle dělají. Nejsou sami, ani Squirrel Webmail si nedělá trvalé spojení.

   vmstat 1

v těch kritických chvílích ukazuje nevelké zatížení procesoru kolem 20% jedné CPU, nulovou stránkovací aktivitu, ale zato čtení z blokových zařízení bo=15000 a víc. Nemýlím-li se, tohle znamená provoz 15MB/s čtení z disku a ukazuje se, že se jedná o to diskové pole, na kterém je jak /var/spool/mail , tak uživatelské homesy. Při tom

   ps -ef

opravdu neukazuje nic podezřelého, jenom stovky imapů.

Moje představa je taková, že opakované čtení poštovních souborů vede k mnoha přístupům na disk, takže buffery jádra už to nevyrovnají a systém skutečně fyzicky přistupuje na disky. Kde je to slabé místo nevím - snad přímo v jádře, když současně máme kolem 1000 context switchů za sekundu.

Nabízí se možnost použít jiný IMAP server. V debatním klubu cz.comp.linux jsem našel diskusi různých IMAP serverů. Thread začíná tady. Mohli bychom udělat pokus se serverem dovecot. Mohli bychom nechat dosavadní formát mbox, takže uživatelé by si třeba ani nevšimli a dál by si vesele grepem hledali, co před lety sami napsali. mbox zůstane mboxem, kdo ví jestli by to pomohlo. Co když nutným předpokladem k efektivnějšímu zpracování pošty je právě přechod na maildir? V tom případě bychom uživatelům museli nabídnout samozřejmě nástroj na převod uložené pošty do nového formátu, ale taky nějaký vyhledávač, který by nahradil dosavadní přímé hledání v mboxech.

Než se pustíme do vyměňování IMAP serveru, rád bych si promyslel ještě jiné možnosti.

Nešlo by třeba poradit jádru, aby si udělalo větší buffery? Škoda že nevím jak. To jádro je 2.4.21-297-smp4G #1 SMP .

Já myslím, že zdaleka největší zatížení pochází od počátečního čtení INBOXů. Kdyby IMAP připojení bylo trvalé, tohle by přestalo a zase by se to začalo chovat mravně. Takže bychom potřebovali front end neboli fake IMAP server, který by napoprvé přijal počáteční požadavek od klienta a jen by zprostředkoval komunikaci mezi klientem a základním démonem. Po vyřízení požadavku by ale spojení neukončil, nýbrž by pár minut vyčkal. A kdyby mezitím dostal požadavek od stejného klienta, odfiltroval by počáteční autentizační část a potom by teprve zprostředkoval komunikaci.

Na webu vidím pár IMAP front endů, ale vesměs jsou orientovány na pokročilejší funkce - totiž na rozhození zátěže na klastr. Případně na odfiltrování jen autentizační části, ale ta nám to v našem případě nebrzdí (jak vidíme na nevelkém vytížení procesorů). Nějaký IMAP Front End se nabízí i k MS Exchange. No jasně, proto se MS poštovní klienti můžou přetrhnout, jak zběsile posílají požadavky. Aby se hodně kupovaly Exchange a k nim potřebné tuny železa.

IMAP front end jednoduché konstrukce, jak jsem se ho právě pokusil specifikovat, jsem v Internetu kupodivu nenašel. Asi jsem vymyslel úplnou hloupost.

       

Komentáře

[D-Evil]

Jsem v tomhle teda celkem amatér, ale zdá se mi neefektivní otvírat např. 200 MB soubor a hledat v něm třeba jen pár kilobajtů, v tomhle by asi maildir moh pomoct, soubory jsou indexovaný, takže se mi zdá, že zátěž by měla bejt menší.

Taky se mi zdá neefektivní při velkym počtu spojení používat xinetd - jestli se nepletu, při každym požadavku se pal spouští program, kterej ho obslouží. To je další zátěž pro disk a další zpomalení. Démon by asi svojí práci odvedl líp.

[Mobidick]

Souhlasim s tim,ze prechod na Maildir pomuze,resil jsem stejny problem a jako jedno z opatreni to znacne zvedlo pruchodnost imapu.

[..]

Kamarad google na dotaz co vi o imap proxy; odpovedel webem http://www.imapproxy.org kde lze najit - cituji :

What is the imapproxy?

The name says almost all you need to know. It proxies IMAP transactions between an IMAP client and an IMAP server. The general idea is that the client should never know that it's not talking to the real IMAP server.

Snad by Vam to mohlo pomoci, pri (velmi) zbeznem pohledu je to presne to co potrebujete.

[Dunric]

Podobný problém jsem asi před 2 lety řešil taktéž s UW-IMAPem a slabinou byl právě defaultně používaný formát mbox. Kupodivu stačilo nastavit způsob uložení do formátu mbx a nároky na zdroje serveru se prudce snížily a rovněž odezva pro klienty je znatelně lepší. IMAP lze překompilovat, aby používal MBX právě jako výchozí. Na bezproblémový převod schránek mbox -> mbx dobře poslouží nástroje z imap-utils, konkrétně mailutil.

[lenox]

Pripojuji se ke kritice formatu mbox...prechod na maildir vyrazne ulechci serveru.

Nasledne bych uvazoval o imapproxy ci dbmail

[Roman DAVID]

taky jsem se podobnou otazkou asi pred mesicem zabyval. Puvodne jsem mel umysl prejit na maildir, ale pak jsem si precetl o mbx a nevypada spatne (az na par nevyhod, ktere jsou uvedeny ve FAQ).

Co se tyka vykonu, kouknete na: http://www.decisionsoft.com/pdw/mailbench.html

Taky doporucuji ke cteni: http://www.washington.edu/imap/documentation/formats.txt.html (zejmena posledni cast, kde se pojednava o nevyhodach maildiru)

[Marek]

Můj názor je jednoznačně přechod na "maildir", "mbox" je silně neproduktivní ... otevírat X-set MByte pro čtení pár kByte ... to je přece nelogické, toť můj pohled.

Sám jsem to řešil a "maildir" problém vyřešil, uživatelé spokojeni a převod proběhl nějakou utilitkou mboxtomdir, nebo tak nějak.

[Heron]

Hmm v mail klientu (KMail) mám přes 300 000 mailů (rozdelené do cca 50složek) - maildir jsem zkusil, ale FS (ext3) to psychicky nezvládal, zvlášť při zálohování jsem měl pocit, že ta disková hlavička musí upadnout.

[Jan Kundrát (jkt)]

Jenom tak FMI, nejmenuje se nahodou onen server "sosna"? :)

[krnoha]

Když to víš tak proč se ptáš?

[Jan Kundrát (jkt)]

Protoze jsem to nevedel. Kdyz bych si byl jisty, tak bych se neptal :).

[Jan Kundrát (jkt)]

Take je dobre zminit, ze cast uzivatelu ma svuj $HOME (resp. mailboxy z nej) umisten na jinem stroji a pristupuje se k nemu pres NFS. Muze to nejak ovlivnit vykon?

Drobna poznamka - muj osobni a nicim nepodlozeny nazor je to, ze by zlepseni odezvy pomohlo i to, aby se Maple poustel nekde jinde a ne na onom serveru. Jiste, je to SMP stroj, ale stejne...

Dalsi poznamka - nekdy pred cca. rokem jsem se snazil prinutit pine spolupracovat s maildirem a pokud si dobre pamatuju, tehdy to "oficialni" verze jeste neumela.

A konecne posledni poznamka - celkem zajimave mi pripada pristupovani na IMAP pres SSH tunel. Uzivatel nepouziva standardni TCP/SSL, ale pres SSH si "sam" pusti IMAP demona. Zrejme to pouziva naprosto minimalni pocet lidi, ale je to vcelku zajimava myslenka - umoznuje pouzivat SSH klice etc. Bylo by dobre, aby tahle moznost zustala zachovana (resp. na onom serveru jsem ji jeste nezkousel, takze vlastne nevim, jestli funguje).

[krnoha]

Napřed děkuji za tip na imapproxy.org , tohle jsem myslím přesně potřeboval. Jinak podle mnoha názorů by nám pomohl jiný formát poštovních souborů. Každý jiný než klasický mbox bude lepší. Začneme si nějak hrát s formátem mbx. maildir se radši vyhneme, protože statisíce souborů každého ze stovek uživatelů, s tím by se docela špatně manipulovalo.

Začneme tou proxy. Jo a taky od xinetd přejdeme k démonovi. I když na tom vlastně nezáleží.