Come ridurre al minimo l'utilizzo della memory SpamAssassin (spamd)

Sto utilizzando SpamAssassin su Debian (la configuration predefinita con Pyzor, AWL e Bayes disabilitata e sa-compile abilitata) e ognuno dei processi figlio spamd consuma circa 100 a 150 MB di memory (circa 50 MB di memory reale) sui 32 bit e circa il doppio (abbastanza logico) sui server a 64 bit. Ci sono generalmente due processi figlio, ma in tempi occupati possono essere cinque (il massimo) in esecuzione.

ISTM che da 200 a 600 MB è molto memory per questo task. Vorrei continuare ad utilizzare SA come parte della mia struttura di filtraggio, ma sta diventando difficile giustificare così tanta memory.

Ci sono modi per ridurre la quantità di memory che each process figlio utilizza? (O in alternativa, fai un process di figlio singolo in modo veloce che posso impostare i bambini massimi a qualcosa di simile a 2?). Sono disposto a prendere in considerazione qualsiasi possibilità, inclusi quelli che possano o possono determinare una precisione ridotta.

Ho già letto la pagina "Out of Memory Problemi" della wiki SA ; nulla c'è di alcun uso. Messaggi di size superiori a 5 MB non vengono scansionati con SA.

5 Solutions collect form web for “Come ridurre al minimo l'utilizzo della memory SpamAssassin (spamd)”

Penso che tu sia incomprensione del modo in cui Linux comunica l'utilizzo della memory. Quando un process forks, si ottiene un secondo process che condivide molte risorse con il process originale. Incluso in questa è la memory. Tuttavia, Linux utilizza una tecnica nota come Copy On Write (COW) per questo. Ciò significa che each process figlio con forchetta vedrà gli stessi dati nella memory del process originale, ma each volta che questi dati cambiano (dal figlio o dal genitore), le modifiche vengono copiate e solo indicano una nuova posizione.

Fino a quando uno dei processi non modifica tali dati, essi condividono la stessa copia. Di conseguenza, potrei avere un process che utilizza 100MB di RAM, e forchetta 10 volte. Ciascuno di quei processi forgiati mostrerebbe l'utilizzo di 100 MB di RAM, ma se hai guardato l'utilizzo complessivo della memory sul box, potrebbe mostrare solo che 130 MB di RAM è in uso (100 MB condivisi tra i processi e più di un paio di MB di overhead , più altre dozzine MB o due per il resto del sistema).

Come esempio finale, ho una casella in questo momento con 30 processi apache in esecuzione. Ogni process mostra un utilizzo di 22 MB di RAM. Tuttavia, quando esegui libero -m per mostrare il mio utilizzo complessivo della RAM, ottengo:

topher@crucible:/tmp$ free -m total used free shared buffers cached Mem: 349 310 39 0 24 73 -/+ buffers/cache: 212 136 Swap: 511 51 460 

Come potete vedere, questa casella non ha nemless abbastanza RAM per eseguire 30 processi che utilizzavano ciascuno 18MB di RAM "reale". A less che tu non sia letteralmente esaurito dalla RAM o che le tue applicazioni stanno scambiando pesantemente, non mi preoccuperei delle cose.

UPDATE: Inoltre, controlla questo strumento chiamato smem , menzionato da jldugger nella risposta ad un'altra domanda sull'uso di memory Linux qui .

L'utilizzo di sa-compile potrebbe essere in grado di migliorare la velocità di corrispondenza di molte regole.

Ecco cosa ho fatto.

Ho un set-up where un sacco di messaggi tendono ad essere consegnati approssimativamente allo stesso tempo; per una serie di esperimenti ho eseguito SA sui messaggi che vengono copiati in una bobina temporanea e poi consegnati da un lavoro cron each cinque minuti.

spamd continuerebbe a printingre "forse dovresti aumentare il parametro max-children" e l'ho sollevata fino a 40 in un punto, ma ho avuto il server che consumava tutto il suo spazio di scambio e l'arresto.

Ora ho implementato un diverso regime in cui la consegna è regolata da un file di block Procmail. Poiché è stato semplice da fare, uso l'ultima cifra dell'ID del process e correre con 10 bambini. Non sono affatto sicuro che questo sia ottimale, ma ha già aiutato a evitare i picchi insidiosi di carico che ho sperimentato di volta in volta.

 LINEBUF=10240 # Grab last digit of PID for lockfile PID=$$ :0 * PID ?? ()\/[0-9]$ { D=$MATCH } :0 * > 512000 { SA="(too large)" } :0Ew:/tmp/20spamc.$D SA=| spamc -p 38783 -l -y 

Inoltre, ho avviato spamd con una serie di restrizioni ulimit . I numbers sono stati estratti da http://svn.apache.org/repos/asf/spamassassin/trunk/contrib/run-masses tranne che ho rimosso la restrizione ulimit -u . (Non so cosa sta succedendo, 32 è un po 'troppo piccolo in each caso … Con qualcosa di simile a 500 ho potuto tenere la spamd esecuzione per un po' di tempo, ma alla fine entrando nel limite.)

 ulimit -v 204800 ulimit -m 204800 ulimit -n 256 #ulimit -u 32 perl -T -I lib -w spamd --min-children 2 --max-children 10 --max-spare 5 etc etc 

Suppongo che finirò con i guasti di consegna se il carico è troppo alto per un tempo prolungato, ma finora sembra che sono riuscito a ridurre il carico a livelli gestibili con questo; e un sacco di consegne fallite è ancora molto meglio della macchina in esaurimento dello swap.

Le medie di carico elevato (a volte) sono un sintomo indiretto che la macchina sta esaurendo dalla RAM (e che utilizza molti processi di scambio CPU dalla memory virtuale), pertanto potrebbe provare a configurare il server di posta per non passare la posta tramite SpamAssassin se le medie di carico sono troppo alte.

Non si accenna a quale MTA si sta eseguendo, ma se stai chiamando SA da un elenco di controllo di accesso in exim4, allora il suggerimento nella parte inferiore di questo messaggio è efficace.

Inoltre, è ansible alleviare il carico su SA e ridurre così l'utilizzo della memory, mettendo in atto altri methods di filter anti-spam a basso impegno (in modo da elaborare e rifiutare alcuni spam prima di arrivare a SA) per esempio, il greylisting e il mittente verificano le chiamate utilizzano relativamente poco RAM.

Eravamo in una situazione simile parecchi mesi fa. SpamAssassin e ClamAV stavano usando un sacco di memory in un server ospitato. Avevamo la possibilità di aggiungere più memory al server, ma si è rivelato più costoso e più efficace per passare a Postini. YMMV.

Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.