Администрирование · 12 мин
Как повысить производительность 1С: пошаговое руководство
Конкретные способы ускорить 1С: диагностика узких мест, настройка СУБД и сервера, оптимизация кода, регламентные задания, типичные ошибки и контроль результата.
Медленная работа 1С редко имеет одну причину. Обычно это комбинация факторов: перегруженный сервер СУБД, неоптимальные запросы в конфигурации, разросшиеся таблицы итогов, устаревшие индексы или неправильно настроенные регламентные задания. Поэтому повышение производительности начинается не с «ускорения всего сразу», а с поиска конкретного узкого места.
Практика показывает, что в файловых базах основные тормоза связаны с дисковой подсистемой и блокировками при одновременной работе пользователей, а в клиент-серверном варианте — с настройками MS SQL Server или PostgreSQL и с запросами, которые генерирует платформа и прикладной код. Подходы к оптимизации в этих двух режимах заметно различаются.
Прежде чем что-либо менять, зафиксируйте текущее состояние: время открытия ключевых документов, скорость проведения, длительность формирования основных отчётов. Без исходных замеров вы не сможете доказать, что оптимизация дала результат, и рискуете потратить время на изменения, которые ничего не улучшат.
Как найти узкое место: диагностика перед оптимизацией
Первый инструмент диагностики — технологический журнал платформы. Он записывает события: длительные запросы к СУБД, блокировки, ошибки, вызовы сервера. Включите его на ограниченное время (час-два в пиковую нагрузку), настроив отбор по длительности событий, чтобы не переполнить диск логами.
Второй источник информации — замер производительности в конфигураторе (Отладка → Замер производительности). Он показывает, какие строки кода и запросы занимают больше всего времени при выполнении конкретной операции. Это особенно полезно, когда тормозит одна конкретная функция: проведение документа, закрытие месяца, формирование отчёта.
Дополнительно оцените аппаратную часть: загрузку процессора, памяти и дисков на сервере СУБД и сервере 1С в момент жалоб пользователей. Если дисковая очередь стабильно высокая — проблема в подсистеме хранения; если процессор загружен на 100% одним ядром — вероятно, есть тяжёлый запрос или нехватка памяти у СУБД.
Загрузку дисков, памяти и процессора на серверах
Замер производительности в конфигураторе
Пинг до сервера, загрузку терминального сервера
Расписание фоновых заданий и обслуживания СУБД
Обслуживание СУБД: статистика, индексы и регламентные операции
Если база работает на MS SQL Server или PostgreSQL, регулярное обслуживание СУБД — самое эффективное и безопасное действие. Устаревшая статистика заставляет оптимизатор запросов выбирать плохие планы выполнения, и один и тот же запрос может выполняться в десятки раз медленнее, чем мог бы.
Минимальный набор регламентных операций: обновление статистики, реорганизация или перестроение индексов при высокой фрагментации, очистка процедурного кэша при подозрении на «плохой» план запроса. В MS SQL это оформляется планом обслуживания или скриптами по расписанию, обычно в ночное время.
Для MS SQL проверьте настройки самой базы: модель восстановления (для рабочих баз часто достаточно простой, если нет требований к точечному восстановлению), размер и прирост файлов данных и журнала, параметр max degree of parallelism и лимит памяти сервера. Установка лимита памяти важна: без него SQL Server может занять всю оперативную память, оставив систему и сервер 1С без ресурсов.
- 1Настройте еженочное обновление статистики по всем таблицам базы
- 2Добавьте еженедельную реорганизацию или перестроение индексов с высокой фрагментацией
- 3Установите лимит памяти для SQL Server, оставив ресурс ОС и серверу 1С
- 4Проверьте модель восстановления и настройте рост файлов базы фиксированными шагами
- 5Через неделю сравните время типовых операций с исходными замерами
Настройка сервера 1С и инфраструктуры
В клиент-серверном варианте проверьте размещение компонентов. Частая ошибка — сервер 1С и СУБД на одной машине с недостаточным объёмом памяти: они конкурируют за ресурсы, и оба работают медленнее. Если разделить их нельзя, обязательно ограничьте память СУБД.
Для кластера серверов 1С важны параметры рабочих процессов: их количество, лимит памяти на процесс и настройки перезапуска. Слишком мало рабочих процессов — пользователи стоят в очереди; слишком много — расходуется память и растут накладные расходы. Точные значения подбираются под конкретную нагрузку, универсальных цифр здесь нет.
В файловом режиме главные факторы — скорость диска и сети, если база лежит на сетевом ресурсе. Размещение файловой базы на медленном сетевом диске при работе десятка пользователей почти гарантированно даёт тормоза и блокировки. При росте числа пользователей правильное решение — переход на клиент-серверный вариант, а не попытки «разогнать» файловый режим.
Оптимизация прикладного кода и запросов
Наиболее частые причины медленного кода в 1С: запросы в цикле, обращения к данным через точку («разворачивание» реквизитов), отсутствие отборов при выборке больших таблиц, получение всей таблицы вместо нужных полей. Замер производительности быстро показывает такие места.
Типовые исправления: вынести запрос из цикла и передать в него таблицу значений через временную таблицу; заменить обращения через точку на соединения в запросе; добавить индексы по полям отборов и соединений, если таблицы большие; использовать виртуальные таблицы регистров с параметрами вместо чтения всей таблицы движений.
Отдельно проверьте отчёты на СКД: часто тормозит не сам запрос, а постобработка — ресурсы, вычисляемые поля, иерархия. Упростите настройки по умолчанию, уберите лишние группировки и проверьте, не выполняется ли запрос дважды из-за настроек компоновки.
Регламентные задания и фоновые процессы
Регламентные и фоновые задания — частый скрытый источник тормозов. Задания, которые запускаются каждую минуту или работают в часы пиковой нагрузки, конкурируют с пользователями за ресурсы сервера и создают блокировки.
Проверьте список активных регламентных заданий: отключите неиспользуемые, перенесите тяжёлые на ночное время, увеличьте интервалы для некритичных задач. Обратите внимание на задания, которые завершаются с ошибками и перезапускаются — они могут работать непрерывно и грузить сервер.
Если задание обрабатывает большие объёмы (например, обмен данными или загрузка цен), разбейте обработку на порции и добавьте контроль длительности, чтобы задание не выполнялось часами в рабочее время.
Сокращение объёма данных и обновление платформы
Большие базы работают медленнее по определению: растут таблицы, индексы, время выполнения запросов. Если база ведётся много лет, рассмотрите свёртку итогов на начало периода и перенос старых данных в архивную базу. Это штатная операция, но её нужно выполнять аккуратно, с проверкой корректности остатков.
Проверьте также вспомогательные механизмы: журналы регистрации без ограничения глубины хранения могут разрастаться до значительных размеров; включённая полная версионность объектов на всех справочниках и документах увеличивает объём записываемых данных. Ограничьте срок хранения и перечень версионируемых объектов до реально необходимого.
Наконец, следите за версией платформы: в новых релизах регулярно исправляются проблемы производительности самого движка. Обновление платформы — не панацея, но держать её на актуальном релизе, совместимом с вашей конфигурацией, разумно. Обновляйте сначала на тестовой копии.
Как выбрать действие
Как проверить, что оптимизация сработала
После каждого изменения повторяйте те же замеры, что делали в начале: время проведения типового документа, формирование ключевого отчёта, открытие списков. Сравнивайте результаты в сопоставимых условиях — в то же время суток и при похожей нагрузке.
Не вносите несколько изменений одновременно, если хотите понять, что именно помогло. Меняйте по одному параметру, замеряйте, фиксируйте. Это дольше, но даёт управляемый результат и позволяет откатить неудачное изменение.
Как проверить результат
Сократилось по сравнению с исходным замером и стабильно при повторных попытках
Результат плавает или не изменился — узкое место не устранено
Очередь диска низкая, нет длительных ожиданий
Очередь растёт — проблема в подсистеме хранения
Длительных запросов и взаимоблокировок стало заметно меньше
Появились новые длительные события — изменение ухудшило ситуацию
Субъективно работа стала быстрее в тех операциях, что замерялись
Пользователи не замечают разницы — уточните, какие операции их тормозят
Что важно запомнить
Оптимизация 1С — это цикл: замер, поиск узкого места, одно изменение, повторный замер. Начинайте с обслуживания СУБД и регламентных заданий, затем переходите к коду и инфраструктуре. Все рискованные операции выполняйте на копии и с резервной копией.
Частые вопросы
Сколько оперативной памяти нужно серверу 1С?
Универсальной цифры нет: объём зависит от числа пользователей, размера базы и нагрузки. Практический признак нехватки — активное использование файла подкачки и рост дисковой активности при пиковой нагрузке. Начните с мониторинга текущего потребления памяти рабочими процессами кластера и СУБД, затем добавляйте память с запасом на рост.
Поможет ли переход на SSD, если база и так на сервере?
Если база размещена на обычных HDD, переход на SSD обычно даёт заметное ускорение, особенно для файловых баз и при интенсивной записи. Но если узкое место — неоптимальные запросы или нехватка памяти, быстрый диск проблему не решит. Сначала проверьте дисковую очередь в момент тормозов.
Что делать, если тормозит только один отчёт?
Сделайте замер производительности при его формировании. Чаще всего причина в запросе без отборов, соединениях через точку или тяжёлых настройках СКД. Оптимизируйте запрос, добавьте параметры периода и отборы, упростите структуру отчёта — в большинстве случаев этого достаточно.
Можно ли ускорить файловую базу без перехода на клиент-серверный режим?
Частично: разместите базу на быстром локальном диске, ограничьте число одновременных пользователей, отключите лишние регламентные задания и антивирусную проверку каталога базы. Но при росте числа пользователей файловый режим упирается в блокировки, и переход на клиент-серверный вариант становится единственным устойчивым решением.
Как часто нужно обновлять статистику и индексы в СУБД?
Типовая практика для активно работающих баз — обновление статистики ежедневно в нерабочее время, реорганизация или перестроение индексов — еженедельно или по факту роста фрагментации. Точную периодичность подбирайте по динамике: если тормоза возвращаются через пару дней после обслуживания, интервал стоит сократить.
Опасно ли чистить процедурный кэш MS SQL Server?
Сама операция безопасна, но после очистки первые выполнения запросов будут медленнее, пока строятся новые планы. Выполняйте очистку в нерабочее время и только при подозрении на некорректный план запроса — как регулярную процедуру её применять не нужно.