lassú qmail?

Linux-haladó

lassú qmail?

  • 681 megtekintés

( nzmark | 2006. 01. 11., sze – 16:33 )

Felraktam egy sun dual opteronos gépre egy gentoo linuxot, szépen amd64-re optimalizálva, szakít is rendesen.
http://www.shupp.org/toaster/ leírás alapján a qmail-t is fölraktam, spam és vírusszűréssel + vpopmail támogatással. ez is megy szépen. elkezdtem tesztelni a postal progival, és a cactival monitoroztam a gép és a qmail állapotát.
a helyzet az, hogy eléggé csalódott vagyok, mert percenként csak olyan 500levelet fogadott (450-535). a qmail queue-ban pedig folyamatosan gyűltek a levelek (simán fölmet 10.000fölé), és csak szépen lassan komótosan rakta ki a postafiókba. mi lehet a gond? mivel lehetne gyorsítani? növeltem a kiszolgáló processzek számát (spamd) ezzel picit gyorsabb is lett, de azért én lényegesen jobb eredményt vártam volna.

( 1aca | 2006. 01. 11., sze – 17:53 )

[quote:d308b6304a="nzmark"]Felraktam egy sun dual opteronos gépre egy gentoo linuxot, szépen amd64-re optimalizálva, szakít is rendesen.
http://www.shupp.org/toaster/ leírás alapján a qmail-t is fölraktam, spam és vírusszűréssel + vpopmail támogatással. ez is megy szépen. elkezdtem tesztelni a postal progival, és a cactival monitoroztam a gép és a qmail állapotát.
a helyzet az, hogy eléggé csalódott vagyok, mert percenként csak olyan 500levelet fogadott (450-535). a qmail queue-ban pedig folyamatosan gyűltek a levelek (simán fölmet 10.000fölé), és csak szépen lassan komótosan rakta ki a postafiókba. mi lehet a gond? mivel lehetne gyorsítani? növeltem a kiszolgáló processzek számát (spamd) ezzel picit gyorsabb is lett, de azért én lényegesen jobb eredményt vártam volna.

Nem tudom, pontosan hogyan futtatod. De remlik valami, hogy valahol ki lehetett kacsolni, hogy ne probaljon IDENT-elni minden connection-re. Az tuti felgyorsitja. Persze csak ha be van kapcsolva nalad :)

Ja igen. a tcp-env -nek kellett -R opciot adni.

( Ago | 2006. 01. 11., sze – 18:07 )

vagy válthatsz postfixre :) nem ismerem a leírást és nem is néztem meg, de nem lehet, hogy a spamszűrő mindenféle hálózati ellenőrzéseket is végez? Mondjuk megpróbálja a neveet visszaoldani, 5-6 szűrőlistához nyúlni stb. Esetleg segíthet egy caching DNS-t teszel fel. Ha már DJB, akkor ott a dnscache a cr.yp.to-ról szintén. Vagy bind is megfelel. Csak cachelj. Az is tud dobni a dolgokon. A már említett ident-re én nem emlékszem vagy ahol qmail volt a kérés - azért mindenhol megpróbáltam ilyen esetben is váltásra bírni a cégeket :) - ott kikapcsoltam. Az ember viszi magával az egyszer jól beállított gépek alapján előállított beállító scriptjeit és csak adaptál pár értéket a helyi környezetre :) A másik, hogy a qmail elég I/O intenzív tud lenni és I/O szempontból nem a legjobban teljesítő mta. A RAID5 egyes esetekben halál tud lenni egy mta queue számára.

( bajnokk | 2006. 01. 11., sze – 18:16 )

Nézd meg, hogy nem silly qmail syndrome-od van-e. A www.nrg4u.com oldalon van patch (ext-todo). Ha gondolod (és tudod, hogy szükséged van rá), használhatod a big-todo patchet is (az ext-todo-val együtt is akár).

Ezen kívül lehet trükközni a szokásos dolgokkal: gyorsabb I/O, fájlrendszer, stb.

( FoREE | 2006. 01. 11., sze – 19:06 )

sztem probakepp kapcsold ki a spamfiltert es ugy is nezd meg, mielott barmi massal probalkoznal

( nzmark | 2006. 01. 11., sze – 19:11 )

