Почему тормозит 1С: методика диагностики, которая находит причину за два часа

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

До того как открывать счётчики, задаём четыре вопроса. Ответы на них экономят половину работы.

• У всех или у одного? У одного — проблема на станции или в его правах. У всех — на сервере или в сети.
• Всегда или в конкретное время? Каждый день в 09:15 — это регламентное задание или массовый вход. Постоянно — это конфигурация или железо.
• Везде или в конкретной операции? Тормозит один отчёт — проблема в коде и запросах. Тормозит всё, включая открытие списков, — проблема в инфраструктуре.
• Началось резко или нарастало? Резко — было изменение: обновление, новый пользователь, изменение в железе. Нарастало — рост базы, фрагментация, накопление данных.

Комбинация ответов часто даёт диагноз сразу. «У всех, каждый день с 9 до 10, во всех операциях, началось после Нового года» — это почти наверняка утренний пик плюс выросшая база плюс отсутствие обслуживания индексов.

Мы задаём эти вопросы письменно, потому что устные ответы плывут. «Всегда тормозит» после уточнения превращается в «по вторникам и четвергам после обеда» — а это уже след к конкретной обработке.

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

Если оттуда быстро — дальше сервер можно не трогать. Ищем на проблемной станции:

• антивирус, проверяющий каталог кэша 1С (%LOCALAPPDATA%\1C\1cv8) — добавляем исключение;
• разросшийся локальный кэш — чистится удалением каталога, платформа пересоздаст;
• устаревшую версию платформы — клиент и сервер должны совпадать до сборки;
• сетевые диски, недоступные при старте, — 1С ждёт таймаута;
• банально нехватку памяти на станции при открытых браузере, почте и 1С.

Кэш чистим так:

taskkill /IM 1cv8.exe /F
rmdir /S /Q "%LOCALAPPDATA%\1C\1cv8"
rmdir /S /Q "%APPDATA%\1C\1cv8"

Это лечит удивительно много «личных» тормозов, особенно после обновления конфигурации. Кэш метаданных на клиенте иногда расходится с базой, и платформа начинает перезапрашивать структуру.

Тонкий клиент 1С чувствителен не к ширине канала, а к задержке. Это ключевое отличие от файлового доступа, и его редко понимают.

Проверяем задержку до сервера:

ping -n 100 srv-1c | find "Средн"
# и распределение, а не только среднее
Test-Connection srv-1c -Count 100 |
  Measure-Object -Property ResponseTime -Average -Maximum -Minimum

Ориентиры из практики: до 1 мс в локальной сети — норма; 5–15 мс — уже ощутимо на списках; выше 40 мс — работа становится некомфортной, и никакой апгрейд сервера этого не исправит.

Отдельно смотрим потери и переменность задержки. Стабильные 20 мс переносятся лучше, чем прыгающие от 2 до 60. Скачки обычно означают перегруженный коммутатор, дуплекс-мисматч или Wi-Fi.

Wi-Fi заслуживает отдельной строки. Работа в 1С по Wi-Fi возможна, но именно там мы находим большую часть «плавающих» тормозов у отдельных сотрудников. Переезд человека на кабель — проверка на пять минут, которая закрывает вопрос окончательно.

И ещё: проверьте скорость согласования портов. Порт, упавший на 100 Мбит вместо гигабита из-за повреждённого патч-корда, — реальная и регулярная находка.

Get-NetAdapter | Select-Object Name, LinkSpeed, MediaConnectionState

Здесь смотрим три вещи: процессор, память рабочих процессов и очередь к дискам.

Get-Counter -Counter @(
  "\Процессор(_Total)\% загруженности процессора",
  "\Память\Доступно МБ",
  "\Физический диск(_Total)\Средняя длина очереди диска"
) -SampleInterval 5 -MaxSamples 60

Что означают значения:

Отдельно снимаем память по rphost — если процесс подошёл к порогу и вот-вот уйдёт на перезапуск, пользователи это чувствуют.

Важное замечание про процессор. Для 1С частота важнее числа ядер: значительная часть работы однопоточная. Сервер с 32 ядрами по 2,1 ГГц будет на типовых операциях медленнее сервера с 8 ядрами по 3,6 ГГц. Это регулярно удивляет клиентов, которые «взяли мощный сервер».

Если на этом шаге всё в норме, а тормоза есть — виновата почти наверняка СУБД или конкретный код. Идём дальше.

Самый информативный шаг. Вместо гадания смотрим, чего именно ждёт SQL Server.

SELECT TOP 12 wait_type,
       wait_time_ms / 1000 AS wait_s,
       waiting_tasks_count,
       wait_time_ms / NULLIF(waiting_tasks_count, 0) AS avg_ms
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('CLR_SEMAPHORE','SLEEP_TASK','BROKER_TASK_STOP',
      'XE_TIMER_EVENT','LAZYWRITER_SLEEP','SQLTRACE_BUFFER_FLUSH','WAITFOR')
ORDER BY wait_time_ms DESC;

Расшифровка того, что видим чаще всего:

• PAGEIOLATCH_* — ждём чтения с диска. Либо диск медленный, либо памяти мало и кэш не держит рабочий набор.
• CXPACKET вместе с CXCONSUMER — параллелизм. Обычно означает, что MAXDOP и порог параллелизма оставлены по умолчанию.
• LCK_M_* — блокировки. Проблема в прикладной логике или уровне изоляции, не в железе.
• WRITELOG — ждём записи в журнал транзакций. Лог лежит на медленном томе.
• RESOURCE_SEMAPHORE — не хватает памяти на выполнение запросов, они стоят в очереди за грантом.

