Проблема, когда один «простаивающий» пользователь резервирует под свой сеанс несколько гигабайт оперативной памяти, является одной из самых сложных задач для администратора 1С. Когда в распоряжении нет специализированных инструментов вроде Центр управления производительностью (ЦУП) или Контроль исполнения регламентных заданий (KIP), приходится действовать «подручными» средствами. Давайте вместе разберем, как локализовать причину этого явления и как привести работу сервера в норму.
Прежде всего, важно осознать, что 1С — это сложная клиент-серверная система. В архитектуре 1С:Предприятие 8 рабочие процессы rphost.exe отвечают за выполнение кода и обслуживание сеансов. Когда пользователь выполняет операцию, сервер резервирует память для хранения объектов, временных таблиц и данных транзакций. Если по какой-то причине память не освобождается, процесс начинает «раздуваться». Мы рассмотрим основные шаги для диагностики этой ситуации.
Технологический журнал — это наш главный союзник. Он позволяет увидеть, что именно делает пользователь на низком уровне. Чтобы выявить причину, настроим ТЖ на фиксацию событий CALL (вызовы сервером), DBMSSQL (запросы к БД) и EXCP (ошибки). Ограничим сбор данных конкретным пользователем, чтобы не перегрузить диск.
Рассмотрим структуру настройки ТЖ для анализа:
<log history="24">
<event>
<eq property="Name" value="CALL"/>
<eq property="Name" value="DBMSSQL"/>
<eq property="Name" value="EXCP"/>
</event>
<property name="Usr" value="ИмяПользователя"/>
</log>
Проанализировав логи, мы сможем увидеть, на каком именно запросе или вызове сервера происходит резкий скачок потребления памяти. Часто это указывает на неоптимальный код или тяжелый отчет, который не закрывает временные таблицы.
Если штатных инструментов не хватает, воспользуйтесь бесплатными утилитами, например, от Гилева. Эти инструменты позволяют собрать статистику по работе сеансов и выявить «узкие места» в базе данных, которые могут приводить к необоснованному потреблению ресурсов. Это отличный способ быстро оценить состояние системы без покупки дорогостоящего ПО.
В ходе анализа мы выяснили, что в двух идентичных по составу документов базах потребление памяти отличается. Это означает, что проблема не в самих данных, а в:
Сравнение/объединение. Возможно, в проблемной базе есть добавленные расширения или измененные модули, которые при запуске сеанса «подгружают» в память избыточные справочники или кэшируют данные.Модуль сеанса. Код, выполняемый при старте, может быть избыточным.Если мы понимаем, что код изменить быстро не получится, мы можем ограничить аппетиты сервера на уровне консоли администрирования 1С:Предприятия:
rphost.exe. Например, раз в сутки или по достижении критического порога памяти. Это «очистит» память сеансов.Рассмотренные методы помогут вам локализовать проблему. Помните: память сама по себе не растет. Она растет либо из-за долго живущих транзакций (зависаний), либо из-за неоптимальных запросов, возвращающих огромные выборки данных в память сеанса, либо из-за «зависших» объектов в модулях расширений. Используйте Технологический журнал, сравнивайте настройки двух баз и не забывайте про настройки Интервала перезапуска рабочих процессов. Совместными усилиями вы сможете найти «пожирателя» памяти и стабилизировать работу сервера.