Почему /var/lib/rspamd в mailcow растёт из-за файлов Hyperscan и что можно чистить без риска

Если /var/lib/rspamd в вашем mailcow растёт быстрее, чем объём почты, а виновники — файлы с расширениями .hs и .hsmp, вы наткнулись на известную особенность Hyperscan-кэша Rspamd. Разбираю, откуда берутся эти файлы, почему история issue #5232 из 2023 года не переносится один в один на текущие версии, и что можно чистить без риска сломать антиспам.

Симптом в «АвторЛаб»: /var/lib/rspamd растёт, а писем не прибавилось

Самиздат-лаб «АвторЛаб» — 21 рабочее место, свой mailcow на выделенном сервере, который мы обслуживаем на аутсорсе корпоративной почты уже второй год. В конце августа сработал алерт мониторинга: раздел под docker-volume почтового стека набрал 78 % занятости, хотя число ящиков и объём переписки за месяц почти не изменились — редакция небольшая, потоки писем стабильные, ничего похожего на резкий рост нагрузки не было.

Первым делом смотрю, что именно растёт: du -sh /var/lib/docker/volumes/*rspamd-vol-1*/_data показал больше 1,1 ГБ, из которых основная масса — файлы с расширениями .hs и .hsmp. Для сравнения: сама рабочая конфигурация Rspamd (правила, карты, локальные оверрайды) занимает считаные мегабайты. У «АвторЛаб» стоит относительно свежий mailcow — релиз 2026-07b «Mooly», где Rspamd 4.1.4 (пришёл ещё в 2026-07a) зафиксирован прямо в docker-compose.yml образом ghcr.io/mailcow/rspamd:4.1.4-1 — так что списывать всё на древнюю версию не получалось, и я решил разобраться по порядку, а не действовать по старым рецептам из форумов.

Администратор клиента к тому моменту уже нашёл в поиске старое обсуждение с похожими симптомами и предлагал снести всё содержимое каталога скриптом. Я попросил подождать: .hs-файлы — это не мусор в привычном смысле, а скомпилированные базы для движка сопоставления регулярных выражений Hyperscan, и прежде чем что-то удалять, стоило понять, зачем они вообще появляются и что говорит про них официальная документация именно для той версии Rspamd, которая стоит у клиента.

Что такое .hs-файлы и почему Rspamd вообще кэширует их на диске

Rspamd проверяет каждое письмо по сотням регулярных выражений — правила, RBL-паттерны, эвристики антиспама. Сравнивать письмо с каждым выражением по очереди слишком медленно, поэтому там, где это возможно, Rspamd компилирует наборы regex в единую базу движка Hyperscan (или его открытого форка Vectorscan, который работает и на ARM) — это на порядок ускоряет сопоставление, но сама компиляция ресурсоёмкая и небыстрая операция, которую невыгодно повторять при каждом старте воркера.

Поэтому скомпилированные базы кэшируются на диске: по официальной документации Rspamd (раздел Common options) за это отвечают два параметра — hs_cache_dir, задающий каталог, куда сохраняется кэш Hyperscan, и disable_hyperscan, который полностью отключает оптимизации Hyperscan, если они были включены при сборке. Оба параметра актуальны и в текущей документации, задаются в local.d/options.inc, и по умолчанию, если явно не переопределить hs_cache_dir, кэш пишется в рабочий каталог Rspamd — то есть именно туда, куда у mailcow смонтирован именованный volume rspamd-vol-1:/var/lib/rspamd.

Важный нюанс, который я проверил отдельно: официальный FAQ Rspamd прямо называет эти файлы платформенно-зависимым кэшем — при переносе установки на другой сервер рекомендуется удалить *.hs и *.hsmp из /var/lib/rspamd, потому что скомпилированные под одну архитектуру и версию движка базы не переносятся между хостами и пересоздаются заново на новом месте. Это прямое подтверждение того, что сами по себе эти файлы — кэш, а не источник истины: удалить и потерять что-то безвозвратно через них нельзя, в худшем случае Rspamd потратит время на повторную компиляцию.

Issue #5232: что там произошло и почему это не «баг, который когда-нибудь починят»

