Как ускорить программу 1С: пошаговое руководство

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

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

Важно различать файловый и клиент-серверный режимы работы. Часть приёмов актуальна только для SQL-варианта, часть — универсальна. Ниже разобраны оба сценария с указанием, где какой метод применим.

Шаг 1. Найдите узкое место, а не гадайте

Главная ошибка при ускорении 1С — менять настройки вслепую. Сначала определите, что именно тормозит: процессор, дисковая подсистема, оперативная память, сеть или конкретные запросы. Для этого используйте встроенные инструменты платформы.

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

Для клиент-серверного варианта включите технологический журнал с фильтром по длительным событиям DBMSSQL/DBPOSTGRS и блокировкам TLOCK. Это даст точную картину: какие SQL-запросы выполняются дольше нормы и где возникают взаимоблокировки. Параллельно смотрите системные мониторы: загрузку диска (очередь диска), потребление памяти процессами rphost и СУБД, загрузку сети.

Шаг 2. Оптимизируйте аппаратную часть и размещение базы

Самый частый физический bottleneck — дисковая подсистема. База 1С на обычном HDD почти всегда работает медленнее, чем на SSD, особенно при активной записи (проведение документов, обмены данными). Перенос базы на SSD-накопитель часто даёт самый заметный прирост при минимальных затратах.

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

Для файлового режима критична сеть: размещение базы на сетевом диске с медленным каналом или Wi-Fi гарантированно даёт задержки. Файловую базу лучше держать на сервере с быстрым диском и гигабитной сетью, а при росте числа пользователей (ориентировочно от 5–10 активных) планировать переход на клиент-серверный вариант.

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

В клиент-серверном варианте значительная часть производительности определяется настройками СУБД. Для MS SQL Server проверьте: модель восстановления базы (для большинства баз достаточно простой вместо полной), размер и настройки tempdb, параметры автоматического обновления статистики. Устаревшая статистика — классическая причина внезапного замедления отчётов: оптимизатор строит неверный план запроса.

Регулярно выполняйте обслуживание индексов и статистики средствами СУБД (планы обслуживания или скрипты). Фрагментированные индексы на больших таблицах регистров заметно увеличивают время чтения. Для PostgreSQL аналогично важны autovacuum и корректные параметры shared_buffers и work_mem.

На стороне сервера 1С проверьте кластер: количество рабочих процессов, лимиты памяти на процесс, интервалы перезапуска. Утечки памяти в rphost лечатся настроенным автоматическим перезапуском рабочих процессов по расписанию или по превышению порога памяти.

1. 1
   Сделайте резервную копию базы и зафиксируйте текущие замеры производительности
2. 2
   Настройте исключения антивируса для каталогов СУБД и сервера 1С
3. 3
   Проверьте модель восстановления базы и настройки tempdb (MS SQL)
4. 4
   Настройте регламентное обновление статистики и обслуживание индексов
5. 5
   Настройте перезапуск рабочих процессов кластера по памяти или расписанию
6. 6
   Повторите замеры и сравните с исходными

Шаг 4. Уменьшите объём данных и наведите порядок в базе

Большие базы работают медленнее по объективным причинам: дольше выполняются запросы, длиннее индексы, тяжелее резервные копии. Периодически выполняйте свёртку базы (перенос итогов на дату с удалением старых документов) или выгрузку архивных периодов в отдельную базу-копию.

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

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

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

Если замеры показали, что тормозит конкретный код, работа идёт на уровне конфигурации. Типовые источники проблем: запросы в цикле, обращения к базе внутри обхода табличной части, отсутствие индексов по полям отборов, получение всей таблицы вместо выборки с условием, использование «ВЫБРАТЬ *» вместо нужных полей.

Проверьте индексы: поля, по которым часто идут отборы в динамических списках и запросах, должны входить в индексы (свойство «Индексировать» у реквизита или составной индекс). Избыточная индексация тоже вредна — она замедляет запись, поэтому добавляйте индексы осознанно, под реальные запросы.

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

Шаг 6. Организуйте регламентные операции и режим работы

Регламентные и фоновые задания (обмены, расчёт итогов, полнотекстовое индексирование, обновление статистики) должны выполняться в нерабочие часы. Если обмен с сайтом или расчёт себестоимости запускается днём каждые 15 минут, пользователи закономерно жалуются на «подвисания».

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

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

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

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

Время проведения типового документа

Норма

Сократилось относительно исходного замера

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

Не изменилось или выросло — узкое место не найдено

Очередь диска на сервере

Норма

Низкая при рабочей нагрузке

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

Постоянно высокая — проблема в дисках или памяти

Технологический журнал

Норма

Нет длительных запросов и частых взаимоблокировок

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

Длительные события сохраняются — нужна работа с запросами

Жалобы пользователей в часы пик

Норма

Равномерная работа в течение дня

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

Провалы в определённое время — смотрите расписание заданий

Когда самостоятельной оптимизации недостаточно

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

Также к специалисту стоит идти при подозрении на повреждение базы: ошибки СУБД, внезапные падения сервера 1С, расхождение итогов. Здесь цена ошибки — потеря данных, и эксперименты недопустимы.

Частые вопросы об ускорении 1С

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

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

Что быстрее: файловый режим или клиент-серверный?

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

Как понять, что тормозит конкретный запрос, а не сервер?

Используйте «Замер производительности» в конфигураторе: он покажет долю времени каждой строки кода и каждого запроса. Если большая часть времени уходит на один запрос — проблема в нём или в отсутствии подходящего индекса. Дополнительно технологический журнал покажет длительность запроса на стороне СУБД.

Опасно ли делать свёртку базы самостоятельно?

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

Почему 1С тормозит только в определённое время дня?

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

Нужно ли обновлять платформу для ускорения?

Само по себе обновление не ускоряет, но в новых релизах платформы исправляют ошибки менеджера блокировок, оптимизатора запросов и механизмов кэширования. Если вы на старой версии, обновление может устранить известную проблему. Обновляйтесь на тестовой копии и проверяйте работу расширений и доработок.