Странное поведение GPRS-модемов при опросе по подключению

Наблюдаю много странных подключений GPRS-модемов, опрос которых настроен на опрос по подключению. Не все модемы, и пока только в конкретной системе. Однако таких модемов — десятки. Хотелось бы услышать ваши комментарии.

Вот пример.

Видно, что точек учёта одна и видно как настроен автоопрос.

Ниже — подключения модема за указанный интервал.

Сутки у этого модема начинается с того, что у него уже закончился лимит на подключения — 1 странность.

Вторая странность — надпись «Опрос возможен после 2025.11.12 01:30». Причём тут 1:30, если в настройках предусмотрено 5 сеансов в сутки? И это первый сеанс.

Дальше — третья странность в 0:56.

Ошибка, судя по журналу, та же, но результат опроса уже другой. Почему?

Четвёртая странность в 1:20.

В системном журнале это событие также отмечено

Проверил очередь опроса — предположил, что возможно подключение используют другие приборы, но это не так.

Хочется понять что с этим делать. Ошибки ли это ЛЭРСа? Артефакты аналогичные наблюдал и ранее в других версиях, но редко. И лечилось снятием с автоопроса и поставновкой снова.

Но тут артефакты кучно и их много.

Возможно сообщение результата сеанса некорректно отражает суть ошибки. В задании говориться не о календарных сутках, а об окне в 24 часа с момента последнего сброса количества сеансов. По умолчанию при первом после создания задания автоопроса сбросе количества попыток опроса метка времени сброса устанавливается на 00:00 часов текущих суток Сервера. При последующих сбросах уже в нее задается текущее время Сервера. Именно эта метка времени фигурирует в сообщении “Опрос возможен после”.

Сам сброс количества попыток опроса выполняется в системной задаче Сервера “Сброс очереди опроса”, которая запускается каждые 30 минут. Тот факт, что у вас время сброса сместилось на 1:30 говорит о том, что с момента создания задания автоопроса попытки выполнения указанной системной задачи на 00:00, 00:30 и 01:00 завершились неудачно либо по каким то причинам в ходе ее проведения ей не удалось произвести сброс попыток опроса.

Ситуация достаточно трудно поддается анализу ввиду сложности ее воспроизведения и зачастую обходится пересозданием задания автоопроса. Для ее анализа нам нужно больше данных. Пожалуйста, покажите список всех сеансов опроса по рассматриваемой точке учета. Хотелось бы найти опрос, с которого данная ситуация начала возникать по ней впервые.

Причина ситуации неясна. Приложите журналы работы Службы опроса и Сервера, с которым вы работаете, за 11 и 12 ноября.

Обратите внимание, что сделанные вами выводы об отсутствии подключения в других заданиях не подтверждаются выполненной проверкой. Вам стоит открыть подключение в свойствах объекта учета и проверить подключенное к нему оборудование. После этого, если на подключении висит несколько приборов учета, включая обсуждаемый, проверьте по остальным точкам учета отсутствие заданий на автоопрос с использованием данного подключения.

У меня вообще вот так с этими максимальными количествами опросов

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

По поводу второй ошибки, того, что канал уже используется, очень редко, но вижу такое. И помогают в этом протокол TCP и наши любимые блокировки интернета.

(ниже лишь гипотеза, так как когда блокировок нет, опрос идёт штатно, тогда всё в порядке.)

Момент времени 1) Модем вышел на связь с сервером и установил с ним соединение, но, сейчас действуют блокировки, и сеанс рвётся (но рвёт его оператор не штатно, он тупо закрывает GPRS/3G/4G соединение), иногда в сеансе успевают даже пройти какие-то байты данных, иногда нет, и оператор закрывает GPRS соединение (это видно в логах модема, в лэрсе вы этого не увидите и не поймёте никак). В результате TCP соединение как бы “подвисает”.

Момент времени 2) Сервер пытается отправляет какие-то запросы к клиенту не понимая что клиент уже всё…

Момент времени 3) Модем поняв, что соединение ему прервали закрыв GPRS соединение, опять выходит на связь с сервером.

Момент времени 4) У сервера уже два активных (по мнению сервера), но по факту мёртвых соединения. Да, я понимаю, по журналу вроде всё корректно, и время окончания соединения, не больше времени начала следующего сеанса, но возможно, иногда сервер не успевает закрыть старое соединение, а новое уже есть. Возможно дело в каких то долях секунды.

Не исключено. Сервер о котором я пушу находится +/- в вашем регионе

Сеанс опроса.xlsx (35,1 КБ)

Проанализировали присланные данные. У вас 12.11 с 00:09:45 по 01:10:19 наблюдались сбои при подключении к БД, что в свою очередь привело к ошибкам в работе Сервера ЛЭРС УЧЕТ, в результате чего сервер не мог своевременно и в полной мере выполнять свою работу из-за невозможности обращения к своей БД. Как следствие возникла описываемая вами ситуация.

Пожалуйста, нормализуйте работу вашей СУБД, исправив все причины, приводящие к ее недоступности. При проведении работ по обслуживанию СУБД Сервер ЛЭРС УЧЕТ следует останавливать для избежания подобных ситуаций.

Правильно ли я понял, что если возникают сбои при работе с базой данных с 0:00 до 0:30, то есть высокая вероятность, что при следующем сбросе количества попыток опроса время следующего сброса сдвинется на 30 минут, 1 час и так далее?

И чтобы опросы гарантированно начинались ровно в 0:00, после такого сбоя удалить расписание автоопросов, в которых настроен опрос GPRS-модемов по подключению, и задать их заново? Это кажется проще и быстрее, чем изучать журналы опросов и анализировать, не сместилось ли время сброса у какого-то из сотен приборов

Я правильно понимаю?

Не совсем так. Периодичность запуска внутренней задачи, как писал выше, каждые 30 минут. Если время возобновления опроса в строке “Опрос возможен после” уже наступило, но внутренняя задача на это время не будет запущено, то такое задание автоопроса будет обработано при следующем запуске. Например, если время на 00:00 часов, а задача не запускалась с 00:00 по 02:30 включительно, то такое задание будет обработана при запуске задачи в 03:00 и в последствии будет обрабатываться по этому времени ввиду временного окна 24 часа, о котором писал выше. Если впоследствии внутрення задача например не выполнится с 03:00 до 05:00, то задание обработается уже в 5:30, что опять же сместит метку времени возобновления опроса на 05:30. И т.д.

То есть смещение происходит при невыполнении внутренней задачи в ближайшее время после наступления времени из “Опрос возможен после”, а не с 00:00 по 00:30.

Да, все верно.