До основного вмісту

PHP OPcache: налаштування та оптимізація кешу байт-коду

PHP · 19.04.2026 · 3 хв читання
Ілюстрація до статті «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

Пояснення ключових параметрів

ПараметрЗначенняОпис
memory_consumption128–512 МБОбсяг RAM під кеш байт-коду
max_accelerated_files4000–100000Максимум кешованих файлів
revalidate_freq0 (prod) / 2 (dev)Частота перевірки змін файлів (сек)
validate_timestamps0 (prod) / 1 (dev)Чи перевіряти дату зміни файлів
Для production: встановіть validate_timestamps=0 та revalidate_freq=0 — це максимальна швидкість. Після деплою коду скидайте кеш командою php -r "opcache_reset();" або перезавантаженням PHP-FPM.

Оптимальні налаштування для 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
JIT не прискорює звичайні вебзастосунки (WordPress, Laravel) суттєво — вони обмежені I/O, а не CPU. Вмикайте JIT лише тоді, коли ваші застосунки справді CPU-bound.

Скидання кешу 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 — зміни у файлах перестають підхоплюватися взагалі, а не із затримкою, що виглядає як «правка не застосувалася» і збиває з пантелику, доки не згадають про цей параметр.

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

Поле статусуНорма
opcache_hit_rateВище 95%
cache_fullfalse
num_cached_scriptsБлизько до загальної кількості PHP-файлів проєкту
php -r '
$s = opcache_get_status();
echo "hit_rate: " . round($s["opcache_statistics"]["opcache_hit_rate"], 1) . "%
";
echo "cache_full: " . var_export($s["cache_full"], true) . "
";
echo "cached: " . $s["opcache_statistics"]["num_cached_scripts"] . "
";
'

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

Тримайте значення із запасом хоча б у півтора-два рази: зростання кількості файлів проєкту після чергового оновлення фреймворку чи додавання нової бібліотеки через Composer — звичайна справа, і без запасу кеш знову переповниться буквально через пару релізів.

Чи була стаття корисною?
← Назад до бази знань Поставити питання підтримці