Этот запрос за минуту говорит, куда копать дальше, и избавляет от целого дня перебора гипотез. Единственный нюанс: статистика накапливается с момента старта службы, поэтому лучше сбросить её и снять заново в час пик.

DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR);

Если предыдущий шаг показал PAGEIOLATCH или WRITELOG, проверяем диски предметно.

Интересует не пропускная способность, а задержка. Именно она определяет отзывчивость учётной системы.

SELECT DB_NAME(vfs.database_id) AS db,
       mf.physical_name,
       vfs.io_stall_read_ms  / NULLIF(vfs.num_of_reads, 0)  AS avg_read_ms,
       vfs.io_stall_write_ms / NULLIF(vfs.num_of_writes, 0) AS avg_write_ms
FROM sys.dm_io_virtual_file_stats(NULL, NULL) vfs
JOIN sys.master_files mf ON mf.database_id = vfs.database_id
                        AND mf.file_id = vfs.file_id
ORDER BY avg_read_ms DESC;

Целевые значения для боевой базы 1С: чтение до 10 мс, запись журнала до 5 мс. Значения выше 20 мс на файле данных означают, что диск является узким местом, и дальше настраивать что-либо бессмысленно.

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

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

Бывает — и нередко, — что все пять слоёв в норме, а конкретная операция всё равно занимает три минуты.

Тогда виноват код: неоптимальный запрос, обращение к базе в цикле, отсутствующий индекс под конкретную выборку, разросшийся регистр сведений без ограничений.

Инструмент здесь один — технологический журнал с фильтром по длительности. Настраиваем logcfg.xml так, чтобы писались только события длиннее секунды, воспроизводим операцию, смотрим, что попало.

<event>
  <eq property="name" value="DBMSSQL"/>
  <ge property="duration" value="1000000"/>
</event>
<property name="all"/>

Длительность указывается в микросекундах, поэтому 1000000 — это одна секунда. Ошибка на три нуля в эту сторону — самый популярный способ получить сотню гигабайт логов за ночь.

В выхлопе ищем текст SQL-запроса и его план. Обычно виновник виден сразу: соединение без условия, обращение к таблице по неиндексированному полю, выборка всех строк регистра там, где нужны десять.

Дальше это задача для программиста 1С, а не для администратора. Но точная локализация — с текстом запроса, временем и частотой — превращает расплывчатое «отчёт тормозит» в конкретную задачу на два часа.

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

Клиент: оптовая торговля, 41 рабочее место, УТ на MS SQL, база 96 ГБ. Жалоба: «после обеда всё встаёт, утром нормально». Внутренний айтишник два месяца добавлял памяти серверу — с 32 ГБ довели до 96 ГБ. Не помогло ни на минуту.

Вопросы на входе дали: у всех, каждый день примерно с 14:30, во всех операциях, нарастало последние полгода. Комбинация «каждый день в одно время» сразу увела нас от гипотезы «мало памяти» — нехватка ресурсов не смотрит на часы.

Клиентскую сторону и сеть отсекли за двадцать минут: с сервера в 14:40 база тормозила точно так же, задержки в сети были в пределах 0,4 мс.

Счётчики сервера в 14:45 показали загрузку процессора 30 %, свободной памяти 40 ГБ, а вот средняя длина очереди к диску — 27 при норме до 2. Диск был перегружен полностью.

Ожидания SQL это подтвердили: PAGEIOLATCH_SH занимал 71 % всего времени ожидания. Задержка чтения по файлу данных — 84 мс вместо целевых 10.

Оставался вопрос: почему именно после обеда. Ответ нашёлся в расписании заданий на самом гипервизоре. В 14:00 стартовала репликация виртуальных машин на резервную площадку, настроенная полгода назад — ровно тогда, когда «начало нарастать». Репликация читала диски того же массива на полной скорости, и базе не оставалось ничего.

Починка заняла пятнадцать минут: окно репликации перенесли на 01:00 и ограничили ей полосу. Очередь к диску вернулась к 1,5, задержка чтения — к 7 мс.

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

Полный проход по всем пяти шагам у нас занимает около двух часов на незнакомой системе. Из них час — сбор данных, час — их осмысление.

Что фиксируем в отчёте обязательно:

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

Последний пункт превращает работу из «мы там что-то покрутили» в измеримый результат. У клиента-производственника после разведения окон обслуживания и правки MAXDOP проведение реализации ушло с 14 секунд до 3, а формирование ОСВ за квартал — с 2 минут 40 секунд до 47 секунд. Эти два числа в отчёте объясняют ценность работы лучше любого описания.

И совет напоследок: не меняйте несколько вещей одновременно. Соблазн велик, особенно когда видно сразу три проблемы. Но тогда вы не узнаете, что именно помогло, и в следующий раз начнёте с нуля.

С чего начинать, если 1С тормозит у всех?

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

Какая задержка сети допустима для тонкого клиента 1С?

До 1 мс в локальной сети — комфортно, 5–15 мс — уже заметно на списках, выше 40 мс работа становится некомфортной. Тонкий клиент чувствителен именно к задержке, а не к ширине канала, поэтому увеличение скорости канала обычно не помогает.

Что важнее для 1С — число ядер или частота?

Частота. Значительная часть работы платформы однопоточная, поэтому сервер с 8 ядрами по 3,6 ГГц на типовых операциях обгоняет сервер с 32 ядрами по 2,1 ГГц. Многоядерность помогает при большом числе одновременных пользователей, но не ускоряет отдельную операцию.

Как понять, что проблема в коде, а не в железе?

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