История, на которую наткнулся администратор «АвторЛаб», — это issue #5232 в репозитории mailcow-dockerized на GitHub. Автор сообщал, что на mailcow 2023-04b с Rspamd 3.5 выделенный под /var/lib/rspamd раздел в 500 МБ забивался примерно за неделю: он насчитал 628 файлов по маске .hs и оценил суммарный объём .hs/.map/.hsmc/.hsmp примерно в 473 МБ — то есть почти весь выделенный лимит съедался служебным кэшем, а не почтой. В качестве обхода автор написал скрипт, который периодически удалял накопившиеся файлы кэша вручную.

Я специально проверил статус этого issue перед тем, как что-то советовать клиенту: он закрыт мейнтейнерами с пометкой «not planned» и меткой «stale» — то есть команда mailcow не стала чинить это как баг конкретно в своём образе. Это логично: сама механика кэширования Hyperscan — часть Rspamd, а не mailcow, и на момент issue (Rspamd 3.5, весна 2023 года) это было ожидаемым поведением движка, а не дефектом сборки контейнера. Урок отсюда простой: цифры из #5232 — это фотография конкретной установки трёхлетней давности на конкретной версии, а не универсальный ориентир для любого mailcow сегодня.

Ключевая ошибка, которую я вижу у администраторов, которые находят это issue сейчас в 2026 году: они переносят цифры «628 файлов, 473 МБ за неделю» на свою инсталляцию один в один, даже не сверив версию Rspamd. У «АвторЛаб» весь кэш за несколько месяцев работы набрал чуть больше 1,1 ГБ — заметно, но без той скорости роста, что описана в issue, и это не случайность, а прямое следствие того, что архитектура кэширования Hyperscan в Rspamd с тех пор менялась.

Что изменилось в Rspamd 4.0+ и почему старый отчёт нельзя переносить буквально

В changelog релиза Rspamd 4.0.0 прямо описана переработка этого механизма: компиляция и кэширование Hyperscan перенесены на асинхронный Lua-бэкенд с поддержкой общей базы данных на Redis между воркерами и хостами. Помимо смены транспорта, там же заявлен «self-healing cache» — механизм, который сам обнаруживает устаревшие (stale) blob-объекты кэша и запускает их перекомпиляцию, а не оставляет копиться версию за версией, как это могло происходить раньше. Небольшие базы правил при этом вовсе компилируются в памяти без записи на диск.

На практике это значит, что сама причина неконтролируемого накопления файлов, которую видел автор #5232 на Rspamd 3.5, — судя по описанию автора, при каждой пересборке правил появлялись новые файлы кэша, а устаревшие не подчищались — в версиях 4.0 и новее архитектурно ослаблена: обнаружение и перекомпиляция устаревших объектов теперь встроены в сам механизм кэша, а не оставлены полностью на усмотрение внешней очистки. У «АвторЛаб» стоит Rspamd 4.1.4 — то есть уже на новой архитектуре кэша, что и объясняет, почему рост объёма оказался куда скромнее, чем в оригинальном отчёте трёхлетней давности.

Уточню сразу: Redis-часть self-healing-кэша в changelog описана как поддержка общей базы между воркерами и хостами, а не как жёстко обязательное условие работы Hyperscan вообще — если в вашей инсталляции Redis для Rspamd уже настроен (а в mailcow он обычно есть — тот же Redis использует и антиспам-статистика Bayes, и часть других модулей; мы разбирали похожую тему в статье про миграцию на форк Redis), самообслуживание кэша работает во всей полноте. Если у вас старая инсталляция без Redis или явно урезанная конфигурация — поведение стоит проверить отдельно в своей версии, не полагаясь на общее описание из changelog.

Что проверить перед тем, как что-то удалять руками

Первое, что я делаю на любом сервере с похожей жалобой, — смотрю версию Rspamd, а не сразу лезу чистить диск. docker compose exec rspamd-mailcow rspamd --version (или docker-compose exec rspamd-mailcow rspamd --version на старом Compose v1) сразу показывает, с какой архитектурой кэша вы имеете дело — 3.x без self-healing или 4.0+ с ним. Дальше смотрю раскладку по типам файлов, а не только общий объём каталога:

docker compose exec rspamd-mailcow sh -c "cd /var/lib/rspamd && ls -la *.hs *.hsmp 2>/dev/null | wc -l && du -ch *.hs *.hsmp 2>/dev/null | tail -1"

