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

Разгон 1С почти никогда не сводится к одной кнопке. Тормозит либо база (разросшиеся таблицы, устаревшая статистика SQL, забитый журнал регистрации), либо сервер (мало памяти рабочим процессам, слабый диск под tempdb), либо рабочее место (толстый клиент по медленной сети, прямой доступ к файловой базе через VPN). Начинать нужно не с настроек наугад, а с замера: где именно уходит время.

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

Сначала измеряем: где именно теряются секунды

Пока не известно, что тормозит, любая настройка — лотерея. В типовых конфигурациях на БСП есть встроенный замер: Администрирование → Оценка производительности. Включите его на пару рабочих дней — система соберёт времена ключевых операций (проведение, открытие списка, формирование отчёта) и посчитает показатель APDEX по каждой. Операции с APDEX ниже 0,5 — ваши главные кандидаты на оптимизацию.

Для клиент-серверного варианта точнее работает технологический журнал (logcfg.xml в каталоге conf платформы) и, если есть КИП, центр управления производительностью. Но для большинства задач хватает оценки из БСП плюс наблюдения: тормозит у всех или у одного пользователя, при любых операциях или только при проведении, постоянно или в пики.

Индексы и статистика: почему SQL «думает» дольше

В клиент-серверном варианте 90% тормозов на проведении и в отчётах — это устаревшая статистика и фрагментация индексов на стороне СУБД. 1С строит индексы сама, но СУБД со временем перестаёт понимать, как по ним искать эффективнее.

Два ключевых действия на стороне MS SQL Server:

1. Обновление статистики — самое недооценённое. Регулярный UPDATE STATISTICS (или план обслуживания с полным пересчётом) часто ускоряет тяжёлые отчёты в разы, при этом почти бесплатен по времени.
2. Перестроение и реорганизация индексов — ALTER INDEX ... REBUILD при фрагментации выше 30%, REORGANIZE при 5–30%. Планируйте на ночь.

Для MS SQL проверьте модель восстановления базы: для большинства рабочих баз 1С подходит Simple — она не ведёт бесконечно растущий лог транзакций. Полная модель (Full) нужна только если вы делаете поточные бэкапы лога; иначе файл .ldf раздувается и тормозит диск.

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

Для файловой базы прямого доступа к индексам нет, но её аналог лечения — Тестирование и исправление в конфигураторе (Администрирование → Тестирование и исправление) с галками реструктуризации таблиц и пересчёта итогов. А перед этим — chdbfl.exe из каталога платформы для проверки физической целостности файла 1Cv8.1CD.

Настройка кластера и рабочих процессов

На сервере 1С за скорость отвечают настройки кластера в консоли администрирования. Клиент сначала обращается к агенту сервера (порт 1540), затем к менеджеру кластера (1541), а тот распределяет работу между рабочими процессами rphost (их диапазон портов задаётся в свойствах рабочего сервера). Если rphost упирается в память — всё встаёт.

Что проверить в свойствах кластера и рабочего сервера:

• 🧮 Допустимый объём памяти процессов — не ставьте впритык. Процесс, превысивший лимит, принудительно перезапускается, обрывая операции пользователей.
• ⏱ Интервал перезапуска рабочих процессов — плановый перезапуск rphost (например, раз в сутки ночью) освобождает утёкшую память. Днём его лучше не назначать.
• 🧩 Количество информационных баз на процесс — для крупной базы имеет смысл отдать ей отдельный рабочий процесс, чтобы соседние базы не отъедали ресурсы.
• 🖥 Требования назначения функциональности — на мощной ферме можно развести фоновые задания и клиентские соединения по разным рабочим серверам.

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

Журнал регистрации и служебные данные разрослись

Журнал регистрации пишет каждое действие каждого пользователя. За годы он превращается в гигабайты, и база открывается, пишет и ищет медленнее. В платформе 8.3 журнал хранится в каталоге 1Cv8Log (файл формата SQLite).

Что с этим делать:

• Сократите глубину хранения: в конфигураторе Администрирование → Настройка журнала регистрации задайте разделение по периодам и срок, после которого старые записи удаляются (например, хранить 3–6 месяцев).
• Отключите запись заведомо лишних событий, если журнал ведётся «на всякий случай» и реально не анализируется.
• Помеченные на удаление объекты удаляйте регулярно (Администрирование → Обслуживание → Удаление помеченных объектов) — они занимают место в таблицах и замедляют отбор.

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

Клиент, сеть и кэш: ускоряем рабочее место

Если тормозит у конкретных людей, а у остальных нет — дело в рабочем месте или канале.

Тонкий клиент вместо толстого. Толстый клиент тянет по сети много данных; тонкий общается с сервером компактными запросами. Для клиент-серверной базы работайте через тонкий клиент, а ещё лучше — через веб-клиент или опубликованное приложение, если каналы разные по качеству.

Удалённые пользователи — через терминал. Прямое подключение к файловой базе по общей папке через VPN — худший сценарий по скорости и надёжности. Для удалённой работы поднимите терминальный сервер (RDP/RemoteApp) рядом с базой: по сети тогда бегает только картинка, а не данные базы.

Чистка кэша. Накопленный клиентский кэш иногда сам по себе тормозит и глючит. Запуск с ключом /ClearCache или удаление каталога кэша пользователя (в профиле, папки с именем базы) решает «необъяснимые» подвисания одного компьютера. Данные базы при этом не страдают — чистится только локальный кэш.

Сеть. Для сервера 1С и СУБД — гигабитная сеть и минимальная задержка (ping между клиентом и сервером в идеале единицы миллисекунд). 1С чувствительна к задержкам: канал с большим ping «съест» любую оптимизацию базы.

Начальная страница и лишние формы. Если тяжело открывается сама программа, посмотрите, что показывается на начальной странице: десяток форм списков, которые подгружаются при старте, ощутимо замедляют вход. Уберите с неё редко нужные формы. А отключение неиспользуемых функциональных опций (Администрирование → Функциональность или аналогичный раздел настроек) уменьшает объём метаданных, которые клиент разбирает при запуске.

Файловая, SQL и железо: когда апгрейд неизбежен

Файловая база хороша для одного-двух пользователей и небольшого объёма. Когда работающих одновременно больше 5–10 или файл 1Cv8.1CD разросся до нескольких гигабайт, упираешься в потолок самого формата — тут уже не настройки, а архитектура.

Переход на клиент-серверный вариант (MS SQL Server или PostgreSQL) снимает это ограничение: СУБД управляет блокировками, кэширует данные в памяти, параллелит работу. Это самый действенный шаг для растущей базы, но и самый затратный — нужны лицензии сервера 1С и подготовка СУБД.

По железу порядок отдачи обычно такой:

Для MS SQL отдельно отрегулируйте максимальную память сервера (max server memory), чтобы СУБД не вытесняла из памяти сам сервер 1С, если они на одной машине. Параметр параллелизма (MAXDOP) для нагрузки 1С традиционно выставляют осторожно — уточните актуальную рекомендацию для вашей версии платформы и СУБД, прежде чем менять.

Регламент обслуживания: чтобы не тормозило снова

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

Регламентные и фоновые задания в самой конфигурации тоже стоит развести по времени: обмены данными, загрузка банковских выписок, расчёт себестоимости не должны стартовать одновременно в рабочие часы. Расписание — в Администрирование → Обслуживание → Регламентные операции (в клиент-серверном варианте задания выполняет сервер, в файловом — только при открытом клиенте).

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

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