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

Звонок обычно звучит так: «1С встала, бухгалтерия не работает, срочно!». За пятнадцать лет я слышал это раз двести. И знаете что? В половине случаев причина не в 1С вообще. Прежде чем набирать номер программиста 1С за 3000 рублей в час, потратьте час сами — я покажу, как отличить сеть от диска и диск от кривого запроса.

Почему «тормозит» — это три разных диагноза

Вот в чём беда. Клиент говорит «1С тормозит», и это ничего не говорит о причине. Тормозит открытие документа за две секунды — это одно. Тормозит формирование отчёта пять минут вместо тридцати секунд — совсем другое. А зависает вся база сразу для всех пользователей — третье, и тут уже пахнет блокировками на SQL.

У меня было три звонка за одну неделю с одной и той же фразой «1С тормозит». У производственной компании на Каширке — забитый гигабитный свитч, у юрфирмы в центре — забитый диском SSD на 94%, у бухгалтерии на Профсоюзной — банальная блокировка таблицы регистра накопления из-за незакрытой транзакции обмена с банком. Три разных причины, один симптом.

Программист 1С, если вызвать его сразу, полезет разбирать конфигурацию и код. И часто окажется прав — но потратит на диагностику первые полчаса своего оплачиваемого времени, просто исключая инфраструктуру. Дайте ему сразу конкретику: «сеть в порядке, диск загружен на 40%, а вот в SQL висит блокировка от процесса номер такой-то» — и он сразу пойдёт в нужное место.

Шаг 1, десять минут: проверяем сеть

Начинаем с самого дешёвого теста. Открываем командную строку на рабочей станции, где 1С «тормозит», и пингуем сервер: ping адрес_сервера -t. Смотрим на время отклика. Норма для локальной сети — 0-1 мс. Если видите 40-80 мс или, того хуже, потери пакетов — вот и весь диагноз, дальше можно не копать.

Дальше смотрим tracert до сервера — если маршрут прыгает через лишние узлы или через Wi-Fi-точку с перегрузкой, это тоже вылезет. У одного клиента, юрфирмы на 18 рабочих мест, тормозила именно 1С через терминальный сервер — а на деле весь трафик перегружал 100-мегабитный свитч 2010 года выпуска, который тянул заодно IP-камеры и резервное копирование по расписанию в рабочее время. Поменяли свитч на гигабитный за 4 500 рублей — жалобы кончились в тот же день.

Отдельно проверьте, не работает ли кто-то через RDP из дома по слабому интернету, а база при этом толстый клиент — тогда тормозит не сеть офиса, а домашний канал сотрудника, и никакой сервер тут не при чём. И ещё момент: если база опубликована через веб-сервер (Apache или IIS) и работает по HTTP, а не в режиме RDP — проверьте, не деградировал ли SSL-сертификат или не подрос ли пинг до внешнего IP, если офис ходит в облако.

Шаг 2, пятнадцать минут: диск сервера

Сеть в порядке — идём на сам сервер 1С или SQL-сервер (часто это одна машина). Открываем Диспетчер задач, вкладку «Производительность», смотрим на диск. Если полоса загрузки диска висит на 90-100% почти постоянно — вот он, узкий момент. Особенно если это до сих пор HDD, а не SSD — у меня таких клиентов ещё хватает, и все они одинаково удивляются, узнав, что диск за пять лет эксплуатации просто устал.

Более точный инструмент — Resource Monitor (resmon в строке «Выполнить»), вкладка Disk. Там видно очередь запросов к диску (Disk Queue Length) и какой именно процесс диск грузит — sqlservr.exe, ragent.exe или что-то постороннее вроде антивирусной проверки, которая внезапно решила просканировать файл базы данных весом 40 гигабайт прямо в разгар рабочего дня.

У клиента, торговой компании с производством, был именно этот случай: Kaspersky Endpoint Security раз в сутки в 12:30 запускал полное сканирование, и файл базы 1С попадал под лупу антивируса вместе со всем остальным диском. Пятнадцать минут в обед вся торговля стояла колом. Добавили файл базы в исключения антивируса — и всё, никакого программиста вызывать не пришлось.

Ещё проверьте свободное место. Если диск забит больше чем на 90%, SQL Server начинает тормозить на операциях роста файлов базы и журнала транзакций — это классика. Пять минут, чтобы зайти в свойства диска, и сразу видно, не в этом ли дело.

Шаг 3, двадцать минут: запросы и блокировки в SQL

Если сеть чистая и диск не захлёбывается, а тормозит только в 1С — переходим к SQL Server. Тут без страха, инструмент простой: открываем SQL Server Management Studio (если его нет — ставим бесплатно, это займёт пять минут) и запускаем процедуру sp_who2 или, если версия посвежее, смотрим через Activity Monitor.

Ищем строки со статусом SUSPENDED и заполненным полем BlkBy — это значит, что один процесс заблокировал другой, и второй ждёт освобождения ресурса. Если видите цепочку из десяти процессов, ожидающих один и тот же SPID — вот она, причина зависания всей базы разом, а не какого-то одного пользователя.

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

