Как минимизировать использование памяти SpamAssassin (spamd)

Я использую SpamAssassin в Debian (конфигурация по умолчанию с отключенными Pyzor, AWL и Bayes и включенной sa-compile), и каждый из дочерних процессов spamd потребляет от 100 до 150 МБ памяти (около 50 МБ реальной памяти) на 32 бит-серверы, и примерно вдвое больше (достаточно логично) на 64-битных серверах. Обычно есть два дочерних процесса, но в загруженное время может быть запущено пять (максимум).

ISTM, что от 200 до 600 МБ много памяти для этой задачи. Я хотел бы продолжить использовать SA как часть моей структуры фильтрации, но становится все труднее оправдать так много памяти.

Есть ли способы уменьшить объем памяти, который использует каждый дочерний процесс? (Или, в качестве альтернативы, сделайте один дочерний процесс настолько быстрым, чтобы я мог установить максимальное количество дочерних элементов примерно в 2?). Я готов рассмотреть любые варианты, в том числе те, которые приведут или могут привести к снижению точности.

Я уже читал страницу "Проблемы с памятью" в вики SA ; ничто там не имеет никакого смысла. Сообщения размером более 5 МБ не сканируются с помощью SA.

Я думаю, вы неправильно понимаете, как Linux сообщает об использовании памяти. Когда процесс разветвляется, это приводит ко второму процессу, который разделяет много ресурсов с исходным процессом. В это входит память. Однако в Linux для этого используется метод, известный как Copy On Write (COW). Это означает, что каждый разветвленный дочерний процесс будет видеть в памяти те же данные, что и исходный процесс, но всякий раз, когда эти данные изменяются (дочерним или родительским), изменения копируются и только после этого указывают на новое местоположение.

Пока один из процессов не внесет изменения в эти данные, они совместно используют одну и ту же копию. В результате у меня может быть процесс, который использует 100 МБ ОЗУ, и разветвляюсь 10 раз. Каждый из этих разветвленных процессов будет показывать 100 МБ используемой оперативной памяти, но если вы посмотрите на общее использование памяти на коробке, это может показать только то, что используется 130 МБ оперативной памяти (100 МБ совместно используются процессами, плюс несколько МБ служебных данных , плюс еще дюжина МБ или два для остальной части системы).

В качестве последнего примера у меня сейчас есть окно с 30 запущенными процессами Apache. Каждый процесс показывает использование 22 МБ ОЗУ. Однако, когда я запускаю free -m, чтобы показать общее использование ОЗУ, я получаю:

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

Как видите, в этом блоке даже недостаточно оперативной памяти для запуска 30 процессов, каждый из которых использовал 18 МБ «реальной» оперативной памяти. Если у вас буквально не хватает ОЗУ или если ваши приложения сильно меняются, я бы об этом не беспокоился.

ОБНОВЛЕНИЕ: Также ознакомьтесь с этим инструментом под названием smem , упомянутым jldugger в ответе на другой вопрос об использовании памяти Linux здесь .

Используя sa-compile, вы сможете улучшить скорость сопоставления многих правил.

Вот что я сделал.

У меня есть установка, в которой много сообщений обычно доставляются примерно одновременно; для серии экспериментов я запускаю SA для сообщений, которые копируются во временную папку и затем доставляются заданием cron каждые пять минут.

spamd продолжал печатать «возможно, вам следует увеличить параметр max-children», и я поднял его до 40 в один момент, но у меня был сервер, потребляющий все пространство подкачки и сбой.

Теперь я реализовал другой режим, когда доставка управляется файлом блокировки Procmail. Поскольку это было просто сделать, я просто использую последнюю цифру идентификатора процесса и работаю с 10 дочерними элементами. Я совсем не уверен, что это оптимально, но это уже помогло избежать безумных пиков нагрузки, которые я время от времени испытывал.

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

Кроме того, я запускаю spamdс рядом ulimitограничений. Цифры были взяты из http://svn.apache.org/repos/asf/spamassassin/trunk/contrib/run-masses, за исключением того, что я снял ulimit -uограничение. (Не уверен, что происходит. 32 слишком мало в любом случае. С чем-то вроде 500 я мог бы продолжать spamdработать некоторое время, но в конечном итоге столкнулся с лимитом.)

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

Я полагаю, что в конечном итоге произойдут сбои доставки, если нагрузка будет слишком высокой в ​​течение длительного времени, но пока мне кажется, что мне удалось снизить нагрузку до управляемых уровней; и куча неудачных поставок все еще намного лучше, чем машина, на которой заканчивается своп.

Средние значения высокой нагрузки (иногда) являются косвенным признаком того, что на вашей машине заканчивается ОЗУ (и используется много процессов подкачки ЦП назад и вперед из виртуальной памяти), поэтому вы можете попробовать настроить почтовый сервер так, чтобы он не пропускал почту через SpamAssassin, если средние нагрузки слишком высоки.

Вы не упоминаете, какой MTA вы используете, но если вы вызываете SA из списка контроля доступа в exim4, то предложение в нижней части этого сообщения будет эффективным.

Кроме того, вы можете уменьшить нагрузку на SA и, таким образом, уменьшить ее использование памяти, поместив перед ней некоторые другие, менее ресурсоемкие методы фильтрации спама (т. Е. Чтобы они обрабатывали и отклоняли спам до того, как он попадет в SA) - например, вызовы серого списка и проверки отправителя используют относительно мало оперативной памяти.

Мы были в похожей ситуации несколько месяцев назад. SpamAssassin и ClamAV использовали много памяти на размещенном сервере. У нас была возможность добавить больше памяти на сервер, но оказалось, что переключиться на Postini оказалось более экономичным и эффективным по времени. YMMV.