ClamAV contient les chaînes de recherche à l'aide des algorithmes de chaîne classique (Boyer Moore) et d'expression régulière (Aho Corasick). Étant des algorithmes des années 1970, ils sont extrêmement efficaces en mémoire.
Le problème est le grand nombre de signatures de virus. Cela entraîne une augmentation assez importante des infrastructures de données des algorithmes.
Vous ne pouvez pas envoyer ces infrastructures de données à échanger, car aucune partie des infrastructures de données des algorithmes n'est utilisée moins souvent que les autres. Si vous en forcez des pages à échanger le disque, elles seront référencées quelques instants plus tard et reviendront juste directement dedans. ".)
Les infrastructures de données sont nécessaires si vous numérisez à partir de la ligne de commande ou numérisez à partir d'un démon.
Vous ne pouvez pas utiliser seulement une partie des signatures de virus, car vous ne pouvez pas choisir les virus qui vous seront envoyés et ne pouvez donc pas savoir de quelles signatures vous aurez besoin.
Voici la mémoire utilisée sur une machine 32 bits exécutant Debian Wheezy et c'est clamd.
# ps_mem.py
Private + Shared = RAM used Program
281.7 MiB + 422.5 KiB = 282.1 MiB clamd
Edit: je vois que quelqu'un suggère de définir la taille de l'ensemble résident. Si cela réussit, le fait d'avoir une taille de jeu résidente inférieure à la taille du jeu de travail entraînera le thrashing du processus vers et depuis le swap. Cela réduira considérablement l'ensemble des performances du système. Dans tous les cas, la page de manuel Linux pour setrlimit (RLIMIT_RSS, ...) indique que la définition de la taille de l'ensemble résident n'est plus prise en charge et n'a jamais eu d'effet sur les processus qui ont choisi de ne pas appeler madvise (MADV_WILLNEED, ...).