Как ускорить 1С 8.3: практическое руководство по оптимизации

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

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

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

Шаг 1. Найдите узкое место с помощью замеров

Замер производительности в конфигураторе показывает, какие строки кода и запросы занимают больше всего времени. Запустите его, выполните проблемную операцию (например, проведение документа) и отсортируйте результат по колонке времени. Обычно 2–3 запроса дают 80% времени выполнения — с ними и нужно работать.

Для серверного уровня полезен технологический журнал (ТЖ): он фиксирует длительные вызовы СУБД, взаимоблокировки и ошибки. Настройте его через файл logcfg.xml, указав порог длительности событий (например, события DBMSSQL/DBPOSTGRS дольше 1–2 секунд). Не оставляйте подробный ТЖ включённым постоянно — он сам создаёт нагрузку на диск.

Полезный индикатор — монитор загрузки сервера во время «тормозов». Если процесс СУБД (sqlservr, postgres) упирается в 100% CPU или дисковую очередь — проблема в ресурсах или запросах. Если сервер свободен, а пользователи ждут — смотрите сеть и блокировки.

Шаг 2. Настройте обслуживание базы данных

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

Для MS SQL Server настройте регламентный план обслуживания: ежедневное обновление статистики, еженедельную реорганизацию или перестроение индексов (в нерабочее время), периодическую очистку процедурного кэша. Для PostgreSQL убедитесь, что работает autovacuum, и при больших объёмах изменений настройте его агрессивнее значений по умолчанию.

Для файловых баз периодически выполняйте «Тестирование и исправление» с реструктуризацией и сжатием (только при монопольном доступе и после резервной копии). Файловый режим вообще плохо масштабируется: при активной работе более 5–10 пользователей переход на клиент-серверный вариант даст больший эффект, чем любые настройки.

1. 1
   Сделайте полную резервную копию базы
2. 2
   Настройте ежедневное обновление статистики (UPDATE STATISTICS)
3. 3
   Настройте еженедельное перестроение индексов в нерабочее время
4. 4
   Проверьте, что модель восстановления соответствует политике бэкапов (Simple или Full с бэкапом журнала)
5. 5
   Через неделю сравните время выполнения типовых операций с замером «до»

Шаг 3. Проверьте аппаратные ресурсы сервера

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

Оперативной памяти должно хватать, чтобы СУБД держала в кэше активную часть базы. Если сервер постоянно читает данные с диска (высокие значения Page reads/sec, низкий Buffer cache hit ratio в MS SQL), добавление RAM — самый дешёвый способ ускорения. Диски — предпочтительно SSD; размещение базы 1С на медленных HDD или сетевом хранилище почти гарантирует проблемы.

Отдельная тема — виртуализация. Сервер 1С на виртуальной машине нормально работает, если ему выделены фиксированные ресурсы без переподписки (overcommit) и диски не конкурируют с другими нагруженными VM. Проверьте у администратора гипервизора, нет ли «соседей», отъедающих дисковую производительность.

Шаг 4. Оптимизируйте настройки сервера 1С и клиентов

В консоли кластера серверов 1С проверьте количество рабочих процессов (rphost). На сервере с большим объёмом памяти несколько рабочих процессов позволяют распределить нагрузку и изолировать сбои. Также настройте периодический перезапуск рабочих процессов — это снижает эффект утечек памяти и накопления «мусора» в длительно работающих сеансах.

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

Для удалённых пользователей рассмотрите тонкий клиент или веб-клиент вместо толстого — они передают по сети значительно меньше данных. При работе через медленные каналы (VPN, филиалы) хороший эффект даёт публикация базы на веб-сервере или использование терминального доступа, когда по сети идёт только «картинка».

Шаг 5. Разберитесь с регламентными заданиями и фоновой нагрузкой

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

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

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

Шаг 6. Оптимизируйте код и данные конфигурации

Если замеры показали, что время уходит в конкретные запросы, типовые приёмы таковы: выбирать только нужные поля вместо «ВЫБРАТЬ *», использовать индексированные поля в условиях, избегать запросов в цикле (заменять на один запрос с временными таблицами), не использовать соединения с подзапросами там, где достаточно временной таблицы.

На уровне данных помогает своевременное сворачивание итогов по регистрам, установка даты запрета редактирования (уменьшает объём проверок при проведении), архивация старых периодов в отдельную базу. Отчёты по большим периодам стоит строить на остатках и оборотах регистров, а не пересчитывать движения документов.

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

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

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

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

Контрольные точки

Как проверить результат

Время проведения типового документа

Норма

Сократилось по сравнению с замером «до» и стабильно в течение дня

Тревожный признак

Улучшение есть только сразу после обслуживания, затем деградация

Загрузка сервера в часы пик

Норма

CPU и диски не упираются в 100% длительное время

Тревожный признак

Постоянные 100% CPU процесса СУБД или большая дисковая очередь

Жалобы пользователей

Норма

Жалобы прекратились или локализованы к конкретной операции

Тревожный признак

Тормозит по-прежнему у всех — узкое место не найдено

Технологический журнал

Норма

Длительных запросов и взаимоблокировок стало заметно меньше

Тревожный признак

Появились новые длительные события после изменений

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

Сколько оперативной памяти нужно серверу 1С?

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

Ускорит ли работу переход с файловой базы на клиент-серверную?

Да, если работает больше нескольких пользователей одновременно. Файловый режим блокирует данные при записи и гоняет большие объёмы по сети. Клиент-серверный вариант переносит обработку на сервер СУБД, что особенно заметно на проведении документов и отчётах.

Можно ли ускорить 1С, не трогая код конфигурации?

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

Почему 1С тормозит только утром или в конце месяца?

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

Помогает ли «Тестирование и исправление» базы?

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

Что делать, если после всех настроек ничего не изменилось?

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