Сервер 1С виснет в 9 утра: как найти узкое место — SQL, сеть или диск

Ограничение редко находится там, где жалуются пользователи. Медленный отчёт в 1С может быть виной перегруженного диска на сервере СУБД, нехватки памяти у процесса rphost, блокировок в базе или неоптимального запроса в самой конфигурации. Разделить эти четыре слоя помогают счётчики операционной системы, консоль кластера 1С и DMV-запросы к серверу баз данных — каждый инструмент показывает свой участок цепочки.

🕘 9:03, бухгалтерия открывает месяц — и 1С встаёт

Компания на 38 пользователей держит 1С:Бухгалтерию и Управление торговлей на одном физическом сервере: восемь ядер, 32 ГБ памяти, RAID5 из трёх HDD под базу данных. Без десяти девять всё работает как обычно — отчёты открываются за секунды, документы проводятся без задержек. Но ровно в момент, когда бухгалтерия запускает закрытие месяца, а склад параллельно оформляет утренние отгрузки, база встаёт колом на 10-15 минут: зависают все — от кассира до директора, который в это время как раз пытается открыть отчёт по продажам.

ИТ-отдел первым делом перезагружает сервер приложений 1С — не помогает, на следующий день зависание повторяется в ту же минуту. Потом пробуют увеличить количество рабочих процессов rphost в кластере — тоже без результата, потому что никто пока не проверил, где именно упирается нагрузка. Ставка растёт с каждым днём: закрытие месяца сдвигается на двое-трое суток, менеджеры не могут провести отгрузку, потому что база залочена под регламентными операциями, а первые жалобы клиентов на задержку документов и счетов уже приходят в чат поддержки. Для бизнеса это не абстракция: просроченные документы двигают сроки оплаты, а бухгалтерия рискует не уложиться в срок сдачи отчётности за месяц.

шаг 1: что говорят счётчики инфраструктуры

Первым делом смотрят на голые счётчики операционной системы — без них любой разговор про тормоза 1С превращается в гадание на кофейной гуще. На сервере приложений 1С загрузка процессора в момент зависания не поднимается выше 40%, память рабочих процессов стабильна, свопинга нет. А вот на отдельной машине с СУБД счётчик Avg. Disk Queue Length в те же 10-15 минут подскакивает до 18-20 при обычных значениях 1-2 — диск физически не успевает отдавать и записывать данные.

Это уже сужает круг подозреваемых: сервер приложений 1С не перегружен, значит дело либо в дисковой подсистеме СУБД, либо в том, как СУБД её использует. Проверить, соответствует ли железо конфигурации по нагрузке, помогает справочник системных требований 1С — здесь быстро выясняется, что RAID5 на трёх HDD исходно не рассчитан на одновременную запись логов транзакций и чтение больших отчётов при закрытии периода.

Заодно стоит проверить счётчики сети — задержку и потери пакетов до сервера, если часть пользователей работает из другого офиса или на удалёнке: иногда причина совсем не в сервере, а в канале связи филиала.

шаг 2: консоль кластера и технологический журнал 1С

Прежде чем окончательно снять подозрения с сервера 1С, стоит открыть консоль кластера и посмотреть на активные сеансы, память рабочих процессов rphost и количество исключительных блокировок. В этом случае процессы rphost не растут в памяти, число сеансов в момент зависания не превышает обычное, а блокировки на уровне 1С — управляемые, без явных конфликтов между пользователями. Это подтверждает: проблема не в самом сервере приложений и не в том, как распределена на нём нагрузка.

Если бы картина была другой — память рабочих процессов росла бы без остановки, а количество активных сеансов резко скакало в момент зависания — стоило бы пересмотреть настройку сервера 1С: число рабочих процессов на ядро, распределение фоновых заданий по расписанию, лимиты памяти на один процесс. Но в этом кейсе слой чист, и разбор идёт дальше — к самой СУБД.

шаг 3: DMV-запросы показывают, где толпятся ожидания

На сервере СУБД запрос к sys.dm_exec_requests и sys.dm_os_wait_stats в момент зависания показывает не блокировки типа LCK_M_X, а массовые ожидания PAGEIOLATCH_SH — это ожидание физического чтения страниц с диска, а не конфликт транзакций между пользователями. Разница принципиальная: блокировки лечат перестройкой бизнес-логики и графика регламентных операций, а ожидания ввода-вывода — только более быстрым диском или перераспределением файлов данных и логов между разными физическими накопителями.

PAGEIOLATCH или LCK_M_X — как отличить по DMV

• ✓PAGEIOLATCH_SH и PAGEIOLATCH_EX — сеанс ждёт, пока диск дочитает или дозапишет страницу данных; лечится дисками и распределением файлов, а не логикой конфигурации.
• ✓LCK_M_X и LCK_M_S — сеанс ждёт, пока другой сеанс снимет блокировку с той же записи; лечится управляемыми блокировками 1С и графиком регламентных заданий.
• ✓CXPACKET и SOS_SCHEDULER_YIELD — признак нехватки процессорных ядер под параллельные запросы, повод пересчитать количество ядер на сервере СУБД.

