Как увеличить быстродействие 1С: пошаговая инструкция

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

Условно все причины делятся на четыре уровня: инфраструктура (серверы, сеть, диски), СУБД (MS SQL, PostgreSQL), платформа 1С (настройки кластера, регламентные задания) и прикладной код конфигурации. Работать с ними следует именно в таком порядке — от общего к частному. Часто настройка одного параметра СУБД даёт больший эффект, чем месяцы оптимизации кода.

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

Шаг 1. Найдите, что именно тормозит

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

Для замеров используйте встроенные инструменты. Замер производительности (Конфигуратор → Отладка → Замер производительности) покажет, какие строки кода занимают больше всего времени. Технологический журнал кластера 1С фиксирует длительные запросы и блокировки. На стороне MS SQL полезны динамические административные представления: sys.dm_exec_query_stats для самых тяжёлых запросов и sys.dm_os_wait_stats для анализа ожиданий сервера.

Шаг 2. Настройте сервер и СУБД

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

Проверьте модель восстановления базы. Полная модель (Full) без регулярного резервного копирования журнала транзакций приводит к разрастанию файла журнала до десятков гигабайт и замедлению. Если не требуется восстановление на произвольный момент времени, используйте простую модель (Simple); если требуется — настройте регулярный бэкап журнала. Также убедитесь, что автоувеличение файлов базы задано фиксированным размером в мегабайтах, а не в процентах.

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

Шаг 3. Оптимизируйте кластер 1С и регламентные задания

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

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

1. 1
   Откройте консоль заданий или раздел администрирования с регламентными заданиями
2. 2
   Составьте список активных заданий и выясните, какие из них реально нужны
3. 3
   Отключите неиспользуемые задания и зафиксируйте изменения
4. 4
   Разнесите оставшиеся задания по расписанию в нерабочие часы
5. 5
   Через неделю проверьте журнал регистрации: нет ли ошибок и пропущенных запусков

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

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

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

Шаг 5. Устраните блокировки и конфликты

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

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

Для анализа включите в технологическом журнале сбор событий TLOCK и TDEADLOCK — они покажут, какие объекты конфликтуют. Взаимоблокировки (deadlock) почти всегда требуют исправления кода: порядок обращения к данным в разных процедурах должен быть одинаковым.

Маршрут решения

Как выбрать действие

Ошибки «Конфликт блокировок» при параллельной работеПереведите конфигурацию на управляемые блокировки и проанализируйте TLOCK в техножурнале

Медленное проведение документов при росте числа пользователейПроверьте списание остатков по общим измерениям и настройки нумерации

Взаимоблокировки в журнале СУБДПриведите порядок обращения к таблицам в коде к единому во всех процедурах

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

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

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

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

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

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

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

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

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

Время типовых операций до и после

Норма

Сокращение времени проведения и отчётов при том же объёме данных

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

Время не изменилось или выросло — причина не устранена

Ожидания и блокировки в СУБД

Норма

Длительные ожидания блокировок отсутствуют или минимальны

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

Растут ожидания LCK_*, ошибки конфликтов в журнале

Размер базы и журнала транзакций

Норма

Стабильный контролируемый рост

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

Журнал разросся на десятки гигабайт, модель восстановления не настроена

Журнал регистрации регламентных заданий

Норма

Задания выполняются по расписанию без ошибок

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

Ошибки, пропуски запусков, наложение заданий друг на друга

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

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

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

Поможет ли просто добавить оперативную память на сервер?

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

Как понять, что проблема в сети, а не в сервере?

Сравните скорость одной и той же операции на самом сервере (через RDP или локально) и на рабочем месте пользователя. Если на сервере быстро, а у пользователя медленно — проверяйте канал: задержки, потери пакетов, скорость. Для удалённых подразделений часто помогает переход на тонкий клиент или веб-клиент вместо толстого.

Опасно ли отключать регламентные задания?

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

Как часто нужно обслуживать базу 1С?

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

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

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