Мониторинг MS SQL для 1С: что смотреть на сервере СУБД
Мониторинг MS SQL для 1С часто начинают с загрузки процессора и свободной памяти, а заканчивают звонком «документы не проводятся», когда журнал транзакций занял весь диск. Ниже — что на сервере СУБД стоит снимать постоянно: ожидания и блокировки, tempdb, журнал и модель восстановления, бэкапы, диски и память. И как связать это со временем вызовов, которое видит сама 1С.
Где теряется время: в 1С или в SQL Server?
Начинать лучше с кластера 1С. Платформа раздельно показывает полное время вызова, время на сервере 1С, время обращения к СУБД и ожидание на управляемых блокировках. Выросло время обращения к СУБД при прежней нагрузке на рабочие процессы — смотрим SQL Server. Растут ожидания на управляемых блокировках — СУБД ни при чём: их держит менеджер блокировок кластера 1С, и в счётчиках SQL Server их не видно.
Пороги для этих времён разобраны в статье о том, при каких значениях 1С действительно тормозит, — повторять их не будем.
Метрики СУБД и 1С должны лежать на одной временной шкале: тогда «в 14:05 время обращения к СУБД выросло втрое» сразу сопоставляется с «в 14:03 упало время жизни страниц в кеше». На этом построен мониторинг 1С: кластер, СУБД и сервер в одном месте.
Ожидания и блокировки: как читать wait stats
Когда запрос ждёт, SQL Server записывает тип и длительность ожидания в sys.dm_os_wait_stats. Значения копятся с запуска службы или со сброса через DBCC SQLPERF, поэтому смысл имеет только разница между двумя снимками: пять минут в момент жалобы против того же окна неделю назад.
Для баз 1С типичны несколько типов. LCK_M_S, LCK_M_U, LCK_M_X — запрос ждёт блокировку другой транзакции. PAGEIOLATCH_SH и PAGEIOLATCH_EX — страница читается с диска, потому что её нет в памяти. WRITELOG — медленная запись в журнал. RESOURCE_SEMAPHORE — запросу не хватает памяти на сортировку или хеш. ASYNC_NETWORK_IO — SQL Server ждёт, пока клиент заберёт результат; для 1С клиент — rphost, и обычно это огромная выборка или медленная сеть между сервером 1С и СУБД.
CXPACKET и CXCONSUMER — ожидания параллельных планов. В методических материалах 1С рекомендуется max degree of parallelism, равный 1: если параллелизм разрешён и эти ожидания в топе, начните с этой настройки.
Постоянно удобно снимать и штатные счётчики: SQLServer:Locks (Lock Waits/sec, Average Wait Time, Number of Deadlocks/sec), Processes blocked из General Statistics, Longest Transaction Running Time из Transactions. Взаимоблокировка SQL Server в 1С выглядит как «Конфликт блокировок при выполнении транзакции», так что рост Number of Deadlocks/sec почти всегда идёт вместе с жалобами.
Почему растут tempdb и журнал транзакций?
В tempdb создаются временные таблицы запросов 1С (ПОМЕСТИТЬ), туда уходят сортировки и хеш-соединения, которым не хватило памяти, и хранилище версий строк, если у базы включён READ_COMMITTED_SNAPSHOT. Долгая транзакция не даёт очищать версии, и tempdb растёт, пока она не закроется. Что именно занимает место, показывает sys.dm_db_file_space_usage.
Microsoft в описании tempdb советует столько файлов данных, сколько логических процессоров, но не больше восьми, а при конкуренции за выделение страниц добавлять по четыре. tempdb пересоздаётся при каждом запуске службы, и если начальный размер мал, после перезагрузки сервер первое время занят автоприростом файлов.
Почему не освобождается журнал, SQL Server пишет сам — в столбце log_reuse_wait_desc в sys.databases. LOG_BACKUP: база в модели FULL, а копий журнала нет или они перестали делаться. ACTIVE_TRANSACTION: журнал держит открытая транзакция, найти её помогает DBCC OPENTRAN. Когда журналу некуда расти, база получает ошибку 9002: читать можно, провести документ нельзя. Сжатие файла не поможет, пока не устранена причина.
Поэтому под алертом должны быть заполнение журнала каждой базы (Percent Log Used) и самая долгая транзакция. Закрытие месяца в 1С законно держит транзакцию дольше обычного — на такие окна порог поднимают, а не выключают правило.
Бэкапы, диски и память
Бэкап, который тихо перестал делаться, хуже его отсутствия: на него рассчитывают. Время последней полной копии и копии журнала по каждой базе лежит в msdb.dbo.backupset — алерт на возраст копии пишется одним запросом. И копию стоит иногда восстанавливать на тестовом сервере. Такие алерты полезны, только если их читают ночью и в выходные; если дежурного нет, это закрывает мониторинг как услуга.
Место смотрите по томам отдельно: данные, журнал, tempdb, бэкапы. На томе в несколько терабайт порог в процентах срабатывает поздно, полезнее прогноз по скорости роста. Заполненный том журнала останавливает изменения, как ошибка 9002, а том с бэкапами — тихо.
Page life expectancy — сколько секунд страница живёт в кеше без обращений. Порог 300 секунд придуман для серверов с небольшой памятью; при десятках гигабайт под кеш ориентир — около 300 секунд на каждые 4 ГБ или обычный уровень этого сервера. Смотрите PLE вместе с Page reads/sec, Memory Grants Pending и отношением Total Server Memory к Target Server Memory. Если 1С и SQL Server на одной машине, задайте max server memory, иначе СУБД заберёт память у rphost.
Нужно ли собирать wait stats постоянно?
Да, снимками раз в несколько минут, а не одним запросом в момент жалобы: по разнице видно, что выросло именно сейчас, и есть с чем сравнить. Фоновые ожидания вроде SLEEP_TASK, LAZYWRITER_SLEEP или BROKER_TASK_STOP растут всегда — их из анализа исключают.
Какую модель восстановления выбрать для базы 1С?
Это решение про допустимую потерю данных, а не про скорость. Если потерять день работы допустимо, хватает SIMPLE и ежедневной полной копии. Если нужно восстановление на момент времени — FULL с регулярными копиями журнала, и тогда мониторинг этих копий обязателен, иначе журнал однажды займёт весь диск.
Что проверить у себя
— Время обращения к СУБД из 1С и метрики SQL Server лежат на одной шкале.
— Снимки sys.dm_os_wait_stats сохраняются, есть обычный уровень для сравнения.
— Есть алерты на заблокированные процессы и взаимоблокировки.
— Для каждой базы известны модель восстановления и log_reuse_wait_desc.
— Заполнение журнала и самая долгая транзакция под алертом.
— Число файлов и начальный размер tempdb соответствуют рекомендации.
— Возраст последних копий проверяется алертом, тестовое восстановление делалось.
— Место на томах данных, журнала, tempdb и бэкапов под алертом, max server memory задан.
В Voltir агент сам находит MS SQL на Windows и читает штатные счётчики без учётной записи в СУБД: блокировки, заблокированные процессы, PLE, заполнение журнала по базам и самую долгую транзакцию, с готовыми алертами из документации по мониторингу баз данных.
Как это выглядит рядом со временами вызовов 1С, видно в живом демо.
Стоимость — на странице тарифов.