Практичний посібник: діагностика витоків пам'яті в 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 грн щомісяця. Зв'яжіться з нами, щоб обговорити ваші завдання.

Техпідтримка 1С-Бітрікс: з чого починається реальна допомога

Обмін з 1С через \Bitrix\Sale\Exchange зупинився в п'ятницю ввечері. Залишки на сайті — вчорашні, клієнти замовляють товар, якого немає. Менеджер пише в чат «1С не завантажується», але проблема — в PHP-процесі, який впав через memory_limit при імпорті 40 000 SKU. На діагностику та виправлення потрібно 20 хвилин, якщо знаєш, куди дивитися. Без підтримки — до понеділка сайт торгує повітрям. Ми — команда з 7-річним досвідом обслуговування проектів на 1С-Бітрікс. За цей час провели понад 50 успішних впроваджень і врятували не один сайт від простоїв.

Чому техпідтримка 1С-Бітрікс критична?

Бітрікс — живий продукт. Виходять патчі безпеки, змінюються версії модулів, кастомізовані рішення потребують сумісності. Чим довше сайт живе без обслуговування, тим вищий ризик:

• Вразливості. Бітрікс випустив патч для модуля vote (CVE-2022-XXXX). Без підтримки його ставлять «коли руки дійдуть» — через 3 місяці. За цей час сайт можуть зламати. Ми накочуємо критичні патчі протягом 48 годин — але тільки після перевірки на staging, тому що оновлення main до 24.x ламало CIBlockElement::GetList з кастомними властивостями.
• Ліцензія. Закінчилася — втрата доступу до оновлень та маркетплейсу. Відстежуємо терміни, повідомляємо за 60/30/14 днів.
• Моніторинг. Не просто «сайт пінгується». Перевіряємо ключові сценарії: додавання в кошик (sale.basket.add), оформлення замовлення, обмін з 1С, робота пошуку. Якщо API 1С повернув 500, а сторінка віддає 200 — пінг-моніторинг цього не побачить.
• Бекапи. Створюються автоматично, але хто перевіряє відновлення? Раз на квартал розгортаємо на тестовому сервері та прогоняємо smoke-тести.

Оновлення ядра раз на місяць знижує кількість вразливостей у 3 рази порівняно з щоквартальним підходом. Це не маркетинг — це статистика з нашої практики.

Що входить в техпідтримку 1С-Бітрікс?

Регулярні роботи (включені в абонент):

• Моніторинг: uptime + сценарії (кошик, замовлення, обмін 1С)
• Бекапи: pg_dump / mysqldump + rsync файлів → ізольоване сховище. Перевірка відновлюваності
• Оновлення ядра Бітрікс та модулів: \Bitrix\Main\ModuleManager::isModuleInstalled() — перевірка залежностей, накат на staging, тестування, деплой
• PHP та серверне ПЗ — оновлення на виділеному сервері. Перехід між мажорними версіями PHP — з перевіркою deprecated-викликів у кастомному коді
• Аналіз /bitrix/admin/event_log.php та серверних логів — превентивне усунення помилок
• SSL, домен — перевипуск та продовження
• Щомісячний звіт: що зробили, що знайшли, що рекомендуємо

Роботи за запитом (з годинного банку):

• Баги: «картка товару не відкривається на Safari» — діагностика, фікс, деплой
• Контент: банери, сторінки, категорії, товари
• Інтеграції: нова платіжка, нова доставка, новий маркетплейс (Wildberries API, Ozon Seller API)
• Оптимізація: CIBlockElement::GetList з 20 JOIN гальмує → рефакторинг на D7 ORM з фасетним індексом
• SEO-доробки: мета-теги, Schema.org, sitemap
• Консультації: «Який модуль Бітрікса обрати для розстрочки?»

Як ми оновлюємо ядро Бітрікс?

Оновлення — процес, що не терпить шаблонів. Спочатку перевіряємо сумісність кастомних модулів з новою версією \Bitrix\Main\Application. Якщо в коді використовуються deprecated-методи — фіксимо їх до деплою. Staging-оточення точна копія прода, включаючи налаштування кешування та черги агентів. Після тестів викочуємо, моніторимо логи error_log та подій. При найменшому відхиленні — відкат за 5 хвилин. — Інструкція з оновлення ядра на dev.1c-bitrix.ru

Які типові завдання вирішуємо в рамках техпідтримки?

Контент. Банери до «Чорної п'ятниці» — за день, тому що маркетолог згадав у четвер. Нова категорія з фільтрами через catalog.smart.filter. Лендінг під рекламну кампанію — з готових компонентів, без дизайнера, за 4-6 годин.

Функціонал. Поле «прикріпити файл» в form.result.new — 2 години. Форма запису на консультацію з інтеграцією в AmoCRM через webhook — 4-6 годин. Підключення JivoSite / Carrot Quest — 1-2 години.

Верстка. «Поїхав» блок на iPhone з Dynamic Island — Safari рендерить env(safe-area-inset-top) по-своєму. Оновили ядро Бітрікс — зламався CSS картки товару, тому що компонент catalog.element оновив HTML-структуру. Чинимо.

Інтеграції. Обмін з 1С: агент CAgent по catalog.import.1c впав по таймауту при 50 000 товарів — розбиваємо імпорт на пакети через STEP. API СДЕК оновився з v1.1 на v2 — переписуємо обробник sale.delivery.handler. Новий еквайринг — налаштовуємо sale.paysystem.handler.

Серверні. Перехід між мажорними версіями PHP: grep по deprecated (each(), create_function(), {$var} строковий доступ), фікс, тестування. SSL: certbot не продовжив — cron-задача не відпрацьовувала через зміну шляху до Python. DKIM/SPF/DMARC для поштового домену — щоб сповіщення про замовлення не потрапляли в спам.

Терміни та вартість

Вартість розраховується індивідуально під обсяг завдань. Додаткові години за ставкою з договору. Можлива зміна пакету: підвищення — в будь-який момент, пониження — з початку наступного місяця. Нестандартні вимоги обговорюємо окремо. Зв'яжіться з нами — підберемо оптимальний варіант.

Екстрена підтримка — коли горить

Сайт ліг, оплата не проходить, виявлено злам.

• Гаряча лінія — Telegram + телефон. Для преміум-клієнтів — виділений номер чергового інженера
• Реакція від 15 хвилин на критичні інциденти
• Поза чергою — критичні інциденти обробляються раніше поточних завдань, незалежно від залишку годин
• Постмортем — після усунення фіксуємо, що зламалося, чому і як запобігти. Документуємо в базі знань проекту

Замовте техпідтримку зараз — отримайте первинний аудит в подарунок та гарантію безперебійної роботи вашого проекту на 1С-Бітрікс.