Rychlost spamassassinu
Jan Houstek
Jan.Houstek na mff.cuni.cz
Úterý Květen 31 11:14:35 CEST 2005
Ing. Pavel PaJaSoft Janoušek wrote:
>>No, řekl bych že přesně tolik, kolik jich povolím. Třeba
>>jedna nebo dvě.
>
> Řekněme při průměrné době zpracování se vším okolo (ta paměť je
> stále držena) cca 30s nám to dává propustnost pod 3.000,- mailů za den... -
> to není zrovna velký výkon...
Podle toho, co tady tvrdíte, se SA chová tak, že každá instance sežere
čtvrt giga paměti a pak deset vteřin čeká na výsledky nějakých dotazů na
blacklisty apod. V takovém případě si prostě nemůžete dovolit pustit víc
instancí, než kolik se vám do paměti vejde, a opravdu to bude omezovat
propustnost.
Řešením by bylo takto se chovající software nepoužívat, nebo ho nějak
umravnit, např. oddělit dlouho trvající čekací a paměťově nenáročnou
část od té výpočetní a náročné. Nebo ty dotazy na blacklisty nějak
efektivně kešovat.
> (třeba naše firma není zrovna velká organizace
> a přesto těch mailů proteče přes systém okolo 6.000) A co teprve nárazovky
> když vypadne linka a pošta je nějakou dobu na záložním MXku... A to vůbec
> radši nezmiňuji pitomá MTA jako nejmenovaný MS Exchange (včetně zřejmě MS
> Exchange 2003), který místo aby na dotyčné MXko (nebo smart host) to posílal
> serializovaně, tak to pošle klidně v 200 konkurentních socketech...:-)
Nárazy nejsou problém, podobně žravé content filtry se nedají rozumně
provozovat jinak, než že se mail přijme do fronty a ta se pak sekvenčně
zpracovává s pevně daným počtem paralelně běžících filtrů. Ve špičce se
pak stane akorát to, že budou ty maily ve frontě, a doručování bude
mírně zpožděné.
Filtrovat obsah přímo na úrovni SMTP, a nejlépe rovnou tak, že se obsah
skenuje průběžně, jak přichází po síti, má sice řadu výhod, ale je to
realizovatelné jen s filtrem, který nepožere půlku paměti serveru. V
opačném případě si koledujete o snadno proveditelný DoS útok.
-- Honza Houštek
Další informace o konferenci Linux