Налаштування OPcache для 1С-Бітрікс

Наша компанія займається розробкою, підтримкою та обслуговуванням рішень на Бітрікс та Бітрікс24 будь-якої складності. Від простих односторінкових сайтів до складних інтернет-магазинів, CRM систем з інтеграцією 1С та телефонії. Досвід розробників підтверджено сертифікатами від вендора.
Пропоновані послуги
Показано 1 з 1 послугУсі 1626 послуг
Налаштування OPcache для 1С-Бітрікс
Проста
~1 робочий день
Часті питання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.png
    Розробка сайту компанії B2B ADVANCE
    1262
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Розробка веб-сайту для компанії ФІКСПЕР
    851
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    585
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    751
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    657
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    989

Налаштування OPcache для 1С-Bitrix

При першому запиті до сторінки Bitrix PHP читає, розбирає та компілює десятки файлів ядра. Без OPcache це відбувається при кожному запиті. З правильно налаштованим OPcache скомпільований байткод зберігається в спільній пам'яті — інтерпретатор пропускає етап компіляції та час відповіді падає в 3–5 разів.

Проблема не у ввімкненні OPcache — він ввімкнений за замовчуванням з PHP 5.5. Проблема у тому, що параметри за замовчуванням розраховані на «середньостатистичне» PHP-застосування, а не на Bitrix, де в одному запиті підключається 200–400 файлів.

Діагностика поточного стану

// Стан OPcache
$status = opcache_get_status();
echo "Кешовані файли: " . $status['opcache_statistics']['num_cached_scripts'] . "\n";
echo "Кеш повний: " . ($status['cache_full'] ? 'YES' : 'NO') . "\n";
echo "Hit rate: " . round($status['opcache_statistics']['opcache_hit_rate'], 2) . "%\n";
echo "Пам'ять використана: " . round($status['memory_usage']['used_memory'] / 1024 / 1024, 1) . " MB\n";
echo "Пам'ять вільна: " . round($status['memory_usage']['free_memory'] / 1024 / 1024, 1) . " MB\n";

Якщо cache_full = YES — OPcache заповнений, нові файли не кешуються. Якщо Hit rate нижче 90% — або пам'яті недостатньо, або часті перезапуски (розгортання).

Кількість PHP-файлів Bitrix на типовому проекті:

find /var/www/bitrix/bitrix -name "*.php" | wc -l
# Зазвичай 15000–40000 файлів

Правильні параметри OPcache для Bitrix

У файлі php.ini або /etc/php.d/10-opcache.ini:

[opcache]
opcache.enable = 1
opcache.enable_cli = 0

; Розмір пам'яті під байткод. Для Bitrix Enterprise — 256M, для Business — 128M
opcache.memory_consumption = 192

; Таблиця інтернованих рядків (імена функцій, класів, константи)
opcache.interned_strings_buffer = 16

; Максимум файлів у кеші. Повинен бути більший за реальну кількість PHP-файлів
opcache.max_accelerated_files = 32531

; Періодичність перевірки змін файлів на диску (секунди)
; На продакшені встановити 0 з ручним скидом при розгортанні
opcache.revalidate_freq = 60

; Не перевіряти часові мітки файлів (максимальна продуктивність)
; Потребує ручного скидання при розгортанні!
opcache.validate_timestamps = 0

; Оптимізації AST
opcache.optimization_level = 0x7FFEBFFF

; Збереження кешу між перезапусками PHP-FPM через спільну пам'ять
opcache.huge_code_pages = 1

; Шлях для файлового кешу (резервний, якщо спільна пам'ять переповнена)
opcache.file_cache = /tmp/opcache

; Не дозволяти скидання кешу з коду (безпечніше)
opcache.restrict_api = /var/www

validate_timestamps = 0 та розгортання

Це найбільш суперечливий параметр. При validate_timestamps = 0 OPcache ніколи не перевіряє, чи змінився файл на диску. Швидкість максимальна, але при оновленні коду зміни не застосовуються до перезагрузки PHP-FPM.

Скидання кешу після розгортання:

# Перезапуск PHP-FPM (надійно, але секунда простоя)
systemctl reload php8.1-fpm

# Програмний скид через CLI (PHP повинен бачити той самий OPcache)
php -r "opcache_reset();"
# Попередження: CLI-процес використовує окремий OPcache, якщо php-fpm запущений як демон

# Через HTTP-запит до спеціального скрипту (працює для FPM)
curl -s http://127.0.0.1/opcache_reset.php

Скрипт /var/www/bitrix/opcache_reset.php (доступ тільки з localhost):

<?php
if ($_SERVER['REMOTE_ADDR'] !== '127.0.0.1') {
    http_response_code(403);
    exit;
}
opcache_reset();
echo "OPcache скинувся OK\n";

opcache.huge_code_pages на Linux

На Linux з ядром 4.0+ можна розмістити кеш в huge pages (2 МБ замість 4 КБ), що знижує навантаження на TLB процесора:

# Виділити huge pages
echo 128 > /proc/sys/vm/nr_hugepages

# Додати в /etc/sysctl.conf для постійного ефекту
vm.nr_hugepages = 128

При ввімкненому opcache.huge_code_pages = 1 PHP автоматично використовує huge pages для кешу. Ефект ощутний на високонавантажених проектах — зменшення CPU на 5–15%.

Моніторинг у продакшені

Вбудована сторінка статусу OPcache від PHP-group:

# Завантажити офіційний скрипт
wget https://raw.githubusercontent.com/amnuts/opcache-gui/master/index.php \
  -O /var/www/bitrix/opcache-status.php
# Додати захист за IP або базову автентифікацію

Метрики для системи моніторингу через opcache_get_status():

  • hit_rate — має бути 95%+
  • cache_full — якщо true, збільшити memory_consumption
  • oom_restarts та hash_restarts — якщо ненульові, потрібна оптимізація параметрів