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