Здравствуйте. Есть подозрение, что предыдущие темы по некоторым проблемам исходят из общей производительности системы, поэтому хотелось бы проконсультироваться, сильно ли такая ситуация может сказываться на производительности:
У нас несколько тысяч gprs модемов, на большинстве настроен опрос при подключении модема к ЛЭРС, но установлено не более 3 сеансов в сутки. В свойствах подключений отмечена галочка “Разрывать соединение после опроса“. Видимо после каждого сеанса опроса, которое завершается с сообщением “Исчерпано максимальное количество сеансов опроса на сегодня” ЛЭРС разрывает соединение с модемом, но модем подключается снова из-за чего запускается новый сеанс опроса. В итоге возникает такая картина:
Здесь внимание на количество gprs соединений в сутки. Каждую секунду подключается несколько новых модемов. По некоторым модемам количество подключений превышает несколько тысяч в сутки, а причина отключения - “Отключен сервером“:
Дополню. Серьезные проблемы с производительностью возникли после последнего обновления, мы его установили 30 января. До обновления была версия 3.63.4, после стала 3.64.3
По видео видно, что за весь январь у нас было примерно 1.6 млн сеансов связи с модемами. А за 4 дня февраля уже 1.3 млн, видимо в обновлении было что-то, что начало генерировать огромное количество сеансов связи. И для примера все сеансы связи по одному узлу за 29 января, до обновления:
Давайте рассматривать ситуацию по одному модему. Если сеансы опроса через него завершаются аналогичным результатом “Оборудование уже опрашивается другим сеансом опроса”, проверьте есть ли в них сеанс, после которого сеансы стали завершаться вышеописанным результатом. Если есть, приложите его журнал опроса, а также журналы работы Сервера и Службы опроса за тот же день.
Можно точно сказать, что нагрузка на систему в такой конфигурации большая, так как каждое подключение и отключение модема приводит к запросам к БД. Лучше всего снять флажок, пускай висят подключенные. Это меньшая нагрузка на систему, чем то, что есть сейчас.
У самых часто подключаемых модемов уже снял, и да, это немного повлияло на работу. Но остается ещё примерно 2400 подключений с этим флагом. Знаю, что вносить изменения напрямую в БД не следует, но т.к. нет массового редактирования подключений можно ли это всё-таки снять его через БД? Или это может привести к нежелательным последствиям?
В принципе изменение параметра автоматического разрыва соединения после опроса в БД не является какой то сложной операцией. Но в принципе, с учетом массовости подключений ваших модемов, Сервер на время проведения такого изменения стоит выключить.
Значение данного параметра хранится в колонке “GprsAutoDisconnect” таблицы “PollConnection”. Если самостоятельно обновить не удастся, можем подготовить соответствующий скрипт, по выполнении которого во всех подключениях отключался бы данный параметр.
С написанием запроса проблем не будет, уже смотрел где хранится этот параметр
Но остается вопрос, почему всё-таки обновление привело к этой ситуации, хотя и схема, по которой инициализируются новые сеансы опроса при постоянных переподключениях модемов выглядит логичной
На приведенном вами ранее скриншоте видно, что сеансов опроса, которые закончились непредвиденной ошибкой несколько. Покажите журнал опроса первого сеанса, где она начала возникать “кучно”, журнал последнего сеанса отраженного на вашем скриншоте, после которого уже пошли сеансы с результатом “Оборудование уже опрашивается другим сеансом опроса”.
Если вы хотите выяснить причину возникновения рассматриваемой ситуации, в таком случае пока что не отключайте флаг разрыва подключения после опроса через скрипт.
По присланному списку сеансов видно, что результат “Оборудование уже опрашивается другим сеансом опроса” появлялся с самого начала 31.01.2026. Пожалуйста, проверьте весь список сеансов данной точки начиная с времени запуска Сервера и найдите самое первое возникновение сеанса с таким результатом. Покажите скриншот списка сеансов с этим сеансом и скриншот предшествующего ему успешного сеанса. Журнал опроса на этих скриншотах должен быть виден полностью, либо пришлите также файлы журналов опроса этих сеансов. Также пришлите журналы работы Сервера и Службы опроса за этот день.
Еще уточните прибор учета, привязанный к рассматриваемой точке, привязан в других точках?
Журнала работы сервера за этот день, к сожалению нет, т.к. сервер работает в контейнере, он уже перезапускался, а сохранение журнал вне контейнера пока не настроено
Кроме того, это не единственная точка, по которой возникает подобная ошибка, и с некоторой частотой они возникали до обновления. Но после обновления с увеличением сеансов опроса в 10-12 раз увеличилось и количество таких ошибок. На всякий случай добавляю список всех сеансов опроса gprs за 30.01. Обновление ЛЭРС было установлено примерно в 11.45
Для анализа необходимы оба журнала. Пожалуйста, настройте сохранение журнала работы Сервера, перезагрузите обе службы (их контейнеры) и дождитесь воспроизведения ситуации, приложив обновленные данные, аналогичные присланным в вашем последнем комментарии.
