Мониторинг потребления оперативной памяти 1С-Битрикс

Мониторинг потребления оперативной памяти 1С-Битрикс

PHP — процессовая модель: каждый запрос запускает новый PHP-FPM воркер, и каждый воркер потребляет RAM независимо. При pm.max_children = 50 и 64 МБ на воркер — это уже 3,2 ГБ только под PHP. На практике Битрикс-запросы с тяжёлыми компонентами (импорт из 1С, формирование прайс-листов, сложные отчёты) потребляют 128–256 МБ. Если сервер начинает использовать своп, время ответа деградирует в разы.

Что потребляет память в Битрикс

Главные источники роста RSS воркеров:

• Импорт из 1С через CommerceML — CCatalogImport загружает XML целиком в память. При файлах > 50 МБ воркер легко набирает 200–300 МБ.
• Операции с инфоблоком — CIBlockElement::GetList() без nTopCount возвращает весь результат сразу.
• Кэш в памяти — если включён managed_cache (memcached), локальная копия данных в PHP-процессе дублирует кэш.
• Утечки в сторонних модулях — статические свойства, глобальные массивы, накапливающиеся за жизнь воркера при pm.max_requests = 0.

Инструменты мониторинга

Системный уровень — каждые несколько секунд:

# Суммарная память по PHP-FPM процессам
ps aux --sort=-%mem | grep php-fpm | awk '{sum += $6} END {print sum/1024 " MB"}'

# Детально по каждому воркеру
ps aux | grep php-fpm | grep -v grep | awk '{print $6/1024 " MB\t" $11}'

PHP memory_limit — диагностика в коде:

// Показывает пик потребления за жизнь запроса
$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'
    );
}

Этот код добавляем в OnEndBufferContent — так покрываем все запросы без инструментальных накладных расходов.

Prometheus + node_exporter + Grafana:

# prometheus.yml scrape config
- job_name: node
  static_configs:
    - targets: ['localhost:9100']

Метрика node_memory_MemAvailable_bytes — свободная память. Алерт при падении ниже 512 МБ:

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

PHP-FPM: параметры под контроль

Ключевые параметры в /etc/php/8.1/fpm/pool.d/bitrix.conf:

pm = dynamic
pm.max_children = 30         ; не больше (RAM - 1GB) / avg_worker_memory
pm.max_requests = 500        ; перезапускаем воркер после 500 запросов (защита от утечек)
pm.process_idle_timeout = 30s

; Статус-страница для мониторинга
pm.status_path = /php-fpm-status

pm.max_requests = 500 — воркер перезапускается после 500 запросов, сбрасывая любые утечки памяти. При нормальном коде это не нужно, но сторонние модули Битрикс иногда накапливают статику.

Кейс: сайт с ежедневным импортом

Интернет-магазин, импорт из 1С в 02:00 через cron_events. После импорта несколько PHP-FPM воркеров оставались с RSS 250–300 МБ, сервер (8 ГБ) уходил в своп, утром до 07:00 сайт тормозил.

Диагностика: max_requests был 0, воркеры с раздутой памятью не перезапускались. pm.max_requests = 200 и ограничение memory_limit = 256M (было 512M) решили проблему: раздутые воркеры умирали после 200 запросов, память возвращалась системе.