Просим объяснить причину ошибок Lers.ExceptionHandler Ошибка записи сообщений в журнал службы опроса Истекло время ожидания ответа от базы данных.
На сервере 15 000 точек учета, в 12 ночи настроено ежедневное задание опроса всех точек учета. В ночное время ошибки возникают многократно.
В течение дня опрос выборочно запускается по разным точкам учета, ошибок меньше, чем ночью, но счет идет на десятки.
В конфиге мы увеличили время ожидания от сервера баз данных до 300 секунд (300 в секции Database).
Таблица PollSessionLog имеет 15 32 984 402 записей, PollSession – 67 815 875 записей. В логах сервера часто встречаются ошибки [Core Microsoft SqlClient Data Provider] Microsoft.Data.SqlClient.SqlException: Transaction (Process ID 73) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
Возможно Серверу ЛЭРС УЧЕТ не хватает ресурсов для опроса всех точек учета. Уточните, какая загруженность ПК Сервера ЛЭРС УЧЕТ во время опроса всех точек учета?
Уточните, пожалуйста, Служба опроса ЛЭРС УЧЕТ, через которую производится опрос, установлена на том же ПК, что и Сервер? Аналогичный вопрос по SQL Server.
Также уточните описанные ошибки “Transaction (Process ID 73) was deadlocked…” и “Ошибка записи сообщений в журнал службы опроса Истекло…” возникают во время массового проведения опроса всех точек учета или в случайное время?
Сервер опроса работает на выделенном сервере с 32 ядрами, загрузка CPU не более 10%
Сервер БД работает на выделенном сервере с 16 ядрами, загрузка CPU не более 20%
Дедлоки возникают в течение рабочего дня в разное время, во время работы опроса сообщений о дедлоках нет.
Ошибки “Ошибка записи сообщений в журнал службы опроса Истекло…” возникают в большом количестве во время опроса, в течение дня появляются реже.
На сервере БД из мониторинга вытащили запрос, который вызывает блокировки, которые предшествуют ошибкам по таймауту:
–object: LERS.dbo.PollSession, lock mode: Exclusive (X), index: PK_PollSession
(@__pollTaskId_0 int) DECLARE @stop int DECLARE @rowAffected INT DECLARE @totalRowAffected INT
SET @stop = 0 SET @totalRowAffected = 0 WHILE @stop=0 BEGIN DELETE TOP (4000) FROM A FROM [PollTask] AS A
INNER JOIN ( SELECT [p].[Id] FROM [PollTask] AS [p] WHERE [p].[Id] = @__pollTaskId_0 ) AS B ON A.[Id] = B.[Id]
SET @rowAffected = @@ROWCOUNT SET @totalRowAffected = @totalRowAffected + @rowAffected
IF @rowAffected < 4000 SET @stop = 1 END SELECT @totalRowAffected
Описанный выше запрос не может быть связан с возникающей ошибкой.
Ранее вы писали, количество записей в таблице PollSessionLog. Это таблица, в которой хранятся журналы опроса. Собственно при записи в эту таблицу и возникает ошибка, судя по всему, из-за ее очень большого размера.
Уточните, пожалуйста, какой срок хранения журналов опроса задан в Системных параметрах → Обслуживание базы данных → Журналы? Также уточните какая самая ранняя запись по дате в вышеупомянутой таблице?
В принципе ранняя записей укладывается в заданный период хранения журналов опроса, хотя и является достаточно большой.
Судя по всему в период проведения ночного опроса всех точек нагрузка на СУБД SQL Server возрастает достаточно сильно в результате чего она не успевает отвечать на запросы Сервера ЛЭРС УЧЕТ в результате чего возникает рассматриваемая ошибка. Почему при этом она не расходует все ресурсы выделенного ПК нам неизвестно. Возможно в ней есть какие то ограничения по ресурсам. По данному вопросу вам стоит обратиться в техническую поддержку разработчика данной СУБД.
Все что можно сделать сейчас в ЛЭРС УЧЕТ, чтобы исключить возникновение данной ошибки, это увеличить время ожидания ответа от БД еще больше, чтобы Сервер ЛЭРС УЧЕТ дольше ожидал ответа от БД.
Есть ли какие-либо рекомендации по периоду хранения логов? Мы прекрасно понимаем, что настройками можно убить любое производительное железо. Настройки позволяют указать практически любой период хранения логов, но лет через 5 таймаут к серверу БД придется увеличивать до часов и суток.
Как я понял, по умолчанию значение для хранения всех журналов 80 суток. Есть ли рекомендации для этого значения?
Каких либо особых рекомендаций на этот счет нет. В большинстве случаев это определяется тем, за сколько дней вам необходимо просматривать эти данные, в вашем случае журналы. Если у вас нет необходимости в журналах за 3 года, а необходимы журналы только за год, соответственно можно сократить срок их хранения до года.
Единственное при очень больших сроках хранения данных мы можем порекомендовать периодически делать резервную копию БД и удалять очень старые данные. Если вдруг вам понадобятся старые данные, вы можете временно развернуть резервную копию с ними для их просмотра, а потом вернуться к актуальной БД.
Также можно настроить обслуживание индексов все в том же разделе обслуживания базы данных (если данная настройка выключена), чтобы увеличить скорость выполнения запросов.
Еще можем посоветовать разбить основное время проведения опроса всех точек, на несколько опросов с разницей например в час, если это возможно. Опрос такого большого количества точек учета в одно время создает очень большую нагрузку на все компоненты, но в первую очередь на Сервер ЛЭРС УЧЕТ и соответственно на SQL Server. Например можно разнести опрос 12000 точек учета на 3 опроса групп точек по 4000.
Проще выгрузить в другую таблицу все записи ранее месяца - позволит вернуть архивные записи без восстановления из резервных копии прерывания работы. За идею спасибо!
Если под другой таблицей подразумевается созданная вручную таблица внутри БД ЛЭРС УЧЕТ, то нужно быть очень осторожным, так как если в последствии в ЛЭРС УЧЕТ появится таблица с таким же наименованием как и ваша, это может вызвать ошибки.
Я бы все же посоветовал в этом случае создать отдельную БД, в которой создавать нужные вам таблицы.