Ещё полезная штука — встроенный в 1С центр управления производительностью (ЦУП) или обычный технологический журнал. Но для первичной диагностики хватит и штатного SQL-инструментария. Также гляньте загрузку процессора SQL-сервера в Диспетчере задач: если sqlservr.exe жрёт 90% CPU постоянно, а не всплесками — это уже почти наверняка кривой запрос без нужных индексов, и это прямая работа для программиста 1С, тут инфраструктура ни при чём.

Технологический журнал — когда простых средств мало

Если первых трёх шагов не хватило, а точечно понять, что именно тормозит — какой отчёт, какая обработка, какой конкретно запрос — включаем технологический журнал 1С. Звучит страшно, делается просто: создаётся XML-файл конфигурации в папке conf, платформа сама начинает писать лог по указанным событиям, обычно интересуют события EXCP (ошибки) и CALL (вызовы с временем выполнения).

Через 10-15 минут работы пользователей в базе смотрим лог — там прямым текстом написано, какой запрос выполнялся 47 секунд и от какого пользователя. Это уже не догадки, а факт, с которым можно идти к программисту и говорить конкретно: вот этот отчёт по остаткам на складах виснет на функции, где явно нет индекса по номенклатуре.

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

Случай из практики: как час диагностики сэкономил 40 тысяч рублей

Расскажу историю целиком, потому что она типичная. Медицинская клиника, 22 рабочих места, 1С:Медицина плюс 1С:Бухгалтерия на отдельной базе. Звонок: «всё встало, врачи не могут завести пациента, у нас очередь в коридоре». Классический вариант — сразу звать самого дорогого специалиста и платить за срочность.

Мы за 40 минут прошли ровно эти три шага. Пинг до сервера — 0 мс, сеть чистая. Диск сервера — загрузка 35%, тоже не то. Зашли в SQL Server, запустили sp_who2 — и увидели восемь заблокированных процессов, все ждут один SPID. Тот процесс оказался ручной выгрузкой в 1С:Отчётность, которую бухгалтер запустил и, не дождавшись, свернул окно и ушёл на встречу, оставив транзакцию открытой на сорок минут.

Убили процесс через KILL в SQL Server, база отпустилась за секунду, очередь в коридоре рассосалась. Стоимость вызова стороннего программиста 1С по срочному тарифу в тот день был бы минимум 8 000 рублей плюс, скорее всего, час-два на ту же самую диагностику, которую мы сделали сами. А если бы вызвали ещё и сетевого админа проверить провода — вообще бы вышло тысяч на 15-20 при том, что причина была в одном забытом окне на компьютере бухгалтера.

Когда диагностика говорит: без программиста не обойтись

Честно скажу — процентов 30 случаев после этой диагностики всё равно упираются в код или конфигурацию. Если запрос из отчёта выполняется долго стабильно, каждый день, без блокировок и при свободном железе — это архитектурная проблема запроса, отсутствие индексов, забытая временная таблица без индексирования, огромные виртуальные таблицы регистров без отбора по периоду. Тут диагностика инфраструктуры бессильна, нужен человек, который читает код на встроенном языке.

Второй случай — устаревшая платформа. Если у вас 1С:Предприятие версии восьмилетней давности на связке с современным SQL Server 2022, бывают конфликты производительности, о которых знает только тот, кто занимается 1С каждый день. Обновление платформы — тоже работа для программиста, тут я не спорю.

Но даже в этих случаях диагностика, которую вы провели сами, экономит время специалиста и, соответственно, ваши деньги. Он приходит не с чистого листа, а с готовыми данными: сеть чистая, диск свободен на 60%, загрузка SQL в норме, а вот конкретный запрос висит 38 секунд — разбирайтесь с кодом. Час его работы вместо трёх-четырёх.

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

У меня толстый клиент 1С, а не терминальный сервер — диагностика та же самая?
Почти. Сеть проверяете точно так же — пингом до сервера баз. Диск смотрите на самом сервере SQL, а не на компьютере пользователя, потому что именно там физически лежит база. А вот загрузку процессора имеет смысл смотреть и на клиентской машине тоже — старый компьютер с 4 ГБ памяти сам по себе может тормозить формирование больших отчётов, это уже не вопрос сервера.

Можно ли обойтись без SQL Server Management Studio, если её вообще никогда не ставили?
Да, для первой прикидки хватит Диспетчера задач: смотрите на процесс sqlservr.exe — если он стабильно жрёт весь процессор, это уже сигнал. Но SSMS бесплатна, ставится за пять минут с сайта Microsoft и один раз облегчает жизнь навсегда, я всем клиентам рекомендую держать её под рукой хотя бы на сервере.

У нас 1С в облаке у провайдера — эта диагностика вообще применима?
Частично. Сеть и диск вы проверить не сможете напрямую, это зона ответственности провайдера, но пинг до внешнего адреса сделать всё равно стоит — если он скачет, звоните провайдеру с конкретными цифрами, а не с абстрактным «тормозит». А вот блокировки в SQL, если у вас есть доступ к базе через SSMS, посмотреть можно и в облаке — это ваша конфигурация, а не инфраструктура провайдера.

Как часто вообще стоит делать такую проверку, если жалоб нет?
Я советую клиентам смотреть загрузку диска и свободное место раз в месяц — это пять минут, а предотвращает половину будущих авралов. Если диск подбирается к 85%, лучше расширить его заранее, а не разбираться в панике, когда база встанет намертво в разгар квартальной отчётности.