Производительность 1С — типовые узкие места и как их искать

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

1. Блокировки и взаимоблокировки

Главная причина «зависаний» при большом числе одновременных пользователей. Документ блокирует регистр на запись, второй пользователь ждёт.

Где искать:

• Центр администрирования 1С: журнал блокировок.
• На MS SQL: sys.dm_tran_locks, sp_who2.
• На PostgreSQL: pg_locks, pg_stat_activity.

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

2. Тяжёлые запросы в обработках и отчётах

Обычно — соединения в цикле, чтение в цикле, отсутствие условий по дате/регистру в больших таблицах.

Где искать:

• Технологический журнал 1С с фильтром QUERY и длительностью >1 сек.
• В SSMS / pgAdmin — топ-50 запросов по среднему времени.

Фикс: перенести логику из цикла в запрос, убрать ВЫРАЗИТЬ(...) в WHERE на большие таблицы, добавить условия по периоду.

3. Регистры накопления без устаревших итогов

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

Проверка: «Управление итогами» в режиме конфигуратора. Расчёт итогов — раз в месяц после закрытия периода.

4. Отсутствующие или лишние индексы

1С создаёт индексы на основе свойств «Индексирование» в реквизитах. Часто:

• Реквизит «Контрагент» в большом регистре не проиндексирован — отчёт по контрагенту 10 секунд.
• Индекс есть, но не используется из-за неправильного порядка полей.
• На таблицу 50 индексов — каждое UPDATE замедляется.

На PostgreSQL — pg_stat_user_indexes покажет, какие индексы вообще не используются.

5. Обмены данных в рабочее время

Cron-обмен с сайтом или другой 1С каждые 15 минут — пользователи ловят блокировки. Большая выгрузка данных в Excel или DataLens тоже стопит.

Фикс: тяжёлые обмены в ночное окно, мелкие — асинхронно через очередь без захвата объектов.

6. Тонкий клиент и сеть

Пользователь в Хабаровске работает с сервером в Москве через RDP — задержки. Меняют RDP на тонкий клиент по HTTPS — становится в 3-5 раз медленнее, потому что тонкий клиент гоняет много мелких запросов.

Реальная пропускная способность тонкого клиента на канале 50 Мбит с пингом 80 мс — норма для офиса в РФ. С пингом >150 мс — невыносимо.

Фикс: терминальный сервер ближе к пользователям, не тонкий клиент через интернет.

Инфраструктура

• CPU сервера 1С — 2-3 ядра на 25 активных пользователей.
• RAM сервера БД — минимум размер активных регистров + 30%.
• SSD под БД — обязательно, не SATA HDD.
• Отдельный диск под tempdb (MS SQL) или WAL (PG).
• Свежая версия платформы 1С — 8.3.24+ в 2026.

Как искать

1. Включить технологический журнал на сервере 1С с фильтром DURATION>5000.
2. Снять метрики Performance Counters на сервере СУБД за нагрузочный час.
3. Найти топ-10 самых медленных запросов.
4. Проанализировать планы выполнения.
5. Чинить по приоритету: блокировки → запросы → индексы → инфра.

Что не работает

• «Добавить памяти на сервер» — не помогает, если узкое место в коде.
• «Купить новую платформу 1С» — без оптимизации эффект 5-15%.
• «Перейти с MS SQL на PostgreSQL» — само по себе не ускоряет, требует другой настройки.

Вывод

«1С тормозит» — слишком общая формулировка. Конкретные узкие места: блокировки, тяжёлые запросы, регистры без итогов, индексы, обмены в рабочее время, тонкий клиент через медленный канал. Лечатся по приоритету через техжурнал и метрики СУБД. Без замера — стрельба в темноту.