Администрирование · 12 мин
Как повысить скорость работы 1С
Конкретные способы ускорить 1С: настройка сервера и СУБД, оптимизация запросов, регламентные задания, оборудование. Пошаговые инструкции и проверка результата.
Медленная работа 1С редко имеет единственную причину. Чаще всего тормоза складываются из перегруженного сервера, неоптимальных запросов в конфигурации, разросшихся таблиц базы данных и неправильно настроенных регламентных заданий. Прежде чем что-то менять, нужно понять, где именно теряется время: на клиентском компьютере, на сервере 1С, на сервере СУБД или в сети между ними.
Диагностику удобно начинать с простого разделения: если программа тормозит у всех пользователей одновременно — проблема почти наверняка на сервере или в базе. Если медленно работает только один компьютер — смотрите клиентскую часть: антивирус, диск, сетевое подключение, версию платформы. Если тормозит одна конкретная операция (проведение документа, формирование отчёта) — вероятнее всего, дело в запросах и индексах.
Ниже разобраны практические меры по порядку: от диагностики и быстрых побед до глубокой оптимизации запросов и железа. Большинство действий доступны администратору без привлечения разработчика, но некоторые требуют изменения конфигурации и обязательного тестирования на копии базы.
Диагностика: как найти реальное узкое место
Оптимизация вслепую почти всегда даёт нулевой результат. Первый инструмент — встроенный замер производительности в конфигураторе (Отладка → Замер производительности). Он показывает, сколько времени заняла каждая строка кода и каждый запрос при выполнении проблемной операции. Если 80% времени уходит на один запрос — вы нашли цель.
Для клиент-серверного режима дополнительно смотрите загрузку сервера СУБД: в MS SQL Server это Activity Monitor и динамические административные представления (sys.dm_exec_query_stats), в PostgreSQL — pg_stat_statements. Эти инструменты показывают самые тяжёлые запросы за период, а не только в момент замера.
Полезно зафиксировать базовые показатели до начала работ: время открытия программы, проведения типового документа, формирования ключевого отчёта. Без «до» и «после» невозможно понять, дала ли конкретная мера эффект.
Загрузку CPU, RAM и дисков сервера СУБД; тяжёлые запросы
Антивирус, состояние диска, сеть, версию платформы
Замер производительности, план запроса, наличие индексов
Расписание регламентных заданий, бэкапов, обменов
Быстрые меры на стороне клиента и файловой базы
Если база файловая и лежит на сетевом диске — это само по себе главный источник тормозов. Файловый режим по сети критичен к задержкам, и даже быстрый сервер не спасает. Оптимальные варианты: работа через терминальный сервер (RDP), где база и клиент на одной машине, публикация через веб-сервер или переход на клиент-серверный режим при росте числа пользователей выше 5–10.
Добавьте каталоги 1С и файлы базы в исключения антивируса: проверка на лету каждого обращения к файлам заметно замедляет работу. То же касается сервера СУБД — каталоги данных и журналов транзакций должны быть исключены из сканирования, иначе антивирус будет тормозить каждую операцию записи.
Проверьте, что клиентские машины и сервер используют актуальную версию платформы, рекомендованную для вашей конфигурации: в новых релизах регулярно исправляются проблемы производительности. На клиенте отдавайте предпочтение тонкому клиенту вместо толстого — он переносит больше работы на сервер и меньше зависит от мощности рабочего места.
Настройка сервера 1С и СУБД
В клиент-серверном варианте значительную часть прироста даёт правильная настройка СУБД. Для MS SQL Server проверьте: режим восстановления базы (модель Simple подходит, если не нужно восстановление на произвольный момент времени), размер и авторасширение журнала транзакций, регулярное обновление статистики и перестроение индексов. Устаревшая статистика — частая причина того, что оптимизатор выбирает плохой план запроса.
Для PostgreSQL критичны параметры shared_buffers, work_mem и регулярный autovacuum. Значения по умолчанию рассчитаны на минимальное железо и почти всегда требуют увеличения под нагрузку 1С. Точные значения зависят от объёма оперативной памяти сервера и размера активной части базы — подбирайте их постепенно, контролируя потребление памяти.
На кластере серверов 1С обратите внимание на количество рабочих процессов и их лимиты памяти. Один рабочий процесс на сервер — не всегда оптимально: при большом числе пользователей имеет смысл несколько процессов с ограничением объёма памяти и автоматическим перезапуском, чтобы утечки в одном процессе не останавливали работу всех.
Оптимизация запросов и кода конфигурации
Тяжёлые запросы — самая частая причина медленных отчётов и проведений. Типичные проблемы: соединение с виртуальными таблицами без отбора, использование вложенных запросов там, где достаточно соединения, выборка всех полей вместо нужных, отсутствие индекса по полям отбора. Каждая из них устраняется переписыванием запроса, а не железом.
При работе с виртуальными таблицами регистров (Остатки, Обороты, СрезПоследних) всегда передавайте параметры отбора — период и измерения. Запрос «СрезПоследних» без условий заставляет СУБД обработать всю таблицу регистра. Также избегайте запросов в цикле: соберите данные одним запросом с пакетом или временной таблицей.
Для поиска проблем используйте план запроса. В MS SQL это выполняется через SQL Server Management Studio (Include Actual Execution Plan), в PostgreSQL — команду EXPLAIN ANALYZE. Признаки плохого плана: сканирование всей таблицы (Seq Scan, Clustered Index Scan) там, где ожидается поиск по индексу, большие расхождения ожидаемого и фактического числа строк.
- 1Сделайте замер производительности операции в конфигураторе и найдите самый дорогой запрос
- 2Получите план запроса в средствах СУБД и найдите сканирования больших таблиц
- 3Добавьте отборы в параметры виртуальных таблиц и проверьте индексы по полям условий
- 4Перепишите запрос, убрав вложенные запросы, соединения по вычисляемым полям и лишние поля
- 5Повторите замер на тестовой базе и сравните время до и после
- 6Только после успешного теста переносите изменения в рабочую базу
Регламентные задания, итоги и обслуживание базы
Регламентные задания (обмены, расчёты, загрузка курсов, синхронизации) нередко запускаются в рабочее время и конкурируют с пользователями за ресурсы. Перенесите тяжёлые задания на ночные часы, отключите неиспользуемые, а частые лёгкие задания проверьте на предмет ошибок: задание, падающее с ошибкой каждые несколько минут, создаёт постоянную лишнюю нагрузку и засоряет журнал регистрации.
Следите за управлением итогами регистров накопления и бухгалтерии. Если итоги не рассчитываются по текущий период, запросы к виртуальным таблицам остатков и оборотов резко замедляются. Проверьте режим разделения итогов — для большинства современных конфигураций он должен быть включён, так как ускоряет проведение документов в многопользовательском режиме.
Регулярное обслуживание включает: обновление статистики и реиндексацию на уровне СУБД, тестирование и исправление информационной базы (в выходные, при отсутствии пользователей), очистку устаревших данных — помеченных объектов, версий объектов, журналов обменов, если механизм версионирования включён. Запустите штатную обработку «Удаление помеченных объектов» в монопольном режиме.
Когда проблема в железе и как проверить результат
Апгрейд оборудования оправдан, когда программные меры исчерпаны, а мониторинг показывает устойчивую утилизацию ресурса выше 80–90%. Приоритеты для сервера 1С и СУБД: быстрые диски (SSD/NVMe вместо HDD даёт самый заметный эффект для баз данных), достаточный объём оперативной памяти (рабочий набор базы желательно помещать в кэш), затем процессор с высокой тактовой частотой — многие операции 1С однопоточны.
Для файловых баз с ростом пользователей железо не решает проблему — здесь правильный ответ: переход на клиент-серверную архитектуру или терминальный режим. Попытка «ускорить» сетевую файловую базу покупкой дисков обычно заканчивается разочарованием.
После каждого изменения повторяйте контрольные замеры в тех же условиях: то же время суток, тот же документ, тот же отчёт. Фиксируйте результаты — это позволит откатить меры, которые не дали эффекта, и не тратить время на повторные эксперименты.
Как проверить результат
Сократилось по сравнению с замером до оптимизации
Без изменений или выросло — мера не сработала, откатите
Очередь диска небольшая, утилизация ниже 80%
Диск постоянно загружен на 100% — узкое место в подсистеме хранения
Используются поиски по индексам (Index Seek, Index Scan)
Полное сканирование больших таблиц осталось
Скорость стабильна в течение дня
Провалы в конкретные часы — ищите конфликтующие задания
Как выбрать действие
Частые вопросы
Ускорит ли работу 1С переход на SSD?
Да, если узкое место — дисковая подсистема, что характерно для баз данных. Замена HDD на SSD/NVMe на сервере СУБД обычно даёт самый заметный прирост из всех аппаратных мер. Но если проблема в неоптимальном запросе со сканированием таблицы, SSD лишь немного сгладит симптомы — запрос всё равно нужно переписывать.
Сколько оперативной памяти нужно серверу 1С?
Универсальной цифры нет: ориентир — чтобы активная часть базы и рабочие процессы помещались в память без постоянного обращения к диску. На практике смотрите показатели кэша СУБД и подкачки: если система активно использует файл подкачки, памяти не хватает. Начинайте с оценки размера базы и числа одновременных пользователей.
Можно ли ускорить файловую базу без перехода на клиент-сервер?
Частично: работа через терминальный сервер (база и клиенты на одной машине), исключения в антивирусе, быстрый локальный диск и уменьшение числа одновременных пользователей дают заметный эффект. Но принципиальное ограничение файлового режима — блокировки всей таблицы при записи — снимается только переходом на клиент-серверную архитектуру.
Что делать, если тормозит только формирование отчётов?
Это почти всегда проблема запросов. Сделайте замер производительности при формировании отчёта, найдите самый тяжёлый запрос, проверьте отборы в виртуальных таблицах и индексы. Также проверьте, рассчитаны ли итоги регистров по текущий период — нерассчитанные итоги сильно замедляют отчёты по остаткам и оборотам.
Опасно ли самостоятельно менять настройки СУБД?
Базовые операции обслуживания (обновление статистики, реиндексация) безопасны при соблюдении регламента и выполнении в нерабочее время. Изменение параметров памяти и параллелизма требует осторожности: неверные значения могут ухудшить работу. Меняйте параметры по одному, фиксируйте старые значения и проверяйте результат замерами.
Как понять, что пора привлекать специалиста по оптимизации?
Если замеры показывают проблемы в коде типовой конфигурации, нужна реструктуризация регистров или оптимизация не дала эффекта после устранения очевидных причин — задача выходит за рамки администрирования. Также специалист нужен, когда требуется изменять конфигурацию, снятую с полной поддержки: ошибки там дороже, чем стоимость работы.
Что важно запомнить
Ускорение 1С начинается с замера, а не с покупки железа. Найдите узкое место, устраните его наименее рискованным способом, проверьте результат повторным замером. Регулярное обслуживание СУБД и разумное расписание регламентных заданий предотвращают большинство проблем до их появления.