Высокое потребление памяти на сервере 1С приводит к снижению производительности, замедлению работы пользователей, увеличению времени выполнения запросов и фоновых заданий, а в тяжелых случаях — к аварийному завершению рабочих процессов rphost. При этом сама по себе большая цифра потребления памяти еще не означает наличие проблемы. Рабочие процессы 1С используют оперативную память в соответствии с текущей нагрузкой, и после выполнения тяжелой операции память не обязательно сразу возвращается операционной системе.
В этой статье наш партнер Андрей Бурмистров, эксперт в сфере оптимизации производительности 1С, разбирает основные причины высокого потребления памяти на сервере 1С. Показываем, в каких случаях необходимо искать проблему в прикладном коде, а в каких — анализировать саму платформу.
Собираем сведения о потреблении памяти
При анализе проблем с потреблением памяти в первую очередь нас интересуют процессы rphost и rmngr. В большинстве случаев основным потребителем оказывается именно rphost, поскольку рабочий процесс выполняет серверный код конфигурации и обрабатывает пользовательские вызовы.
Количество процессов rphost может быть больше одного, поэтому важно смотреть не только суммарное потребление памяти сервером, но и потребление каждого рабочего процесса отдельно.
Если на сервере находится несколько служб сервера 1С или несколько кластеров, то информация о том, какой именно процесс занял память, поможет сузить круг подозреваемых.
Например, в диспетчере задач видно, что память занимает процесс с ID 16084.
Кстати, на вкладке «Подробности» информация об используемой памяти более полная.
Теперь, зайдя в консоль кластера, можно быстро определить, к какому именно кластеру относится этот процесс.
В примере это «Локальный кластер», при этом в консоли отображается объем виртуальной выделенной памяти, которую ОС зарезервировала под этот рабочий процесс, что соответствует колонке «Выделенная память» на вкладке «Подробности».
Такой способ анализа является реактивным, если память уже занята, то далеко не всегда можно понять, в какой именно момент это произошло. Пользователь, который занял память, уже мог завершить сеанс, а память останется занятой, поэтому без регулярного мониторинга не обойтись. Чтобы понять, в какой момент память стала расти, необходимо использовать программы мониторинга вроде Zabbix, Prometheus + Grafana или специальные инструменты мониторинга для 1С, например, «Монитор».
Приходите на разбор частых проблем. 20 октября проведем вебинар «Что тормозит вашу 1С: разбор реальных причин».
Покажем, как с помощью «Монитора» перейти от реактивного поиска причин к постоянному контролю системы. Разберем работу инструмента, покажем, как анализировать долгие запросы, ожидания на блокировках, взаимоблокировки, ошибки технологического журнала и получать уведомления о проблемах.
20 октября, 12:00–13:00
Бонус для участников: час консультации с Андреем Бурмистровым по вопросам производительности и 30 дней триал‑версии «Монитора» с бесплатной установкой.
Андрей Бурмистров
эксперт в сфере оптимизации производительности 1С
Находим виновника
Все описанное выше можно увидеть в «Мониторе», а также узнать, кто из пользователей и в какой базе что запустил.
Счетчик Performance Monitor «Рабочий набор (частный)» соответствует значению колонки «Память» в диспетчере задач на вкладке «Процессы», то есть объем занятой физической оперативной памяти данным процессом. Счетчик «Байт исключительного пользования» соответствует колонке «Память» рабочего процесса в консоли кластера, это объем выделенной виртуальной памяти, которая может быть как в оперативной памяти, так и в файле подкачки.
На графике хорошо видно, в какой именно момент занятая память взлетела вверх, после чего физическая память стала постепенно освобождаться. Такое поведение является нормальным при запуске тяжелых операций. Обратите внимание, что объем виртуальной памяти не изменился, ОС резервирует это пространство на случай повторения высокого потребления.
Теперь необходимо найти причину роста памяти, для этого можно использовать либо данные сеансов, либо анализ серверных вызовов.
Сначала посмотрим на данные сеанса, добавив на график показатель «Сеанс: Текущая память Мб». В итоге видим, что в базе Demo пользователь с именем «Администратор» занял 5 128 Мб памяти.
Далее, используя журнал регистрации, можно посмотреть, что именно запускал этот пользователь.
Но при этом все равно будет непонятно, что именно внутри этой обработки привело к повышенному потреблению памяти.
Второй путь — анализ серверных вызовов.
Технологический журнал позволяет логировать события CALL (серверные вызовы), а у данного события есть свойство MemoryPeak (пиковое значение занятой памяти за вызов).
Добавив показатель «Серверный вызов» на график и указав в качестве оси Y значение «ПиковаяПамятьМб» можно увидеть источник этого вызова и сколько каких ресурсов он использовал.
В данном случае вызов был из внешней обработки, при этом длился чуть более двух минут. Занятая память в пике составила 7 079 Мб. Также здесь указана, какая именно серверная процедура вызывалась.
Если причина проблемы — запрос, который вернул большой объем информации, то это также можно увидеть на графике, добавив показатель «Долгий запрос». Если мы ожидаем увидеть запрос, вернувший большой объем, то в колонке «Ось Y» выбираем значение «ФактическоеЧислоСтрок». Такой запрос не обязательно должен быть долгий, в данном случае он выполнился за 13.5 секунд, все остальное время — это передача и обработка данных, так как он вернул почти 10 млн строк.
При расшифровке отображаются детали запроса и стек вызова.
Если запрос может вернуть объемный результат, то рекомендуется выполнять обход результата запроса.
Например:
РезультатЗапроса = Запрос.Выполнить(); ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать(); Пока ВыборкаДетальныеЗаписи.Следующий() Цикл // Вставить обработку выборки ВыборкаДетальныеЗаписи КонецЦикла;
Крайне не рекомендуется без острой необходимости выгружать результат запроса в таблицу значений, так как это приводит к повышенному расходу памяти, данные хранятся и в результате запроса, и в таблице.
Помимо запросов, большой объем памяти могут потреблять:
создание объемных коллекций,
помещение в хранилище значений объемных файлов,
чтение и обработка объемных файлов,
работа с большими блоками текста.
Следует помнить, что при помещении во временное хранилище данные сначала могут целиком размещаться в памяти rphost, а уже затем преобразовываться в поток данных и передаваться дальше.
Поэтому конструкции, которые выглядят безобидно на первый взгляд, на больших объемах могут приводить к существенному пиковому расходу памяти.
Утечки памяти
Гораздо серьезнее ситуация, когда занятая память продолжает плавно расти на протяжении всего дня и не выходит на плато и не освобождается, на графике виден постоянный рост. Скорее всего, это говорит об утечках памяти, расследовать такие инциденты гораздо сложнее, и этот процесс достоин отдельной статьи.
Проверяем, что проблема не связана с версией платформы
Хоть и редко, но бывает так, что проблема появилась после обновления платформы, в таком случае необходимо проверить наличие известных ошибок в используемой версии. Если есть возможность, можно откатить обновление и проверить, ушла ли ошибка.
Защита от слишком тяжелых серверных вызовов
В сервере уровня КОРП 1С предусмотрены механизмы управления нагрузкой кластера, в том числе параметр «Безопасный расход памяти за один вызов». Он предназначен для защиты рабочего сервера от вызова, который потребляет аномально большой объем памяти.
Параметр работает совместно с ограничениями на общий объем памяти рабочих процессов. В частности, при превышении установленного предела кластер может не допустить продолжение конкретного вызова, если расход памяти за этот вызов выходит за безопасный предел. Это позволяет ограничить последствия одного неудачного отчета или обработки для всего рабочего процесса.
Здесь важно понимать назначение этого механизма: он не устраняет причину высокого потребления памяти, а ограничивает последствия слишком тяжелого серверного вызова. Поэтому установка лимитов не должна заменять оптимизацию прикладного кода.
Если причину определить не удалось
Иногда мониторинг позволяет уверенно сказать только одно: rphost постоянно растет по памяти, но определить виновника штатными средствами не получается. В этом случае необходимо переходить к более глубокому анализу.
Один из инструментов — дамп процесса. Для Windows можно использовать ProcDump. В методических материалах 1С приведены рекомендации по снятию дампов рабочих процессов rphost, rmngr и ragent для последующего анализа.
Дамп позволяет получить значительно больше информации о состоянии процесса в конкретный момент времени, чем обычный мониторинг.
Для анализа подозрения на утечку памяти особенно полезно снять несколько дампов с интервалом во времени:
Дамп № 1 — через 10–30 минут Дамп № 2 — через 10–30 минут Дамп № 3
Если между дампами процесс продолжает расти, сравнение состояния памяти может помочь определить, какие объекты остаются в памяти.
В сложных случаях собранные дампы вместе с технологическим журналом и описанием проблемы можно передавать в службу поддержки 1С. Такой подход также рекомендуется в методических материалах 1С при неясной причине проблемы.
Заключение
Проблема высокого потребления памяти на сервере 1С редко решается простым увеличением объема оперативной памяти.
Если память растет скачками и затем возвращается к прежнему уровню, чаще всего необходимо искать тяжелую операцию: отчет, обработку, обмен или фоновое задание.
Если же память постепенно растет и причины неясны, то запускаем долгий и мучительный анализ утечек памяти.
Для успешного анализа такого рода проблем, необходимо постоянно иметь под рукой данные о том, какие сеансы сколько памяти потребляют, какие серверные вызовы выполняют и сколько именно памяти использует сейчас рабочий процесс.
Когда у вас на руках эти сведения, время анализа значительно сокращается, а виновника проблемы можно определить буквально за несколько минут.
Приходите на разбор частых проблем. 20 октября проведем вебинар «Что тормозит вашу 1С: разбор реальных причин».
Покажем, как с помощью «Монитора» перейти от реактивного поиска причин к постоянному контролю системы. Разберем работу инструмента, покажем, как анализировать долгие запросы, ожидания на блокировках, взаимоблокировки, ошибки технологического журнала и получать уведомления о проблемах.
20 октября, 12:00–13:00
Бонус для участников: час консультации с Андреем Бурмистровым по вопросам производительности и 30 дней триал‑версии «Монитора» с бесплатной установкой.
Андрей Бурмистров
эксперт в сфере оптимизации производительности 1С