Как заставить 1С работать быстрее

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

Типичные симптомы выглядят по-разному: документ проводится 30 секунд, отчёт строится минутами, база «подвисает» у всех пользователей одновременно или только у одного. Каждый из этих сценариев указывает на разные узкие места, и лечить их нужно по-разному. Массовые зависания чаще связаны с сервером и СУБД, а проблема у одного пользователя — с клиентским компьютером, кэшем или антивирусом.

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

Шаг 1. Найдите узкое место, а не гадайте

Прежде чем что-то менять, зафиксируйте, где теряется время. Включите технологический журнал на сервере 1С и соберите события длительностью, например, более 5 секунд: запросы СУБД (DBMSSQL/DBPOSTGRS), вызовы, транзакции и блокировки (TLOCK, TDEADLOCK). Это покажет, какие именно запросы и операции тормозят систему, а не «ощущения пользователей».

Параллельно посмотрите загрузку сервера штатными средствами: диспетчер задач или Performance Monitor на Windows Server, iostat и top на Linux. Ключевые показатели — длина очереди диска, загрузка CPU, свободная память и активность файла подкачки. Если диск постоянно загружен на 100%, никакая оптимизация запросов не даст заметного эффекта.

Полезно разделить проблему по масштабу: тормозит у всех — смотрите сервер и СУБД; тормозит у одного пользователя — проверяйте его ПК, сеть, антивирус и локальный кэш метаданных; тормозит одна операция — анализируйте конкретный запрос или проведение документа.

Шаг 2. Проверьте оборудование: диски и память решают больше половины проблем

Главное правило для файловой и клиент-серверной 1С: база должна лежать на SSD, а не на HDD. Механический диск физически не способен обслуживать сотни мелких случайных операций чтения-записи, которые генерирует СУБД. Перевод базы с HDD на SSD часто ускоряет работу в разы без каких-либо других изменений.

Оперативной памяти должно хватать под СУБД и рабочие процессы сервера 1С одновременно. Если SQL Server или PostgreSQL не может держать активную часть базы в памяти, каждый запрос идёт на диск. Признак нехватки RAM — активное использование файла подкачки и высокие показатели чтения с диска при умеренной нагрузке. Как ориентир для средних баз — память сервера должна быть сопоставима с размером активно используемой части базы, точный объём подбирается по мониторингу.

Для файловых баз критична ещё и сеть: работа по медленному Wi-Fi или через VPN с высокой задержкой убивает производительность. Файловую базу нельзя размещать на сетевом диске с нестабильным соединением — это не только медленно, но и рискованно для целостности данных.

Шаг 3. Настройте СУБД под нагрузку 1С

Если база работает на MS SQL Server или PostgreSQL, настройки «по умолчанию» почти всегда неоптимальны. Для MS SQL Server проверьте: ограничение максимальной памяти сервера (оставьте ОС и серверу 1С достаточный объём), размещение tempdb на быстром диске с несколькими файлами данных, модель восстановления базы (для большинства случаев достаточно Simple, если нет требований к точечному восстановлению) и отключённое автосжатие базы.

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

Для PostgreSQL аналогично важны autovacuum настройки и регулярный ANALYZE. Разросшиеся таблицы с «мёртвыми» строками — частая причина деградации производительности баз, которые изначально работали быстро.

-- MS SQL: обновление статистики по всем таблицам базы
EXEC sp_MSforeachtable 'UPDATE STATISTICS ? WITH FULLSCAN';

Шаг 4. Приведите в порядок итоги, индексы и данные

Регистры накопления и сведений растут быстрее всего. Проверьте, включено ли использование итогов у регистров накопления и сдвинут ли период рассчитанных итогов близко к текущей дате — если итоги рассчитаны по старый период, каждый отчёт и проведение пересчитывают огромные объёмы данных. Выполните пересчёт итогов в меню «Все функции → Стандартные → Управление итогами».

Большой объём устаревших данных — сам по себе тормоз. Помеченные на удаление объекты, годами не удаляемые, версии объектов, история изменений, протоколы обменов — всё это раздувает таблицы. Регулярно выполняйте удаление помеченных объектов и настройте штатные механизмы очистки устаревших данных, если они есть в вашей конфигурации.

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

Шаг 5. Разгрузите сервер: регламентные задания и пользовательские привычки

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

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

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

Шаг 6. Когда проблема в коде конфигурации

Если сервер настроен, а конкретная операция всё равно выполняется минутами — причина почти наверняка в коде или запросах конфигурации. Классические источники: запросы в цикле, обращение к данным через точку от ссылки в цикле («разыменование»), отсутствие индексов по полям условий запроса, получение всей таблицы вместо выборки нужных полей, неуправляемые блокировки при проведении.

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

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

Шаг 7. Проверьте результат и закрепите эффект

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

Ускорение — не разовая акция. Настройте регулярный регламент: еженощное обновление статистики, еженедельная реиндексация, ежемесячный контроль размера базы, журнала транзакций и списка фоновых заданий. Тогда деградация будет заметна на ранней стадии, а не когда пользователи начнут жаловаться.

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