Диагностика утечек памяти 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 ₽ ежемесячно. Свяжитесь с нами, чтобы обсудить ваши задачи.