Comment réduire l'utilisation de la mémoire SpamAssassin (spamd)

J'utilise SpamAssassin sur Debian (la configuration par défaut avec Pyzor, AWL et Bayes désactivés et sa-compile activée), et chacun des processus enfants spamd consomme environ 100 à 150 Mo de mémoire (environ 50 Mo de mémoire réelle) sur le 32 serveurs bit, et environ le double (assez logiquement) sur les serveurs 64 bits. Il existe généralement deux processus enfants, mais en période de pointe, il peut y avoir cinq (maximum) en cours d'exécution.

ISTM que 200 à 600 Mo est beaucoup de mémoire pour cette tâche. J'aimerais continuer à utiliser SA dans le cadre de ma structure de filtrage, mais il devient difficile de justifier autant de mémoire.

Existe-t-il des moyens de réduire la quantité de mémoire utilisée par chaque processus enfant? (Ou alternativement, rendre un processus enfant unique si rapide que je peux définir le nombre maximal d'enfants à quelque chose comme 2?). Je suis prêt à considérer toutes les options, y compris celles qui entraîneront ou pourraient entraîner une précision réduite.

J'ai déjà lu la page "Problèmes de mémoire insuffisante" sur le wiki SA ; rien n'y sert. Les messages supérieurs à 5 Mo ne sont pas analysés avec SA.

Je pense que vous comprenez mal la façon dont Linux rapporte l'utilisation de la mémoire. Lorsqu'un processus bifurque, il en résulte un second processus qui partage beaucoup de ressources avec le processus d'origine. La mémoire y est incluse. Cependant, Linux utilise pour cela une technique connue sous le nom de Copy On Write (COW). Cela signifie que chaque processus enfant forké verra les mêmes données en mémoire que le processus d'origine, mais chaque fois que ces données changent (par l'enfant ou le parent), les modifications sont copiées et pointent ensuite vers un nouvel emplacement.

Jusqu'à ce que l'un des processus modifie ces données, ils partagent la même copie. En conséquence, je pourrais avoir un processus qui utilise 100 Mo de RAM et le débiter 10 fois. Chacun de ces processus bifurqués afficherait 100 Mo de RAM utilisés, mais si vous regardez l'utilisation globale de la mémoire sur la boîte, cela pourrait seulement montrer que 130 Mo de RAM sont utilisés (100 Mo partagés entre les processus, plus quelques Mo de surcharge) , plus une douzaine de Mo ou deux pour le reste du système).

Comme dernier exemple, j'ai une boîte en ce moment avec 30 processus apache en cours d'exécution. Chaque processus montre une utilisation de 22 Mo de RAM. Cependant, lorsque j'exécute free -m pour afficher mon utilisation globale de la RAM, j'obtiens:

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

Comme vous pouvez le voir, cette boîte n'a même pas assez de RAM pour exécuter 30 processus qui utilisaient chacun 18 Mo de RAM «réelle». À moins que vous ne manquiez littéralement de RAM ou que vos applications changent considérablement, je ne m'inquiéterais pas des choses.

MISE À JOUR: Consultez également cet outil appelé smem , mentionné par jldugger dans la réponse à une autre question sur l'utilisation de la mémoire Linux ici .

En utilisant sa-compile, vous pourrez peut-être améliorer la vitesse de correspondance de nombreuses règles.

Voici ce que j'ai fait.

J'ai une configuration où beaucoup de messages ont tendance à être livrés à peu près en même temps; pour une série d'expériences, j'exécute SA sur des messages qui sont copiés dans une bobine temporaire puis livrés par un travail cron toutes les cinq minutes.

spamd continuerait à imprimer "peut-être que vous devriez augmenter le paramètre max-children" et je l'avais augmenté jusqu'à 40 à un moment donné, mais j'avais le serveur consommant tout son espace de swap et se bloquant.

Maintenant, j'ai mis en place un régime différent où la livraison est régie par un fichier de verrouillage Procmail. Parce que c'était simple à faire, j'utilise simplement le dernier chiffre de l'ID de processus et je cours avec 10 enfants. Je ne suis pas du tout sûr que ce soit optimal, mais cela a déjà contribué à éviter les pics de charge insensés que je ressentais de temps en temps.

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

De plus, je démarre spamdavec un certain nombre de ulimitrestrictions. Les chiffres ont été retirés de http://svn.apache.org/repos/asf/spamassassin/trunk/contrib/run-masses sauf que j'ai supprimé la ulimit -urestriction. (Je ne suis pas sûr de ce qui se passe. 32 est de toute façon trop petit. Avec quelque chose comme 500, je pourrais continuer à spamdcourir pendant un certain temps, mais finir par atteindre la 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

Je suppose que je vais me retrouver avec des échecs de livraison si la charge est trop élevée pendant une longue période, mais jusqu'à présent, il semble que j'ai réussi à réduire la charge à des niveaux gérables avec cela; et un tas de livraisons échouées est encore beaucoup mieux que la machine à court de swap.

Les moyennes de charge élevées sont (parfois) un symptôme indirect que votre machine manque de RAM (et utilise beaucoup de processus d'échange de CPU dans les deux sens depuis la mémoire virtuelle), vous pouvez donc essayer de configurer votre serveur de messagerie pour ne pas transmettre de courrier via SpamAssassin si le les moyennes de charge sont trop élevées.

Vous ne mentionnez pas le MTA que vous exécutez, mais si vous appelez SA à partir d'une liste de contrôle d'accès dans exim4, la suggestion au bas de ce message est efficace.

En outre, vous pouvez alléger la charge de SA, et ainsi réduire son utilisation de la mémoire, en y plaçant d'autres méthodes de filtrage du spam moins gourmandes en ressources (c'est-à-dire afin qu'elles traitent et rejettent du spam avant qu'il ne parvienne à SA) par exemple, la liste grise et l'expéditeur vérifient que les légendes utilisent relativement peu de RAM.

Nous étions dans une situation similaire il y a plusieurs mois. SpamAssassin et ClamAV utilisaient beaucoup de mémoire sur un serveur hébergé. Nous avions la possibilité d'ajouter plus de mémoire au serveur, mais il s'est avéré plus rentable et plus économique de passer à Postini. YMMV.