O ClamAV mantém as strings de pesquisa usando os algoritmos clássicos de string (Boyer Moore) e expressão regular (Aho Corasick). Sendo algoritmos da década de 1970, eles são extremamente eficientes em termos de memória.
O problema é o grande número de assinaturas de vírus. Isso faz com que as estruturas de dados dos algoritmos cresçam bastante.
Você não pode enviar essas estruturas de dados para trocar, pois não há partes das estruturas de dados dos algoritmos acessadas com menos frequência que outras partes. Se você forçar as páginas deles a trocarem o disco, eles serão referenciados momentos depois e simplesmente voltarão para o local. (Tecnicamente, dizemos que "o acesso aleatório da estrutura de dados força toda a estrutura de dados a estar no conjunto de memória do processo) ".)
As estruturas de dados são necessárias se você estiver digitalizando a partir da linha de comando ou digitalizando a partir de um daemon.
Você não pode usar apenas uma parte das assinaturas de vírus, pois você não pode escolher quais vírus você será enviado e, portanto, não saberá quais assinaturas precisará.
Aqui está a memória usada em uma máquina de 32 bits rodando Debian Wheezy e é clamd.
# ps_mem.py
Private + Shared = RAM used Program
281.7 MiB + 422.5 KiB = 282.1 MiB clamd
Editar: vejo alguém sugerindo configurar o tamanho do conjunto de residentes. Se isso for bem sucedido, ter um tamanho de conjunto residente menor que o tamanho do conjunto de trabalho levará o processo a ser debatido de e para a troca. Isso reduzirá substancialmente todo o desempenho do sistema. Em qualquer caso, a página de manual do Linux para setrlimit (RLIMIT_RSS, ...) diz que configurar o tamanho do conjunto residente não é mais suportado e nunca teve nenhum efeito em processos que optaram por não chamar o dispositivo (MADV_WILLNEED, ...). p>