Чтобы не гадать на глаз и объективно сравнить сервер до и после изменений, дисковую и процессорную производительность стоит замерить тестом Гилёва — он даёт условные «попугаи» 1С и позволяет сопоставить два разных сервера числами, а не субъективным «вроде стало быстрее».

Дополнительно гипотезу проверяет sys.dm_io_virtual_file_stats — он показывает, на каком именно файле базы, данных или логе транзакций, копится задержка ввода-вывода, и подсказывает, какой из дисков переносить на NVMe в первую очередь.

шаг 4: когда дело не в железе, а в самом запросе

После замены дисков на SSD общее зависание в 9 утра исчезло — база больше не встаёт колом целиком. Но один конкретный отчёт — оборотно-сальдовая ведомость по всем складам разом — по-прежнему выполняется 4-5 минут у каждого, кто его открывает, независимо от загрузки сервера и времени суток. Это уже четвёртый слой: не инфраструктура и не СУБД в целом, а конкретный запрос в конфигурации, который делает полное сканирование таблицы движений вместо использования индекса.

Отличить такую проблему несложно: если тормозит один и тот же отчёт или документ у всех пользователей независимо от нагрузки сервера — дело в запросе или отчёте, и здесь поможет только доработка кода и структуры данных, а не апгрейд железа. Именно на этом шаге многие компании ошибочно арендуют более мощный сервер и не получают результата, потому что причина осталась в конфигурации.

📊 таблица: пять симптомов и слой, за который они отвечают

Короткая шпаргалка для тех, кто снимает показания впервые и не хочет запоминать все DMV наизусть.

чем закончился перенос и что изменилось

Компания разнесла роли: сервер 1С и СУБД теперь работают на разных арендованных машинах, база данных получила NVMe вместо RAID5 на HDD, а проблемный отчёт переписали с использованием индексированного регистра вместо полного перебора движений. Закрытие месяца снова укладывается в обычное время, склад проводит отгрузки без зависаний, и жалобы в чат поддержки прекратились.

Если самостоятельно снимать счётчики и разбирать DMV-запросы некому, дешевле сразу отдать инфраструктуру под нагрузку 1С на аутсорс. Аренда сервера 1С стоит от 1 100 ₽ в месяц за пользователя и уже включает подбор конфигурации под конкретную базу — сервер приложений и СУБД можно развести по разным машинам сразу, не дожидаясь зависаний по утрам.

Под небольшую базу на 15-20 пользователей обычно достаточно виртуального сервера для 1С, а при нагрузке, близкой к описанному кейсу — 35-40 активных сеансов, регламентные операции и тяжёлые отчёты — есть смысл сразу смотреть в сторону выделенного сервера в аренду с гарантированными ресурсами под диск и память. Если разбор нагрузки нужен разово, без переезда всей инфраструктуры, диагностику по счётчикам и DMV делает сисадмин на аутсорсе за 3800 ₽ в час.

Разовая диагностика закрывает конкретный кейс, но нагрузка растёт вместе с бизнесом, и через полгода-год узкое место может сместиться в другой слой — например, из диска в процессор при увеличении числа пользователей. Поэтому счётчики стоит снимать не только когда что-то уже встало, а хотя бы раз в квартал, особенно перед сезонными пиками вроде закрытия года.

❓ Частые вопросы

Как понять, что тормозит именно сервер 1С, а не сеть или СУБД?

Смотрите на консоль кластера 1С: если процессы rphost стабильны по памяти, а количество активных сеансов и исключительных блокировок не растёт в момент зависания, сервер приложений 1С не виноват. Тогда проблему нужно искать на сервере СУБД через DMV-запросы или в сети между офисом и сервером.

Какие счётчики проверять в первую очередь при жалобах на медленную работу 1С?

Для сервера 1С — загрузку процессора и память процессов rphost в консоли кластера. Для сервера СУБД — Avg. Disk Queue Length и ожидания в sys.dm_os_wait_stats. Если оба сервера свободны, а тормозит один и тот же отчёт, дело в конфигурации, а не в железе.

Поможет ли более мощный сервер, если проблема в самой конфигурации?

Нет. Если тормозит один и тот же отчёт или документ у всех пользователей независимо от загрузки сервера, апгрейд железа результата не даст — запрос всё равно будет выполнять полное сканирование таблицы. Сначала нужно исправить запрос или добавить индекс, и только потом оценивать, хватает ли ресурсов сервера.

Сколько стоит аренда сервера для 1С с учётом переноса и настройки?

Аренда сервера 1С стоит от 1 100 ₽ в месяц за пользователя и включает подбор конфигурации под конкретную базу. Разовая диагностика нагрузки по счётчикам и DMV, если нужна только консультация без переноса, обходится в 3800 ₽ за час работы сисадмина.

Что делать, если после переноса на новый сервер тормоза остались?

Значит узкое место было не в инфраструктуре. Нужно повторить диагностику на новом железе: проверить консоль кластера 1С, DMV-запросы к СУБД и найти конкретный отчёт или документ, который тормозит у всех одинаково — обычно причина в запросе, отчёте или отсутствующем индексе.