OPcache на 1 ГБ: как 5500 сайтов падали из-за одного бага

Смотрел, что нового у вендоров, и увидел разбор про баг в OPcache у 5500 WordPress-сайтов — не DDoS, а воркеры PHP-FPM по 600 МБ из-за сброса кеша при обновлении Yoast SEO. Всё из-за одной настройки OPcache, которая разделяется между всеми сайтами на одном сервере.

Прочитал у Habr, что в одном кластере из 5500 WordPress-сайтов с PHP-FPM 8.4 и OPcache на 1 ГБ каждый новый воркер после сброса кеша тут же весил 600 МБ. Память кончалась, OOM-killer убивал базу и nginx, сайты падали каждые пять минут — не из-за ботов, а из-за того, как OPcache работает при массовом сбросе кеша. Уязвимость не в коде, а в архитектуре: один кеш на все сайты, и при обновлении плагинов в 467 из них — кеш сбрасывается, воркеры раздуваются, память растёт. Это не уязвимость в привычном смысле, но риск для любого сервера с таким настроенным OPcache.

На мой взгляд, ключевое здесь — не сам баг, а то, как он проявляется: не сразу, а через время, после обновлений. Система работает, пока не наступает сброс кеша. Это скрытый риск, который не видно в логах до падения. И самое опасное — что настройка OPcache по умолчанию у многих ведёт к такому поведению. Считаю, что это не просто ошибка конфигурации, а архитектурный дефект, который может привести к полному отказу сервиса.

У себя уже проверяю настройки OPcache у клиентов, где один пул PHP-FPM и общий кеш. Если в настройках стоит opcache.memory_consumption=1024 и opcache.validate_timestamps=1, а сайтов больше 100 — начинаю переписывать конфигурацию. Начинаю с резервной копии, потом разделяю кеш по сайтам или перехожу на отдельные пулы. Это не срочно, но в план на неделю включил — особенно у тех, кто использует Yoast SEO или другие плагины с частыми обновлениями.