[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: spamd/spamc ewig lahm



Gruesse!
* Rainer Bendig aka Ny <lists@unresolvedissue.org> schrieb am [26.11.04 19:40]:
 
> > Mir ging es auch nicht um die Erkennungsrate, da hast  du mich scheinbar
> > missverstanden. bogofilter _ist_ ein eigenstaendiger  Spamfilter. Wenn
> > bogofilter Spam findet braucht fuer diese Mail keine Anfrage and den 
> > spamd gestellt werden, ergo keine 5-10 Sek. Aufgabe.

> spam -> fetchmail -> procmail -> bogo -> /dev/null
> spam -> fetchmail -> procmail -> bogo -> sa -> /dev/null
>  ham -> fetchmail -> procmail -> bogo -> sa -> procmail ->filesystem
> 
> Sprich die ham - Mails werden noch immer von spam assassin gescannt.

Meinst du mit ham jetzt irrtuemlich von spamfiltern als Spam erkannte 
Mails oder die "normale" Mail. Aber egal...

(fetchmail u. procmail lasse ich mal weg)
spam 		-> bogo (erkennt Spam)  -> /dev/null
email/ham 	-> bogo (Mail ok) 	-> $postfach

Nur fuer Mails, die bogo nicht eindeutig erkennt (wird im Header als 
Unsure deklariert) wird dann sa aufgerufen.

Rechne dir doch aus: wenn bogo pro Mail 1s braucht und hochgegriffen am 
Anfang 15% Unsure findet und nur fuer diese sa aufruft, ist die 
Laufzeit bei deinem Mailaufkommen doch wesentlich geringer. 

> Und letztendlich reissen es 2 - 3 Sekunden bei ein paar Spams am Tag
> eh nicht mehr raus... so dass ich _aktuell_ noch ohne bogofilter leben
> kann. Denn die restlichen tausenden von Mails werden dann so oder so
> noch durch SA geschleift.

Das ist wie gesagt falsch. Oder unnoetig. Mit bogofilter kannst SA auch
ganz  weglassen. Aber bei manchen Spams ist SA halt besser, weil die
Tests  umfangreicher sind.

Das ist wohl auch der Grund des Ursprungsproblems, warum SA pro Mail 
solange braucht. Ich habe hier (gerade wenn ich per fetchmail viele
Mails hole) bei Mails die durch SA gehen teilweise auch Scanzeiten um 
die 20-30s pro Mail. Wobei meine Load dann riesig hochschnellt.

Je nachdem, wie stark dein Rechner waehrend des Scannens ausgelastet ist 
und wie professionell/kritisch das ganze ist, waere evtl. noch die 
Option, die Anzahl der gleichzeitigen spamd-Childs hochzusetzten (wobei 
das auch nach hinten losgehen kann, aber evtl. die fetchmail-Zeit 
verkuerzt). Oder einen zweiten Rechner hinstellen, auf dem der spamd 
ausschliesslich laeuft.

Ich habe im Log fuer heute gerade nochmal nachgeschaut: fuer 170 Mails 
mit ISDN brauche ich genau 5 Minuten ab fetchmail start bis die letzte 
Mail durch procmail durch ist. Das ist inklusive Virenscanning mit 
amavis.

Gruss
    Gerhard



Reply to: