Администрирование · 13 мин
Как оптимизировать 1С:Предприятие и ускорить работу системы
Практическое руководство по оптимизации 1С:Предприятие: настройка СУБД, сервера, регламентных заданий, индексов и кода. Причины медленной работы и способы их устранения.
Медленная работа 1С:Предприятие почти никогда не связана с одной-единственной причиной. Чаще всего это сочетание факторов: недостаток оперативной памяти на сервере СУБД, разросшиеся таблицы итогов, блокировки при параллельной работе пользователей, неоптимальные запросы в доработанных конфигурациях и регламентные задания, запущенные в разгар рабочего дня. Поэтому оптимизацию имеет смысл вести поэтапно: сначала диагностика, затем устранение самого «узкого» места, потом контроль результата.
Прежде чем что-либо менять, зафиксируйте текущее состояние: сколько времени занимает проведение типового документа, формирование ключевых отчётов, открытие списков. Без исходных замеров невозможно понять, дала ли оптимизация эффект или проблема просто переместилась в другое место. Для замеров подойдут встроенный замер производительности в конфигураторе, технологический журнал и счётчики производительности операционной системы.
Важно понимать архитектуру: в клиент-серверном варианте участвуют три звена — клиентское приложение, кластер серверов 1С и СУБД (MS SQL Server, PostgreSQL или другая поддерживаемая СУБД). Узкое место может находиться в любом из них, и методы оптимизации для каждого звена различаются. Ниже разобраны основные направления работы в порядке от диагностики к тонкой настройке.
Как найти узкое место: диагностика производительности
Первый инструмент диагностики — технологический журнал (ТЖ). Он включается через конфигурационный файл logcfg.xml, размещаемый в каталоге conf сервера 1С. В ТЖ фиксируются длительные вызовы СУБД, блокировки, события TLOCK, TDEADLOCK и длительные запросы. Настройте фильтр, например, на события DBMSSQL длительностью более нескольких секунд — это покажет самые тяжёлые запросы без избыточного объёма логов.
Второй источник — счётчики производительности ОС и СУБД. Смотрите загрузку дисковой подсистемы (очередь диска, время отклика), использование оперативной памяти, процессор и сеть. Если диск постоянно загружен на 100%, а памяти мало, проблема инфраструктурная, и никакая правка кода её не решит. Для MS SQL Server полезны динамические административные представления (DMV) по ожиданиям и самым ресурсоёмким запросам.
Третий инструмент — замер производительности в конфигураторе (Отладка → Замер производительности). Он показывает, какие строки кода и вызовы занимают больше всего времени при выполнении конкретной операции. Это особенно полезно, когда тормозит одна конкретная обработка или проведение конкретного вида документов.
Загрузка дисков, памяти, длительные запросы в ТЖ
Пинг до сервера, антивирус, версия платформы на клиенте
Расписание регламентных заданий, обмены, бэкапы
Незавершённые обработчики обновления, новые запросы в замере
Настройка СУБД: память, индексы и обслуживание
Большая часть тяжёлой работы в клиент-серверной 1С выполняется на стороне СУБД, поэтому её настройка даёт наибольший эффект. Для MS SQL Server задайте ограничение максимального объёма памяти (max server memory), оставив запас под операционную систему и сам сервер 1С, если они размещены на одной машине. Без ограничения SQL Server может занять почти всю память, вызывая нехватку ресурсов у других процессов.
Регулярное обслуживание базы обязательно: обновление статистики и перестроение (или реорганизация) индексов. Фрагментированные индексы и устаревшая статистика приводят к тому, что оптимизатор выбирает неудачные планы запросов, и типовые операции начинают выполняться в разы медленнее. Настройте план обслуживания на ночное время, согласовав его с окном резервного копирования.
Размещение файлов тоже имеет значение. Файлы данных, журнал транзакций и tempdb желательно располагать на быстрых дисках, по возможности раздельно. Растущий файл журнала транзакций — частая причина деградации: убедитесь, что выбрана подходящая модель восстановления и выполняется регламентное обслуживание журнала.
Настройка кластера серверов 1С
Кластер серверов 1С управляет рабочими процессами (rphost), которые исполняют код и обращаются к СУБД. Если рабочий процесс один, а пользователей много, при его перезапуске или аварии пострадают все. Рекомендуется настроить несколько рабочих процессов и ограничить объём памяти, при котором процесс перезапускается, — это защищает от утечек памяти в доработках.
Полезные настройки кластера: интервал перезапуска рабочих процессов, допустимый объём памяти процесса, выключенные процессы останавливать через заданное время. Точные значения подбираются под конкретную нагрузку — универсальных цифр нет, ориентируйтесь на мониторинг потребления памяти процессами rphost в пиковые часы.
Отдельный вопрос — размещение сервера 1С и СУБД. Для небольших баз допустимо размещение на одной машине, но при росте нагрузки их лучше разнести: оба процесса активно потребляют память и процессор, и конкуренция за ресурсы снижает производительность обоих. Сеть между серверами должна быть быстрой и стабильной, без Wi-Fi-сегментов.
Регламентные задания, итоги и обмены данными
Регламентные и фоновые задания — частая скрытая причина «периодических тормозов». Проверьте расписание всех заданий в консоли заданий: обмены с сайтом, синхронизации между базами, расчёты, загрузка курсов валют. Всё тяжёлое должно выполняться ночью или в обеденное окно, а не каждые пять минут в течение дня.
Для регистров накопления и бухгалтерии проверьте периодичность расчёта итогов. Хранение итогов по каждому периоду ускоряет отчёты, но замедляет запись; отключение итогов ускоряет проведение, но замедляет получение остатков. Практический компромисс — установить дату запрета редактирования и перенести рассчитанные итоги на актуальный период, а старые закрытые периоды оставить без пересчёта.
Объём данных напрямую влияет на скорость. Свертка базы за закрытые периоды, удаление помеченных объектов, очистка устаревших версий объектов и журналов — всё это уменьшает размер таблиц и ускоряет как запросы, так и обслуживание СУБД. Перед свёрткой обязательно сделайте копию и проверьте корректность остатков на копии.
- 1Зафиксируйте исходные замеры: время проведения документов и формирования отчётов
- 2Включите технологический журнал с фильтром на длительные запросы и блокировки
- 3Проверьте и перенесите регламентные задания и обмены на нерабочие часы
- 4Настройте план обслуживания СУБД: статистика, индексы, журнал транзакций
- 5Проверьте итоги регистров и установите дату запрета редактирования
- 6Выполните свёртку или удаление устаревших данных на копии, затем на рабочей базе
- 7Повторите замеры и сравните с исходными
Оптимизация кода и запросов в доработках
Если конфигурация дорабатывалась, значительная часть проблем обычно находится в прикладном коде. Классические ошибки: запросы в цикле, обращение к данным через точку от ссылочных полей («разворачивание» ссылок), выборка всех полей вместо нужных, отсутствие отборов по индексированным полям. Каждый запрос в цикле — это отдельное обращение к СУБД; правильный подход — собрать данные одним запросом с временными таблицами.
Используйте пакетные запросы и временные таблицы, выбирайте только необходимые поля, накладывайте отборы как можно раньше. Для виртуальных таблиц регистров всегда задавайте параметры отбора (период, измерения) — выборка остатков без параметров заставляет СУБД читать лишние данные. Конструктор запросов и план запроса в консоли СУБД помогают увидеть, какой путь выбирает оптимизатор.
Проверяйте доработки замером производительности до и после изменений. Если узкое место — типовой код конфигурации на поддержке, не спешите переписывать его: сначала убедитесь, что проблема не в инфраструктуре, иначе получите усложнение обновлений без реального выигрыша.
Блокировки и параллельная работа пользователей
Если база «встаёт» при одновременной работе нескольких пользователей, а по одиночным замерам всё быстро, причина почти наверняка в блокировках. В технологическом журнале ищите события TLOCK и TDEADLOCK: они покажут, какие объекты конфликтуют. Типичные источники — проведение документов, списывающих одни и те же остатки, и обращения к константам или последовательностям.
Для регистров накопления проверьте режим разделения итогов — он включён по умолчанию в современных версиях платформы и существенно снижает конкуренцию при записи. В доработках избегайте чтения остатков перед записью без крайней необходимости (контроль остатков лучше выполнять в транзакции проведения с правильными управляемыми блокировками) и не блокируйте шире, чем требуется логикой задачи.
Взаимоблокировки (deadlock) возникают, когда два процесса захватывают ресурсы в разном порядке. Решение — единый порядок обращения к объектам в коде и сокращение времени транзакций: чем короче транзакция, тем меньше окно для конфликтов.
Как проверить результат оптимизации
Сократилось по сравнению с исходным замером и стабильно в течение дня
Улучшение есть только вне рабочих часов — проблема в конкуренции за ресурсы
Длительные запросы исчезли или их длительность снизилась
Те же запросы выполняются так же долго — изменения не затронули причину
Количество конфликтов снизилось, взаимоблокировки исчезли
Число блокировок выросло после доработок кода
Очередь диска и время отклика в разумных пределах в пиковые часы
Диск загружен на 100% — узкое место осталось в инфраструктуре
Когда оптимизации недостаточно: масштабирование
Если после настройки СУБД, кода и регламентных заданий ресурсы сервера всё равно исчерпаны, проблема решается масштабированием. Вертикальное — увеличение оперативной памяти, переход на более быстрые диски (SSD/NVMe вместо HDD), добавление процессорных ресурсов. Для СУБД объём памяти часто даёт больший эффект, чем процессор: больше данных обслуживается из кэша без обращения к диску.
Горизонтальные варианты: разнесение сервера 1С и СУБД на разные машины, выделение отдельного сервера под фоновые задания и обмены, распределение баз по нескольким серверам СУБД. Для очень крупных внедрений применяют также сокращение объёма данных в оперативной базе — архивацию исторических периодов в отдельные базы для редких обращений.
Что важно запомнить
Оптимизация 1С — это цикл «замер → диагностика → изменение → повторный замер». Начинайте с технологического журнала и счётчиков ресурсов, основной эффект обычно дают настройка СУБД, перенос фоновых заданий, работа с итогами и исправление запросов в доработках. Все рискованные операции выполняйте на копии и в нерабочее время.
Частые вопросы
С чего начать, если база стала медленно работать внезапно?
Внезапная деградация обычно имеет конкретный повод: проверьте, что менялось — обновление конфигурации или платформы, новые регламентные задания, рост объёма данных, изменения в инфраструктуре. Посмотрите свободное место на дисках СУБД и состояние журнала транзакций: переполненный диск — одна из самых частых причин резкой остановки. Технологический журнал за период деградации покажет, какие запросы стали выполняться дольше.
Поможет ли ускорить 1С переход с файлового режима на клиент-серверный?
Для баз с несколькими одновременно работающими пользователями — да, как правило, заметно: СУБД эффективнее обрабатывает параллельные запросы и лучше использует память. Но переход требует лицензий на сервер 1С и СУБД (или использования свободной СУБД), а также навыков администрирования. Для одного-двух пользователей выигрыш может быть незначительным.
Как часто нужно обновлять статистику и перестраивать индексы в СУБД?
Обновление статистики для активно изменяемых баз обычно выполняют ежедневно или несколько раз в неделю, перестроение индексов — реже, по мере накопления фрагментации. Точный график зависит от интенсивности записи: чем больше документов проводится ежедневно, тем чаще требуется обслуживание. Ориентируйтесь на мониторинг фрагментации и время выполнения типовых операций.
Ускорит ли работу увеличение оперативной памяти на компьютере пользователя?
Только если узкое место — сам клиент: тонкий клиент 1С обычно не требует много памяти, и чаще тормоза связаны с сервером, СУБД или сетью. Перед апгрейдом клиентских машин убедитесь через замеры, что проблема именно на клиенте — например, другие пользователи на той же базе работают быстро, а сеть до сервера у проблемного пользователя нестабильна.
Опасно ли самостоятельно менять настройки кластера и СУБД?
Базовые настройки (ограничение памяти СУБД, план обслуживания, расписание заданий) безопасны при соблюдении двух правил: есть актуальная резервная копия и изменения применяются в нерабочее время с последующей проверкой. Глубокие изменения — разбиение базы на файловые группы, перенастройка уровней изоляции, изменение структуры метаданных — лучше сначала отрабатывать на копии или поручать специалисту с опытом администрирования 1С и СУБД.
Почему после обновления конфигурации всё стало работать медленнее?
Частая причина — отложенные обработчики обновления, которые продолжают выполняться в фоне и нагружают базу. Проверьте статус их завершения в разделе обновления версии программы. Если обработчики завершены, а замедление осталось, сделайте замер производительности: в новой версии могли измениться запросы или добавиться проверки, и узкое место нужно искать заново.