Повторы сеансов

При работе в 1С наблюдаются ситуации, когда клиентское приложение упало, а сеанс на сервере продолжает существовать. Пользователь перезапускает 1С и продолжает работать в новом сеансе. А «старые» сеансы в течении долго времени продолжают «висеть», потреблять ресурсы и лицензии.  В больших корпоративных информационных системах, при большом количестве пользователей проблема становится особенно актуальной.

Стандартный функционал сервера 1С не позволяет как то бороться с этой проблемой. А монитор кластеров серверов может автоматически отслеживать и сбрасывать такие сеансы. Для этого в настройках кластера необходимо активировать функцию

История о сброшенных сеансах накапливается в регистре. Можно открыть подробную карточку со всеми показателями сеанса.

Лимиты производительности

Зависший сеанс также характеризуется потреблением большого количества ресурсов. При этом вся система «тормозит» и остальные пользователи жалуются на производительность всей системы и даже в других базах данных. Например, отчет по показателю «Время вызова сервера за 5 мин» наглядно показывает проблему.

Чтобы автоматически сбрасывать такие сеансы, необходимо активировать функцию лимитов производительности и задать порог срабатывания по выбранным показателям.

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

В примере значение 300 тыс. это 5 мин в миллисекундах. Т.е. идет постоянный вызов сервера, по аналогии это как 100% загрузка процессора. Зависшие сеансы могут показывать и миллионные значения показателей. Даже если это какая то длительная обработка, типа проведение документов за год, и она длится больше 5 минут, то все равно вызовы в клиент-серверной архитектуре идут порционные, а не непрерывный с огромными значениями.

Вы можете подобрать свои пороги срабатывания с помощью отчета, а также отслеживать «узкие»\ «тяжелые» места в системе, не включая автоматический сброс таких сеансов.

Также можно задать исключения в лимитах по пользователям. Например, для главного бухгалтера, который действительно формирует очень тяжелые отчеты по всей базе за несколько лет. В дальнейшем рекомендуется оптимизировать подобные места в системе для снижения нагрузки.

Лимиты срабатывают только для клиентских подключений и не срабатывают для конфигуратора, com-коннектора, web-сервиса и пр.