ClamAV на BitrixVM ночью съедает память и валит сайт без 502

Ночью на BitrixVM сайт начинает тормозить или «молча» отваливаться. В мониторинге нет классического 502, в логах антивируса нет «Found virus» — а утром звонит клиент. Часто виноват не «баг Битрикс», а ночной clamscan: он загружает базы сигнатур и конкурирует с MySQL, nginx и PHP за те же гигабайты RAM.

Это capacity-инцидент, а не security-алерт «нашли malware». Патч движка ClamAV и запас памяти под скан — разные контуры: один не заменяет другой.

Как это выглядит на практике

На тесных VM порядка 2–4 ГБ RAM картина узнаваемая. Ночью растёт Load Average — в практике гайдов до порядка ~15, swap забит, сайт тормозит или недоступен без обязательного явного 502. В ps или top виден clamscan либо связанный cron, а админ узнаёт по жалобе клиента или по Load Average утром, а не по алерту «Infected files».

OOM Killer может убить mysqld, php-fpm, nginx или сам clam* — симптомы похожи на «хостинг лёг», но первопричина в пике памяти от антивирусного cron рядом с БД и вебом.

Не путайте слои: штатный веб-антивирус и «Поиск троянов» (xscan) в Битрикс — одно, OS-level ClamAV на хосте — другое. Здесь речь про системный скан.

Почему ночной скан убивает тесную BitrixVM

Официальные требования ClamAV (docs.clamav.net) для ClamScan/ClamD со стандартной базой Cisco CVD рекомендуют ≥3 GiB RAM. В Docker и ограниченных средах минимум тоже 3 GiB, предпочтительно 4 GiB; прямо указано, что 2 GB may be insufficient. Maintainer Cisco-Talos в issue #1254 формулирует жёстче: «2GB is not enough RAM to run ClamAV».

Ориентиры по памяти из docs:

• только загрузка сигнатур в engine — upwards of 1.2 GiB, ещё без учёта сканируемых файлов;
• при concurrent reload баз у clamd кратковременно ~2.4 GiB — новая engine рядом со старой;
• смягчение пика reload: ConcurrentDatabaseReload no в clamd.conf (сканы блокируются на время reload);
• смягчение пика freshclam: TestDatabases no в freshclam.conf (риск оставить битую базу).

BitrixVM из курса вендора поставляется со swap ~256 МБ; в части AMI swap может быть не подключён. На форуме BitrixVM без достаточного swap OOM уже убивал mysqld на тяжёлых операциях — тот же класс инцидента, что и ночной AV на тесной RAM.

Практик-гайды по VMBitrix описывают встроенный или настроенный ClamAV по cron как «быструю проверку»: на 2–4 ГБ clamscan (~1 ГБ под базы по их оценкам) плюс MySQL и web уходит в OOM или жёсткий swap. Утверждение «ClamAV из коробки во всех образах» в открытом learning course вендора отдельной карточкой не подтверждено — проверяйте на конкретной VM.

clamscan каждый запуск грузит CVD в RAM (community: ~600–900 MB сигнатур, на практике Bitrix-гайдов ~1 ГБ+), затем выгружает — отсюда повторные пики. Особенно опасен cron вида find … -exec clamscan. clamd с clamdscan держит базы тёплыми, работает быстрее; постоянный RSS community ~800 MB–1.1 GB, на 4 ГБ VPS daemon часто поднимают только на окно скана.

Гайды противоречат друг другу: low-mem CentOS — «не держите clamd постоянно»; ops-гайды на 4 ГБ — «берите clamdscan вместо clamscan». Выбор зависит от бюджета RAM и частоты сканов. Docs всё равно требуют порядка 3 GiB+ — не обещайте, что clamd «всегда легче» на 2 ГБ.

Где смотреть причину

Сначала пути и cron, не настройки Битрикс в админке:

• /etc/cron.d/bitrix-security — типичный файл security-cron (штатный шаблон или созданный гайдом установки; проверить ls);
• crontab -l, rpm -q clamav / clamscan --version;
• корень сайта: /home/bitrix/www;
• базы сигнатур: /var/lib/clamav (main.cvd / daily.cvd / bytecode.cvd);
• логи: /var/log/clamav/…, /var/log/clamav-scan-*.log.

Пример расписания из гайда установки ClamAV под Битрикс (факт гайда, не «официальный Битрикс»):

• 0 3 * * * — ежедневный bitrix-scan / clamscan-low-mem по /home/bitrix/www;
• 0 */4 * * * — find … -name "*.php" -mmin -240 -exec clamscan (частые пики: каждый вызов снова грузит БД);
• 0 2 * * 0 — weekly full clamscan -r;
• 0 1 * * * — freshclam.

В момент инцидента смотрите ps / top: есть ли clamscan/clamd, какой %MEM и runtime; available RAM и used swap в окне cron; dmesg / journalctl на строки OOM killer с жертвой mysqld/php-fpm/nginx/clam*. Лог скана читайте отдельно: были ли Infected files / FOUND — это другой тип алерта.

