Диагностика утечек памяти 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С-Битрикс.