PHP OPcache: настройка и оптимизация кэша байт-кода

Что такое PHP OPcache

PHP OPcache ускоряет выполнение PHP-скриптов, сохраняя скомпилированный байт-код в разделяемой памяти. При повторных запросах PHP пропускает этапы парсинга и компиляции, что даёт прирост скорости от 2 до 10 раз. OPcache включён в PHP 5.5+ и поставляется вместе с PHP — никакой отдельной установки не требуется.

Проверка статуса OPcache

php -r "echo opcache_get_status() ? 'Enabled' : 'Disabled';"

Или создайте файл /var/www/html/opcache-info.php:

<?php
$status = opcache_get_status();
echo "Memory used: " . round($status['memory_usage']['used_memory']/1024/1024) . " MB\n";
echo "Hit rate: " . round($status['opcache_statistics']['opcache_hit_rate'], 2) . "%\n";

Включение и настройка OPcache

Откройте файл /etc/php/8.2/fpm/php.ini или создайте /etc/php/8.2/mods-available/opcache.ini:

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.validate_timestamps=1
opcache.save_comments=1
opcache.fast_shutdown=1

Объяснение ключевых параметров

Оптимальные настройки для WordPress / Laravel

opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.revalidate_freq=0
opcache.validate_timestamps=0
opcache.interned_strings_buffer=16
opcache.jit=1255
opcache.jit_buffer_size=128M

JIT-компиляция в PHP 8.x

PHP 8.0+ поддерживает JIT (Just-In-Time) компиляцию поверх OPcache. Для CPU-интенсивных задач (обработка изображений, криптография, научные вычисления) JIT даёт дополнительное ускорение:

opcache.jit=1255
opcache.jit_buffer_size=128M

Сброс кэша OPcache

# Через PHP CLI
php -r "opcache_reset();"

# Перезагрузка PHP-FPM
sudo systemctl reload php8.2-fpm

# Через wp-cli (для WordPress)
wp cache flush

Реальные ошибки OPcache

Не хватает разделяемой памяти

PHP Warning:  PHP Startup: Unable to allocate shared memory segment of 268435456 bytes in Unknown on line 0

Чаще всего встречается в Docker-контейнерах: по умолчанию /dev/shm ограничен 64 МБ, а opcache.memory_consumption запрошен на 256 МБ. Решение — либо увеличить --shm-size у контейнера, либо снизить объём памяти под кэш до реально доступного.

Кэш незаметно переполнился

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

php -r "var_dump(opcache_get_status()['cache_full']);"
// bool(true) — кэш переполнен, новые скрипты компилируются заново на каждый запрос

Когда OPcache почти бесполезен

• Короткоживущие CLI-скрипты (одноразовые обработчики, cron-задачи в одну строку) — каждый запуск это новый процесс без общей памяти с предыдущим, кэшировать нечего. Поэтому opcache.enable_cli=0 стоит по умолчанию.
• Долгоживущие воркеры очередей — исключение из правила выше: если процесс живёт часами и переиспользует код, включённый opcache.enable_cli=1 для него полезен.
• Активная разработка с validate_timestamps=0 — изменения в файлах перестают подхватываться вовсе, а не с задержкой, что выглядит как «правка не применилась» и сбивает с толку до тех пор, пока не вспомнят про этот параметр.

Проверка результата

php -r '
$s = opcache_get_status();
echo "hit_rate: " . round($s["opcache_statistics"]["opcache_hit_rate"], 1) . "%\n";
echo "cache_full: " . var_export($s["cache_full"], true) . "\n";
echo "cached: " . $s["opcache_statistics"]["num_cached_scripts"] . "\n";
'

Если cache_full — true, поднимайте opcache.max_accelerated_files с запасом: посчитайте реальное число PHP-файлов проекта командой find . -name "*.php" | wc -l и берите значение как минимум вдвое больше. Для тонкой настройки JIT поверх OPcache смотрите отдельный разбор.

Держите значение с запасом хотя бы в полтора-два раза: рост числа файлов проекта после очередного обновления фреймворка или добавления новой библиотеки через Composer — обычное дело, и без запаса кэш снова переполнится буквально через пару релизов.