Это даёт число файлов и их суммарный вес отдельно от всего остального, что лежит в /var/lib/rspamd — а там кроме Hyperscan-кэша могут быть база fuzzy-хранилища, файлы статистики Bayes (если она не полностью перенесена в Redis) и другие служебные данные, которые удалять точно нельзя. Проверяю также, не переопределён ли hs_cache_dir в data/conf/rspamd/local.d/options.inc — если кто-то раньше уже вручную поменял путь кэша или выставил disable_hyperscan, диагностика и решение будут другими, и я не хочу давать совет «просто удалите файлы», не убедившись, что каталог, который я смотрю, — это действительно активный кэш, а не забытая копия.

Что можно чистить без риска, а что лучше не трогать

По официальному FAQ Rspamd файлы *.hs и *.hsmp в /var/lib/rspamd прямо названы платформенно-зависимым кэшем, который пересоздаётся заново — это единственная формулировка из документации, на которую я готов опираться, когда советую клиенту что-то удалить на проде. Автор issue #5232 в своём обходном скрипте чистил заодно *.map и *.hsmc, но официального подтверждения, что любые файлы с такими расширениями в этом каталоге — всегда безопасный кэш, а не что-то ещё, я не нашёл, поэтому клиентам рекомендую действовать по документированному минимуму, а не копировать чужой скрипт один в один.

У «АвторЛаб» на проде это выглядело так: остановил контейнер, чтобы исключить параллельную запись во время операции, убедился, что /var/lib/rspamd смонтирован именно как том rspamd-vol-1, и почистил только подтверждённые файлы кэша прямо на томе хоста — в остановленный контейнер exec уже не зайдёт (имя тома зависит от COMPOSE_PROJECT_NAME в mailcow.conf, у стандартной установки это mailcowdockerized_rspamd-vol-1):

cd /opt/mailcow-dockerized
VOL=$(docker volume inspect -f '{{ .Mountpoint }}' mailcowdockerized_rspamd-vol-1)
docker compose stop rspamd-mailcow
find "$VOL" -maxdepth 1 \( -name '*.hs' -o -name '*.hsmp' \) -print -delete
docker compose start rspamd-mailcow

После запуска Rspamd тихо пересобрал нужные базы заново по мере обращения к правилам — никаких ошибок в логе воркера, rspamadm configtest отработал чисто, а объём /var/lib/rspamd вместо 1,1 ГБ стал около 90 МБ и дальше рос уже плавно, без всплесков. Ту же логику «не трогать то, что не подтверждено документацией как безопасный кэш» я применяю и в других похожих ситуациях — например, при чистке кэша обновлений Windows, о которой писал отдельно: там тоже часть каталогов можно удалить без последствий, а часть трогать не стоит, и разница определяется тем, что именно там хранится, а не общим ощущением «это же просто кэш».

Как я теперь это мониторю на проде клиента

Раздутый Hyperscan-кэш ведёт себя тихо: не роняет доставку почты, не выдаёт ошибок в типовых проверках здоровья mailcow, а просто ест место на диске, пока в какой-то момент это не совпадёт по времени с плановым обновлением или ростом ящиков и не превратится в аврал. Поэтому у «АвторЛаб» я добавил в ежеквартальный регламент обслуживания отдельную строку — размер rspamd-vol-1 наравне с проверкой vmail и базы данных, а алерт на нехватку места перевёл с процентов на абсолютные гигабайты: 2 ГБ свободных — это мало для любой аварийной операции, даже если это формально 10 % от раздела.

Отдельно я держу в голове версию Rspamd, которая приходит с каждым апдейтом mailcow — сверяюсь с release notes вроде «Mooly» (2026-07b) перед накатыванием обновления и слежу, не появилось ли в changelog Rspamd новых изменений в работе с кэшем: последующие минорные релизы продолжают дорабатывать этот механизм, и то, что верно для 4.1.4 сегодня, не обязано быть верным для следующей минорной версии без проверки. Такой же принцип «сверять регламент с актуальной версией, а не с тем, что было три года назад» я закладываю во все клиентские регламенты по mailcow — например, в общем регламенте эксплуатации mailcow, который веду отдельно, разбираю бэкапы, обновления и антиспам как единый цикл, а не набор разовых действий по мере поступления жалоб.

Итог по «АвторЛаб»: диск больше не растёт бесконтрольно, мониторинг ловит аномалию задолго до критичного заполнения, а сам инцидент занял час разбора и пять минут на выполнение команд — против нескольких часов, которые ушли бы на панику и слепое копирование чужого скрипта без понимания, что именно он делает на конкретной версии Rspamd.

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