Як мінімізувати використання пам'яті SpamAssassin (спам)

Я використовую SpamAssassin на Debian (конфігурація за замовчуванням з Pyzor, AWL та Bayes вимкнена, і включена sa-компіляція), і кожен із спам-дочірніх процесів споживає близько 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 Мб оперативної пам’яті. Однак, коли я запускаю безкоштовно -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-компіляцію, ви зможете покращити швидкість узгодження багатьох правил.

Ось що я зробив.

У мене є налаштування, де багато повідомлень, як правило, надсилаються приблизно за один і той же час; для серії експериментів я запускаю SA над повідомленнями, які копіюються у тимчасову котушку, а потім доставляються за допомогою крон кожні п’ять хвилин.

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.