Почему тормозит 1С и что с этим делать

Сначала измерить, потом чинить

Главная ошибка — начинать с закупки железа. Медленная 1С в большинстве случаев упирается не в мощность сервера, а в конкретную операцию: одно проведение документа, один отчёт, одно фоновое задание.

Порядок диагностики простой:

1. Что именно медленно. Проведение? Открытие списка? Формирование отчёта? Закрытие месяца? У каждой проблемы свои причины.
2. У всех или у одного. Если тормозит у одного пользователя — смотрим его рабочее место и канал. Если у всех — сервер или база.
3. Постоянно или в пики. Утренний час, когда все проводят документы, — это почти всегда блокировки, а не производительность.

Пять частых причин

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

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

Отсутствие обслуживания базы. Индексы фрагментированы, статистика устарела — СУБД строит неоптимальный план запроса. Лечится регламентными заданиями по расписанию, а не разово.

Настройки СУБД и сервера. Память, отданная под SQL Server, режим восстановления, размещение файлов данных и журнала транзакций на одном диске — типичные места, где производительность теряется на ровном месте.

Дисковая подсистема. 1С чувствительна к задержкам дисков. Медленный диск виден сразу: очередь к диску растёт, процессор при этом простаивает.

Что делать по шагам

• Снять замеры. Штатный замер производительности в конфигураторе показывает, какие строки кода занимают время. Это первое, что стоит сделать.
• Посмотреть журнал регистрации. Долгие операции и ошибки видны там же.
• Проверить регламентные задания. Часто выясняется, что обслуживание индексов либо не настроено, либо запускается в рабочее время.
• Разделить нагрузку. Тяжёлые отчёты и обмены выносятся в фоновые задания на ночь, чтобы не конкурировать с работой пользователей.
• И только потом — оборудование. Когда понятно, во что упирается система, апгрейд бьёт в цель, а не «на всякий случай».

Чего делать не стоит

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