Как ускорить 1С: практический план без опасных «чисток»
Ускорить работу базы 1С обычно можно тремя действиями: привести в порядок индексы и статистику на СУБД, перенести и разнести регламентные задания, ограничить рост журнала регистрации и служебных накоплений. Начните с замеров, затем меняйте по одному фактору и проверяйте эффект.
Перед обслуживанием и очисткой сделайте резервную копию и проверьте, что она восстанавливается. Любые «чистки» планируйте в технологическое окно.
Оглавление
Быстрая диагностика: что именно тормозит
- Определите 5–7 сценариев: проведение документа, открытие списка, типовой отчет, закрытие месяца, обмен.
- Снимите время “как есть”: кто выполнял, когда (пик/не пик), сколько секунд заняло.
- Разделите проблему по типу базы:
- Файловая база: чаще упирается в сеть/диск, размер файла, антивирус, одновременный доступ.
- Клиент-сервер: чаще упирается в СУБД (индексы/статистика/блокировки) и фоновые задания.
- Проверьте фон: не стартуют ли одновременно обмены, пересчеты, закрытие периода, массовые обработки.
Самый быстрый путь к результату — цикл: замер → изменение одного параметра → повторный замер. Так вы точно поймете причину ускорения.
Индексы и статистика: обслуживание MS SQL и PostgreSQL
Для клиент-серверной 1С это базовая профилактика: когда статистика устарела, а индексы фрагментированы, СУБД выбирает тяжелые планы запросов, и «тормозит всё» — от списков до отчетов.
MS SQL Server: практическое правило
- Фрагментация 5–30% → REORGANIZE (мягко, обычно быстрее и легче по ресурсам).
- Фрагментация >30% → REBUILD (сильнее нагрузка на диск и журнал транзакций).
- После крупных загрузок/обменов/закрытия периода → обновить статистику (иначе планы запросов могут стать хуже, чем до индексов).
REBUILD способен резко увеличить нагрузку и раздувать журнал транзакций. Следите за свободным местом, делайте обслуживание ночью и не запускайте «всё и сразу» на всех таблицах.
PostgreSQL: на что реально влияет производительность
- Убедитесь, что autovacuum успевает (иначе растет “раздувание” таблиц и индексов).
- Регулярно выполняйте VACUUM (ANALYZE) по нужным базам/таблицам, чтобы статистика оставалась актуальной.
- REINDEX используйте точечно (после сбоев или когда есть явные признаки проблем с индексами), а не «по расписанию на всякий случай».
Регламентные задания и очистка: как снять пики нагрузки
Пользователи часто видят «тормоза» не из‑за индексов, а из‑за того, что в рабочее время параллельно выполняются тяжелые регламентные задания, создают длинные транзакции и блокировки.
Регламентные задания: настройка без отключения “всего подряд”
Проверьте по каждому заданию:
- расписание (не попадает ли на начало дня/обед/массовые операции);
- длительность (если было 2 минуты, стало 40 — это сигнал);
- ошибки и повторы (зацикливание = постоянная нагрузка);
- параллельные старты (несколько тяжелых задач в одну минуту).
Что обычно дает быстрый эффект:
- сдвинуть старты тяжелых задач на 3–10 минут, чтобы убрать пики;
- вынести обмены, синхронизации, массовые перерасчеты в ночное окно;
- разобраться с «вечными» заданиями (чаще причина — блокировки, внешний сервис, рост данных, некорректные настройки).
Безопасная “очистка”, которая реально ускоряет
- Журнал регистрации: задайте политику хранения (срок/объем), а не разовую ручную чистку. Оставляйте подробный уровень только на период расследований.
- Очереди и протоколы обмена: при ошибках интеграций они разрастаются и начинают замедлять операции — чистите по регламенту, после исправления причины ошибок.
- Версии/истории/накопления служебных подсистем (если включены): ограничьте срок хранения, иначе база будет расти без остановки.
Не путайте ускорение с «удалением документов». Удаление учетных данных — отдельный проект (архивирование, регламент, согласование), иначе можно повредить учет и отчетность.
Мини‑регламент обслуживания (пример)
| Периодичность | Что делать | Где |
|---|---|---|
| Ежедневно ночью | обновление статистики + легкое обслуживание индексов | СУБД |
| Еженедельно | тяжелое обслуживание индексов по высоким порогам + проверка места/логов | СУБД |
| Ежедневно | контроль зависших фоновых задач, разнос расписаний | 1С |
| Ежемесячно | политика хранения журнала регистрации и служебных очередей/историй | 1С |
Частые ошибки
- Обслужили индексы, но оставили тяжелые регламентные задания в прайм‑тайм — пользователи не почувствуют улучшения.
- Делают «чистку всего» без понимания, что можно удалять — теряют аудит/историю и получают новые инциденты.
- Запускают REBUILD без контроля места — получают переполнение диска/журнала и простой.
- Не фиксируют замеры “до/после” — невозможно доказать эффект и понять, что помогло.
FAQ
Нужно ли обслуживать индексы в файловой базе 1С?
Нет, там нет отдельной СУБД с индексным обслуживанием. Для файловой базы важнее диск/сеть, размер базы, антивирус, количество одновременных пользователей и переход на клиент-сервер при росте.
Что сначала: индексы или регламентные задания?
Если тормозит “волнами” в определенные часы — начните с регламентных заданий. Если деградация постоянная и растет месяцами — параллельно настраивайте обслуживание индексов/статистики.
Можно ли “просто почистить журнал регистрации”, чтобы стало быстрее?
Иногда помогает косвенно (объем, администрирование), но чаще ключевой эффект дают расписания фоновых задач и корректная статистика/индексы. Журнал лучше не «чистить вручную», а ограничить хранение.
Как понять, что проблема в блокировках?
Признаки: у одних пользователей операции “висят”, у других в этот момент тоже замедляется работа; зависания совпадают по времени с обменами/массовыми заданиями. Тогда ищите конфликтующие задания и пересечения по данным.