Portál AbcLinuxu, 3. května 2025 10:22
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
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í.
grep 'imapd.*Login user=' | sort +6.0 -7.0
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
opravdu neukazuje nic podezřelého, jenom stovky imapů.
ps -ef
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.
Tiskni
Sdílej:
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.
25.1.2006 01:10
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
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).
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ží.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
24.1.2006 15:42