Что делать: стабилизировать скан, не «отключить безопасность»

Практичный порядок из практики гайдов и официальных требований:

1. На хостах 2–4 ГБ с swap ~256 МБ не гоняйте полный ночной clamscan -r / и частый find -exec clamscan рядом с MySQL без запаса swap/RAM.
2. В /etc/cron.d/bitrix-security отключите авто-сканы, оставьте обновление баз (freshclam); полный скан — вручную перед релизами, при необходимости после остановки тяжёлых служб.
3. Low-mem приёмы: nice -n 19 ionice -c 3 clamscan, лимиты --max-filesize / --max-scansize, exclude cache|tmp|\.git; на малой RAM сначала нарастите swap (гайд: ≥2 ГБ на хостах ~1.9 ГБ RAM).
4. Если выбран clamd на тесной RAM: ConcurrentDatabaseReload no, ExitOnOOM yes, MaxThreads 1, MaxQueue 2, ScanOnAccess no — и не ждите чудес на <3 GiB.
5. Патч движка отдельно: на 2026-08-13 Latest stable 1.5.4, LTS 1.4.6 (релизная дата файлов 2026-08-07). CVE-2026-20337 / CVE-2026-20338 (ZIP parser DoS, затронуты 1.5.0–1.5.3, фикс в 1.5.4). Патч ≠ «ночь без OOM».

Типичные ошибки: считать ночные тормоза багом Битрикс или хостинга, не открыв bitrix-security и ps; мониторить только «Infected files», игнорируя RAM/Load во время скана; оставить ConcurrentDatabaseReload по умолчанию на тесной RAM и получить двойной пик при обновлении баз; отключить сканы и забыть про CVD и патч движка.

Какие алерты ставить раньше жалобы клиента

Нужны два контура: capacity (скан жрёт хост) и security (находка malware / устаревший движок). Не смешивайте их в один триггер.

Практические условия — синтез источников, не готовый YAML:

1. Память/host: available RAM ниже порога + рост used swap ночью; корреляция с clamscan/clamd в top.
2. Процесс: появление clamscan, длительный runtime, высокий %MEM; spike Load Average в окне cron.
3. OOM: строки OOM killer в journal/dmesg с жертвой mysqld/php-fpm/nginx/clam*.
4. Результат скана: Infected files / FOUND в логе — отдельный security-alert.
5. Свежесть: версия < 1.5.4 (или LTS < 1.4.6) / возраст CVD / fail freshclam.
6. Доступность: HTTP check / TTFB в окне скана — даже без классического 502.

В Zabbix Agent 2 (практика гайдов под Bitrix) полезен item top-процессов, например UserParameter с ps -eo pcpu,pmem,user,comm,args --sort=-pcpu | head -n 11 — чтобы на дашборде было видно clamscan рядом с веб-стеком. Тяжёлый мониторинг на слабой VM сам усугубляет проблему: сначала стабилизируйте AV-cron.

Сюжет PHP-FPM listen queue и классический 502 — отдельная тема; здесь FPM/502 только как возможный побочный эффект OOM, не главный разбор.

Частые вопросы

Сколько RAM нужно ClamAV, чтобы ночной скан не валил BitrixVM?

Официально для ClamScan/ClamD со стандартной базой рекомендовано ≥3 GiB; загрузка сигнатур одна уже порядка 1.2 GiB, а concurrent reload у clamd кратковременно ~2.4 GiB. На VM 2–4 ГБ со swap ~256 МБ ночной clamscan рядом с MySQL/nginx/PHP часто уходит в OOM или жёсткий swap — 2 GB docs прямо считают недостаточными.

Где на BitrixVM искать ночной clamscan?

Смотрите /etc/cron.d/bitrix-security, затем crontab -l и процессы clamscan/clamd в top; базы обычно в /var/lib/clamav, логи — в /var/log/clamav/. Файл cron может быть и шаблоном, и созданным гайдом — проверяйте наличие на конкретной VM командой ls.

Почему сайт падает ночью без явного 502?

Пик RAM от clamscan приводит к swap/OOM: Load Average растёт, сайт тормозит или отваливается, а классического 502 может не быть. Это capacity-инцидент; алерт «Infected files» его не ловит — нужны метрики RAM, swap, top и journal на OOM.

Патч ClamAV 1.5.4 спасёт от ночного OOM?

Нет. 1.5.4 / LTS 1.4.6 закрывают DoS в ZIP-парсере (CVE-2026-20337, CVE-2026-20338) и относятся к свежести движка. Запас RAM под скан, расписание bitrix-security и отдельные алерты на память — отдельный контур; патч не заменяет capacity-алерт.

Как BX Pulse помогает раньше клиента

BX Pulse следит за доступностью и техническим состоянием проектов на 1С-Битрикс и помогает замечать деградацию в окне ночного скана — рост TTFB, просадки HTTP, аномалии до жалобы клиента. Добавьте первый сайт и настройте уведомления: https://bx-monitor.ru/.