Начиная с версии 3.40 мы включили изоляцию снимков в SQL Server, что могло увеличить нагрузку на tempdb со стороны SQL Server. Данная настройка позволяет избежать ошибок взаимной блокировки в сложных транзакциях, что делает работу ЛЭРС УЧЕТ более стабильной.
Если вас не устраивает высокая нагрузка на tempdb и/или увеличение характеристики ПК, на котором расположен SQL Server, не представляется возможным, вы можете отключить изоляцию снимков в SQL Server. Но вы должны понимать, что отключив эту настройку у вас могут возникать ошибки взаимных блокировок, которые могут приводить к ошибкам работы Сервера.
Для выключения изоляции снимков в SQL Server остановите Сервер ЛЭРС УЧЕТ (дождитесь его полной остановки) и на стороне SQL Server выполните скрипт:
ALTER DATABASE [LERS] SET READ_COMMITTED_SNAPSHOT OFF
после чего Сервер ЛЭРС УЧЕТ можно запустить.
Обращаю ваше внимание, что данную процедуру необходимо будет выполнять после каждого обновления, т.к. при обновлении вышеописанная настройка будет включена повторно.
Кроме того попробуйте следующие. После установки 3.40.4 зайдите в системные параметры на закладку “Обслуживание базы данных” и снимите флажок “Выполнять еженедельное обслуживание индексов БД в воскресенье в 5:00”. После этого перезагрузите службу “ЛЭРС УЧЁТ - Сервер”.
Обслуживание индексов запускается раз в неделю, но может выполняться несколько часов и в самых плохих случаях дней подряд, замедляя работу системы. Возможно, вам будет достаточно этого шага.
Да, нагрузка на SQL сервер стала очень высокая после обновления, даже после переезда на новый сервер (MSSQL2019, железо можно сказать топовое) процессоры загружены до 50%.
Статистика SQL: https://yadi.sk/d/lGuweSseapthQg
Тогда для начала, пожалуйста, отключите и сообщите результат.
Дополнительно хорошо бы посмотреть на то чем занят ваш сервер. Для этого, пожалуйста, в системных параметрах включите Протоколирование отладочных сообщений и примерно через час после того как обнаружите высокую загрузку отправьте нам журнал работы сервера за текущий день. После этого нужно отключить протоколирование отладочных сообщений.
Судя по всему, нагрузка связана с очень интенсивным подключением и отключением GPRS модемов, но это нужно проверить.
Протоколирование было включено, да после обновления также возникла проблема с GPRS модемами, “Опрос завершен. GPRS-модем уже отключен”. По электронке зарегистрировано обращение, идет общение.
Журнал сервера за сегодня: https://yadi.sk/d/ATa88-37pJ2X9Q
Похоже, что нагрузка на БД действительно создаётся при обработке GPRS подключений. Видно, что у вас модемы подключаются и отключаются практически каждую секунду. Уведомление о подключении и отключении модема в свою очередь приводит к дополнительным запросам к БД, что вполне может создать такую нагрузку. Из приложенной вами статистики видно, что больше всего процессорного времени использует запрос, связанный как раз с уведомлением.
В текущей версии 3.40.4 можно сделать следующее.
Как я уже писал, отключить задание обслуживания индексов БД.
Уменьшить срок хранения журнала GPRS-соединений. Если у вас там стоит значение 0, все соединения навсегда остаются в БД, приводя к длительной обработке. А так как эти журналы нужны крайне редко, мы рекомендуем ограничить срок их хранения хотя бы до 90 суток, если этого ещё не сделано.
В следующей версии 3.40.5 мы постараемся оптимизировать обработку подключения и отключения модемов, чтобы снизить интенсивность обращений к БД.
Обслуживание индексов попробую отключить, но я не думаю что это оно создает такую нагрузку, в статистике SQL, которую высылал видно что дает наибольшую нагрузку на процессор.
Срок хранения журналов GPRS-соединений стоит 14 суток.
Ждем новую версию.
Осталось решить проблему с GPRS модемами, у нас их много отвалилось после обновления.