1С тормозит на Accounting: снять замер, не крутить все галочки сразу

Короткий ответ

«1С тормозит» — это не диагноз. Сначала измерьте, где уходит время: клиент (CPU/диск ПК), сеть до SRV-1C, кластер (rphost CPU/RAM), SQL на SQL01 (waits, блокировки, диск данных и TempDB), либо ожидание чужой транзакции. Не включайте одновременно технологический журнал «все события», SQL Trace/Extended Events «всё подряд» и maxdop наугад: вы добавите нагрузку и потеряете картину.

База Accounting на экземпляре MSSQLSERVER. Если тормозит один документ у одного пользователя — это не «сервер слабый». Если все сеансы встали колом — ищите блокировку или диск SQL, не антивирус на одном ПК.

Симптомы и как отличить

Типичная картина:

• проведение реализации 2–15 минут, раньше секунды;
• открытие журнала «крутится», CPU на ПК 5%;
• все жалуются с 9:00, к обеду отпускает;
• rphost на SRV-1C по 2–4 ГБ, диск SQL01 в Latency.

Отличия:

Возможные причины

1. Блокировки: сеанс держит транзакцию (отбор в конструкторе запроса, «зависшая» форма, обмен).
2. Медленный диск тома данных/лога Accounting или общий LUN с бэкапами.
3. Сеть: филиал через узкий канал, RDP + толстый клиент, VPN без QoS.
4. Нехватка RAM у SQL: SQL съел всю память или наоборот — мало buffer pool, постоянный PAGEIOLATCH.
5. Тяжёлые запросы конфигурации, отсутствующие индексы, устаревшая статистика.
6. Рост TempDB из-за сортировок и версионности.
7. Антивирус сканирует *.mdf/*.ldf и каталог srvinfo.
8. Редко: повреждение индексов, устаревший план после обновления конфигурации.

Диагностика

Рабочие имена: SRV-1C, SQL01, база Accounting, instance MSSQLSERVER.

1. Где пользователь

С клиента:

Test-NetConnection SRV-1C -Port 1541
Test-Connection SQL01 -Count 10
Get-Counter '\Processor(_Total)\% Processor Time','\PhysicalDisk(_Total)\Avg. Disk sec/Read'

Если RTT до SRV-1C сотни миллисекунд — сначала сеть, не индекс в SQL.

2. Кластер

В консоли кластера: сеансы Accounting, «захвачено СУБД», время вызова. rphost в Task Manager: кто ест CPU. Не снимайте все процессы.

3. Блокировки и waits на SQL01

-- на SQL01, база Accounting
SELECT session_id, blocking_session_id, wait_type, wait_time, last_wait_type, status, command
FROM sys.dm_exec_requests
WHERE database_id = DB_ID(N'Accounting');

SELECT TOP 20 wait_type, waiting_tasks_count, wait_time_ms, signal_wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE N'WAITFOR%'
  AND wait_type NOT LIKE N'SLEEP%'
  AND wait_type NOT LIKE N'BROKER%'
ORDER BY wait_time_ms DESC;

LCK_M_X / LCK_M_S — блокировки. PAGEIOLATCH_* — диск/память. WRITELOG — журнал транзакций. SOS_SCHEDULER_YIELD / CXPACKET — CPU/параллелизм. Дальше — медленные запросы.

4. Диск

SELECT DB_NAME(database_id) AS db, file_id, num_of_reads, io_stall_read_ms, num_of_writes, io_stall_write_ms,
       io_stall_read_ms * 1.0 / NULLIF(num_of_reads,0) AS avg_read_ms,
       io_stall_write_ms * 1.0 / NULLIF(num_of_writes,0) AS avg_write_ms
FROM sys.dm_io_virtual_file_stats(NULL, NULL)
WHERE DB_NAME(database_id) IN (N'Accounting', N'tempdb');

Средние stall десятки миллисекунд на MDF/LDF — узкое место не «1С как программа».

5. Что не включать сразу

Не ставьте sp_configure 'remote query timeout' как лечение. Не включайте Extended Events с sqlserver.sql_statement_completed без фильтра на прод-нагрузке «на неделю». Для разового замера — см. статью про замер ТЖ и SQL.

Решение

Сценарий A. Есть blocker

Найдите сеанс 1С и SPID. Сохраните работу, если возможно. Снимите сеанс 1С из консоли кластера, не KILL всего rphost. KILL в SQL — крайняя мера, когда сеанс уже не виден в кластере, а транзакция жива. Подробнее: сеанс завис.

Сценарий B. Диск

Уберите backup job с того же тома в рабочее время, исключите MDF/LDF из realtime-сканера, проверьте тонкий диск гипервизора и очередь. Не shrink Accounting «для скорости» — это фрагментация и рост файла снова.

Сценарий C. Сеть

Филиал: тонкий клиент или веб-клиент, не файловая база через WAN. RDP ближе к SRV-1C, чем толстый клиент через 10 Мбит.

Сценарий D. SQL память и запросы

Выставьте max server memory, оставив ОС и rphost, если они на одной машине (лучше разнести). План запроса — точечно, не «rebuild all indexes каждую ночь в прайм».

EXEC sys.sp_configure N'show advanced options', 1;
RECONFIGURE;
-- пример: на SQL01 64 ГБ RAM, 1С на другом хосте SRV-1C
EXEC sys.sp_configure N'max server memory (MB)', 56000;
RECONFIGURE;

Подбирайте число по факту RAM хоста, не копируйте 56000 слепо.

Сценарий E. После обновления конфигурации

Сравните время проблемной операции на копии базы с замером ТЖ. Не оптимизируйте прод без воспроизведения.

Как проверить, что проблема устранена

1. Та же операция (проведение конкретного документа) у того же пользователя: время в секундах, не «вроде получше».
2. Повтор в час пик, не в субботу.
3. blocking_session_id пустой в рабочем окне.
4. Stall чтения MDF не вырос после ваших «улучшений».

Запишите: до/после, пользователь, документ, длительность, wait_type.

Если не помогло

• Тормоза только при отчётах — отдельный запрос/СКД, не проведение.
• После очистки кэша быстрее на 2 секунды — это не ваша проблема диска.
• Регулярно в 02:00 — пересечение backup, index maintenance, регламентных заданий 1С. Разведите окно.
• Рост базы без обслуживания статистики — обновите статистику в обслуживание, не в обед пятницы без плана отката.

Профилактика

• Регламент: замер производительности раз в квартал и после релизов конфигурации.
• Алерт по диску SQL, TempDB, blocking > N секунд.
• Не держать файловую базу на 30 пользователей «пока летает».
• Разнести SRV-1C и SQL01, если CPU бьётся.
• Антивирус: исключения на каталоги СУБД и кластера по политике, не «выключить Defender».

FAQ

Поможет ли перезагрузка SQL01 каждую ночь?

Нет как практика. Вы маскируете утечки планов и оставляете окно, когда recovery и прогрев кэша убивают утро.

Нужно ли включать trace flag 1204 постоянно?

Нет. Для deadlock — XEvents xml_deadlock_report точечно. TF навсегда без причины не ставьте.

Почему у директора быстро, у склада нет?

Разные формы, отборы, объём, иногда другой сервер в списке баз. Сверьте строку Srvr/Ref.

Можно ли ускорить, переведя базу в Simple recovery?

Не ради скорости OLTP. Simple ломает резервирование log и точку восстановления. Сначала диск и блокировки.

Стоит ли выкладывать кластер и SQL на одну VM «чтобы сеть не мешала»?

Совмещение упрощает сеть и усложняет память. Если так — обязательно делите RAM и диски. Иначе 1С и SQL душат друг друга, и «тормоза» не лечатся индексом.