azt hiszem a hw erőforrással nem lehet gond. 2opteron, 4GB ram, hw scsi raid az fs pedig reiserFS. ezzel tuti nincs gond. helyi hálózaton van, helyi hálózaton lévő dns-t használ, és a postal is egy IP-ről támadta, aminek szintén van reverse bejegyzése. a gondom nekem az volt, hogy a leveleket fogadta, de nem tuta olyan ütemben feldolgozni, ahogyan érkeztek ezért szépen a queue-ban gyűjtögette és egyesével szórta ki onnan a leveleket. (ezt csak én gondolom, hogy egyesével)
egyetlen levelet sem utasított vissza, csak éppen a queue -ból a levelek nem olyan ütemben fogytak, mint ahogyan ezt én elvártam volna egy ilyen géptől. azt hiszem a vas bőven el tudta volna viselni, ha szimultán több levelet ellenőriz, egyszerre több levelet próbál a címzettjének eljuttatni helyben a spamd-n és a clamav-on keresztül. ezt nem lehet valahol állítani, hogy ne egyesével dolgozza fel a leveleket, hanem álljon neki többnek egyszerre? simscant használok.
elvégre 2proci van benne, tehát minimum 2szálon csinálhatná, de akár 20levéllel is elbírna egyszerrre.

( nzmark | 2006. 01. 16., h – 10:13 )

[quote:bfbbb24dc4="bajnokk"]A silly qmail szindrómának pont az a lényege, hogy ha túl gyorsan érkeznek a levelek, akkor a qmail-send-nek nincs ideje elindítani a kézbesítést.
Ha a qmail-ed loggol, akkor nagyon egyszerűen láthatod, hogy hány párhuzamos kézbesítést futtat. Az SQS-nél ez úgy néz ki, hogy általában csak 1-2-t, aztán felmegy 70-re (apropó, mennyi is nálad a concurrencylocal?), de gyorsan megint visszaesik.

ez a silly patch melyik qmailt patcholja? az eredetit, vagy egy már patcholt qmail is megfoltoz? csak mert én netqmailt használok, az meg egy erősen foltozgatott qmail.
a concurrencylocal értékének drasztikus változtatása sem okoz semmilyen változást a teszt eredményében. 10-100-ig 10-esével végigpróbáltam, de a queue nagyon gyorsan növekszik bármire is állítom. a status local csak 1/100 vagy 0/100 értéket vesz fel.

( gyorffy | 2006. 01. 11., sze – 22:40 )

[quote:c6b2254f1b="nzmark"]Felraktam egy sun dual opteronos gépre egy gentoo linuxot, szépen amd64-re optimalizálva, szakít is rendesen.
http://www.shupp.org/toaster/ leírás alapján a qmail-t is fölraktam, spam és vírusszűréssel + vpopmail támogatással. ez is megy szépen. elkezdtem tesztelni a postal progival, és a cactival monitoroztam a gép és a qmail állapotát.
a helyzet az, hogy eléggé csalódott vagyok, mert percenként csak olyan 500levelet fogadott (450-535). a qmail queue-ban pedig folyamatosan gyűltek a levelek (simán fölmet 10.000fölé), és csak szépen lassan komótosan rakta ki a postafiókba. mi lehet a gond? mivel lehetne gyorsítani? növeltem a kiszolgáló processzek számát (spamd) ezzel picit gyorsabb is lett, de azért én lényegesen jobb eredményt vártam volna.

Szerintem lehet, hogy valamit el k.rtál. Esetleg ha ajánlhatok egy másik toaster-es megoldást. http://www.tnpi.biz/internet/mail/toaster/
Én ezt használom és nagyon bejön.:)

( bajnokk | 2006. 01. 12., cs – 06:50 )

[quote:e448beb94b="nzmark"]azt hiszem a hw erőforrással nem lehet gond. 2opteron, 4GB ram, hw scsi raid az fs pedig reiserFS. ezzel tuti nincs gond. helyi hálózaton van, helyi hálózaton lévő dns-t használ, és a postal is egy IP-ről támadta, aminek szintén van reverse bejegyzése. a gondom nekem az volt, hogy a leveleket fogadta, de nem tuta olyan ütemben feldolgozni, ahogyan érkeztek ezért szépen a queue-ban gyűjtögette és egyesével szórta ki onnan a leveleket. (ezt csak én gondolom, hogy egyesével)

A silly qmail szindrómának pont az a lényege, hogy ha túl gyorsan érkeznek a levelek, akkor a qmail-send-nek nincs ideje elindítani a kézbesítést.
Ha a qmail-ed loggol, akkor nagyon egyszerűen láthatod, hogy hány párhuzamos kézbesítést futtat. Az SQS-nél ez úgy néz ki, hogy általában csak 1-2-t, aztán felmegy 70-re (apropó, mennyi is nálad a concurrencylocal?), de gyorsan megint visszaesik.