Администрирование · 11 мин
Как оптимизировать систему 1С: пошаговое руководство
Как оптимизировать работу 1С: диагностика узких мест, настройка СУБД, индексы, регламентные задания и типичные ошибки. Пошаговые инструкции для администраторов.
Медленная 1С почти всегда имеет конкретную причину: нехватку ресурсов сервера, неоптимальные запросы, разросшиеся таблицы или ошибки в настройке СУБД. Оптимизация начинается не с покупки нового оборудования, а с диагностики: нужно понять, где именно теряется время — на клиенте, на сервере 1С или в базе данных.
Практический подход прост: сначала собираем метрики и находим самый «дорогой» участок, затем устраняем его, после чего повторно замеряем результат. Без замеров оптимизация превращается в гадание, а изменения в конфигурации или настройках сервера могут ухудшить ситуацию.
Материал рассчитан на администраторов и внедренцев, работающих с клиент-серверной 1С на платформе 8.3 с СУБД MS SQL Server или PostgreSQL. Отдельные разделы полезны и для файлового режима, но основной эффект даёт работа именно с серверной инфраструктурой.
Диагностика: как найти узкое место
Первый шаг — определить, где теряется время. Для этого включите технологический журнал на сервере 1С: он фиксирует длительные вызовы, запросы к СУБД, блокировки и ошибки. Настройка выполняется через файл logcfg.xml в каталоге conf сервера 1С. Собирайте события DBMSSQL (или DBPOSTGRS), TLOCK, TDEADLOCK и EXCP за период, когда пользователи жалуются на тормоза.
Параллельно смотрите счётчики производительности операционной системы: загрузку CPU, дисковую очередь, объём доступной памяти на сервере СУБД. Если дисковая очередь постоянно выше 2–3, проблема почти наверняка в подсистеме хранения, а не в коде конфигурации.
Смотрите длительные запросы в технологическом журнале
Проверьте CPU, память и дисковую очередь сервера
Замерьте время выполнения и проанализируйте план запроса
Ищите события TDEADLOCK и анализируйте порядок обращения к таблицам
Настройка СУБД: где теряется большая часть производительности
На MS SQL Server проверьте три вещи в первую очередь. Во-первых, ограничение памяти: по умолчанию SQL Server может занять почти всю ОЗУ, оставив системе и серверу 1С минимум. Установите max server memory так, чтобы ОС оставалось не менее 4–8 ГБ. Во-вторых, модель восстановления базы: для большинства баз достаточно Simple, если нет требований к восстановлению на произвольный момент времени, — это снижает нагрузку на журнал транзакций. В-третьих, размещение tempdb: желательно на быстром диске, с несколькими файлами данных.
Для PostgreSQL критичны параметры shared_buffers (обычно 25–30% ОЗУ), work_mem и настройки автовакуума. Отключённый или слишком редкий autovacuum приводит к раздуванию таблиц и деградации запросов со временем — это одна из самых частых причин «медленного старения» базы на PostgreSQL.
Индексы и обслуживание базы
Со временем индексы фрагментируются, а статистика устаревает — оптимизатор запросов начинает выбирать плохие планы. Настройте регулярное обслуживание: обновление статистики ежедневно (в нерабочее время), реорганизацию или перестроение индексов по расписанию. Для баз с интенсивной записью это даёт заметный эффект уже в первую неделю.
Отдельная тема — недостающие индексы. Если в технологическом журнале видны запросы с полным сканированием больших таблиц, а план запроса показывает Index Scan или Table Scan там, где ожидается Index Seek, индекса не хватает. В типовых конфигурациях добавлять индексы напрямую в СУБД нельзя — они будут удалены при обновлении структуры. Правильный путь — добавить индекс в конфигураторе (свойство «Индексировать» у реквизита или индекс регистра) либо изменить запрос.
- 1Создайте полную резервную копию базы перед любыми работами
- 2Настройте ежедневное обновление статистики в нерабочее время
- 3Настройте еженедельную реорганизацию или перестроение индексов
- 4Раз в месяц проверяйте топ длительных запросов из технологического журнала
- 5После каждого обслуживания замерьте время типовых операций и сравните с исходным
Регламентные задания и фоновые процессы
Частая причина «периодических тормозов» — регламентные задания, которые запускаются в рабочее время и конкурируют с пользователями. Откройте консоль заданий и проверьте расписание: полнотекстовое индексирование, обмены данными, расчёт итогов, загрузка курсов и тяжёлые обработки должны выполняться ночью или в обеденное окно.
Проверьте, нет ли заданий, которые выполняются каждую минуту, хотя достаточно раза в час. Каждое задание — это сеанс, соединение с СУБД и нагрузка на сервер. Также убедитесь, что не включены неиспользуемые механизмы: например, полнотекстовый поиск, если им никто не пользуется, или управление итогами у регистров, где итоги не нужны.
Оптимизация кода и запросов конфигурации
Если узкое место — конкретный отчёт или документ, анализируйте запросы. Типичные проблемы: соединения с виртуальными таблицами без отборов, запросы в цикле, выборка всех полей вместо нужных, использование функций над полями в условиях (это отключает индексы), соединения по полям составного типа.
Инструменты: режим замера производительности в конфигураторе покажет самые затратные строки кода, а план запроса в СУБД — реальную стоимость операций. Правило простое: сначала устраните самый дорогой участок, замерьте результат, и только потом переходите к следующему. Переписывание всего подряд без замеров почти всегда заканчивается регрессом.
Для доработанных конфигураций проверьте обработчики проведения и подписки на события: нередко при записи документа отрабатывает десяток подписок, каждая из которых выполняет свой запрос. Объединение логики или её перенос в фоновое задание заметно ускоряет проведение.
Инфраструктура: когда железо действительно виновато
Апгрейд оборудования оправдан, когда диагностика показала упор в ресурсы: постоянная загрузка дисков, нехватка памяти с активным свопингом, CPU на 100% в часы пик. Приоритеты обычно такие: сначала быстрые диски (SSD/NVMe для файлов базы и tempdb), затем память, затем процессор.
Для файлового режима главные ограничения — сеть и дисковая подсистема файлового сервера. При росте числа пользователей выше 10–15 файловый режим почти всегда становится узким местом, и правильное решение — переход на клиент-серверную архитектуру, а не наращивание мощности файлового сервера.
Разнесение ролей тоже помогает: сервер 1С и сервер СУБД на разных машинах (или хотя бы с чётким разграничением памяти), веб-сервер и сервер лицензий — отдельно при большой нагрузке. Для тонких клиентов проверьте канал связи: высокий пинг до сервера ощущается пользователями как «тормозящая 1С», хотя сама система работает быстро.
Как выбрать действие
Проверка результата и поддержание эффекта
Любое изменение считается завершённым только после контрольного замера. Выберите 5–10 типовых операций (проведение документа, открытие журнала, формирование ключевого отчёта) и фиксируйте время их выполнения до и после оптимизации в сопоставимых условиях — в одно время суток, при схожей нагрузке.
Оптимизация — не разовое действие. База растёт, меняется нагрузка, выходят обновления платформы и конфигурации. Раз в квартал повторяйте базовую диагностику: топ длительных запросов, состояние индексов, размер таблиц, расписание заданий. Это позволяет ловить деградацию до того, как пользователи начнут жаловаться.
Как проверить результат
Сократилось или стабильно при росте объёма данных
Растёт пропорционально объёму базы без видимых причин
Длительных запросов (более нескольких секунд) единицы
Массовые события DBMSSQL с длительностью в десятки секунд
Близка к нулю большую часть времени
Стабильно выше 2–3 в рабочие часы
Отсутствуют или единичны
Регулярные события TDEADLOCK в журнале
Что важно запомнить
Эффективная оптимизация 1С строится по циклу: замер — диагностика — точечное исправление — контрольный замер. Основные источники проблем: настройки СУБД, состояние индексов, регламентные задания в рабочее время и неоптимальные запросы. Апгрейд железа — последний шаг, а не первый.
Частые вопросы
С чего начать, если 1С тормозит у всех пользователей одновременно?
Одновременная деградация у всех — признак проблемы на сервере, а не в конфигурации. Сначала проверьте загрузку CPU, памяти и дисковую очередь на сервере СУБД, затем посмотрите активные запросы и блокировки. Часто причина — запущенное обслуживание, тяжёлый отчёт или нехватка памяти из-за неограниченного SQL Server.
Можно ли оптимизировать типовую конфигурацию без снятия с поддержки?
Да, значительная часть мер не требует изменения кода: настройка СУБД, обслуживание индексов и статистики, перенос регламентных заданий в нерабочее время, отключение неиспользуемых механизмов, настройка технологического журнала. Изменения кода стоит рассматривать только после того, как исчерпаны эти варианты.
Как понять, что проблема в запросе, а не в сервере?
Если тормозит конкретная операция при нормальной загрузке сервера, почти наверняка дело в запросе или коде. Включите технологический журнал, найдите длительный запрос, получите его план в СУБД и ищите полные сканирования больших таблиц, отсутствующие индексы или соединения без отборов.
Как часто нужно перестраивать индексы?
Универсальной нормы нет: частота зависит от интенсивности записи. Практичный ориентир — перестроение или реорганизация раз в неделю в нерабочее время и ежедневное обновление статистики. Ориентируйтесь на фактическую фрагментацию: для малоизменяемых таблиц частое обслуживание бессмысленно.
Стоит ли чистить базу от старых данных для ускорения?
Да, свёртка итогов и перенос старых периодов в архивную базу заметно уменьшают размер таблиц и ускоряют запросы. Но делайте это штатными средствами конфигурации, с резервной копией и после согласования с пользователями: доступ к истории может быть нужен для отчётности и проверок.
Поможет ли переход на более новую версию платформы?
Иногда да: новые версии платформы содержат оптимизации механизмов и исправления ошибок производительности. Однако переход требует тестирования совместимости с конфигурацией и не заменяет диагностику — если проблема в конкретном запросе или настройке СУБД, смена версии её не решит.