Практичний посібник: діагностика витоків пам'яті в 1С-Бітрікс

Коли на сервері з 8 ГБ RAM запускається імпорт з 1С, пам'ять може вичерпатися за 15 хвилин, якщо не налаштовано моніторинг

Вдень, при піковому навантаженні, сайт починає гальмувати або видавати 503. Найчастіше справа в нестачі оперативної пам'яті у PHP-FPM воркерів. Кожен запит споживає пам'ять, і якщо воркери не встигають звільняти її, сервер йде у своп. Ми розберемо, як відстежити проблему та налаштувати моніторинг, щоб уникнути простоїв.

Наш досвід — понад 10 років роботи з Бітрікс та 50+ проектів з оптимізації. Ми перебрали десятки конфігурацій і виробили методику, яка знижує споживання RAM на 20–30% без втрати швидкості.

Чому пам'ять — вузьке місце в Бітрікс?

PHP не розділяє пам'ять між воркерами: кожен процес-воркер живе своїм життям. При pm.max_children = 50 і середньому споживанні 128 МБ на воркер — це 6,4 ГБ тільки під PHP. До цього додаються системні процеси, база даних (MySQL), веб-сервер. Якщо сума перевищує доступну RAM, вмикається своп, і час відповіді зростає в рази.

Основні ненажерливі операції:

• Імпорт через CommerceML (файли XML читаються повністю, воркер може набрати 300+ МБ).
• Складні вибірки з інфоблоків без обмежень (CIBlockElement::GetList() без фільтра).
• Сторонні модулі з витоками (статичні властивості, не очищені глобальні масиви).
• Нескинутий кеш на рівні PHP (managed_cache + memcached дублює дані).

Як діагностувати споживання?

На системному рівні найпростіше дивитися RSS кожного воркера:

ps aux --sort=-%mem | grep php-fpm | awk '{sum += $6} END {print sum/1024 " MB"}' 

Або детально: ps aux | grep php-fpm | awk '{print $6/1024 " MB\t" $11}'.

У коді можна поставити діагностику в OnEndBufferContent, як у прикладі нижче. Це ловить важкі сторінки без навантаження на систему.

// Показує пік споживання за час запиту $peak = memory_get_peak_usage(true); if ($peak > 64 * 1024 * 1024) { // > 64 МБ \Bitrix\Main\Diag\Debug::writeToFile( sprintf('Peak memory: %.1f MB, URI: %s', $peak / 1048576, $_SERVER['REQUEST_URI']), 'MEM_HIGH', '/local/logs/memory.log' ); } 

Для постійного моніторингу використовуємо стек Prometheus + node_exporter + Grafana. Метрика node_memory_MemAvailable_bytes показує вільну пам'ять. Алерт при падінні нижче 512 МБ змусить вас реагувати до того, як сайт впаде.

- alert: LowMemory expr: node_memory_MemAvailable_bytes < 536870912 for: 5m annotations: summary: "Low RAM on {{ $labels.instance }}" 

Як знизити споживання на 30%?

Один із найефективніших параметрів — pm.max_requests. Він змушує воркер перезапускатися після N запитів, скидаючи можливі витоки. Для проектів з імпортами та сторонніми модулями ставимо 200–500. Налаштування pm.max_requests дає зниження RAM на 20–30%, що вдвічі ефективніше, ніж просте обмеження memory_limit (10–15%).

Другий — обмеження memory_limit. Ми рекомендуємо 256 МБ для типового сайту. Цього достатньо для 95% операцій, а важкі імпорти можна винести в окремі агенти з лімітом 512 МБ.

Третій — кешування. Якщо включити теговане кешування в інфоблоках і вимкнути дублювання в managed_cache, економія пам'яті складе 10–15%.

Порівняємо підходи:

Згідно з документацією 1С-Бітрікс, оптимальний memory_limit для типового сайту — 256 МБ. Однак для важких операцій рекомендується збільшувати ліміт в окремих агентах.

Кейс з нашої практики: інтернет-магазин з щоденним імпортом

До нас звернувся власник інтернет-магазину на Бітрікс, де імпорт з 1С запускався о 02:00. Після імпорту кілька воркерів залишалися з RSS 250–300 МБ, і сервер (8 ГБ) йшов у своп. Вранці до 07:00 сайт працював із затримками.

Ми з'ясували, що pm.max_requests був 0, тобто воркери не перезапускалися. Встановили pm.max_requests = 200, обмежили memory_limit до 256 МБ (був 512). Підсумок: роздуті воркери вмирали після 200 запитів, пам'ять поверталася системі. Сайт перестав гальмувати, а час імпорту скоротився на 15% завдяки меншій кількості свопу. Завдяки цьому налаштуванню клієнт скоротив витрати на оренду сервера на 25 000 грн на місяць.

Що входить в послугу?

При замовленні моніторингу та оптимізації пам'яті ми:

1. Аналізуємо поточну конфігурацію PHP-FPM, кешування, навантаження — проводимо аудит продуктивності.
2. Налаштовуємо збір метрик (Prometheus + node_exporter).
3. Оптимізуємо параметри pm, memory_limit, кешування.
4. Додаємо діагностику в код (логування піків).
5. Навчаємо команду користуватися дашбордами та алертами.
6. Надаємо звіт з рекомендаціями та гарантуємо покращення.

Терміни орієнтовно

Діагностика та налаштування займають від 2 до 5 робочих днів залежно від складності проекту. Вартість розраховується індивідуально після аналізу поточної конфігурації.

Типові помилки при налаштуванні пам'яті

Одна з частих помилок — надто високий параметр pm.max_children, що призводить до перевищення RAM та свопу. Також не рекомендується встановлювати однаковий memory_limit для всіх запитів, оскільки важкі операції вбивають воркери. Відсутність моніторингу призводить до того, що витоки помічають лише коли сайт падає. Не тегований кеш дублює дані, витрачаючи пам'ять.

Отримайте консультацію інженера — оцінимо вашу конфігурацію безкоштовно. Замовте аудит продуктивності вашого Бітрікс-проекту — ми знайдемо вузькі місця та запропонуємо рішення. Якщо ви помічаєте гальмування сайту, зв'яжіться з нами для безкоштовної консультації.

Силки: Налаштування PHP-FPM, Управління кешем Бітрікс, Wikipedia: PHP-FPM.

Швидке налаштування моніторингу пам'яті

Додамо ще один приклад: налаштування простого моніторингу через pm.status_path. Увімкніть у пулі PHP-FPM параметр pm.status_path = /status, потім запитуйте метрики скриптом або через Prometheus exporter. Це дає кількість активних воркерів та середнє споживання.

У середньому, оптимізація пам'яті дозволяє економити від 10 000 до 30 000 грн щомісяця. Зв'яжіться з нами, щоб обговорити ваші завдання.