Почему 1С тормозит и что ускорит её на самом деле: от замера до железа
Содержание
Увеличить скорость 1С быстрее всего удаётся там, где найдено конкретное узкое место: медленный диск, нехватка памяти у СУБД, запрос в цикле или файловая база на сетевой папке. Дешёвые методы ускорения — исключения антивируса, очистка кэша, обновление статистики СУБД — дают эффект за час. Дорогие — переход на клиент-сервер, новое железо, переписывание кода — оправданы, только когда замер показал, что проблема именно там.
Ниже порядок, в котором работает практик: сначала измерить, потом чинить самое узкое место, потом следующее. Покупка сервера «на всякий случай» часто не помогает: если тормозит одна блокировка, восемь новых ядер её не уберут.
| Метод | Когда помогает | Цена и риск |
|---|---|---|
| Исключения антивируса, план питания | Файловая база, тормозит всё подряд | Бесплатно, риска нет |
| Очистка кэша клиента | Медленный запуск, странные зависания форм | Бесплатно, нужно закрыть 1С |
| Обслуживание СУБД (индексы, статистика) | Отчёты и проведение замедлялись постепенно | Бесплатно, нагрузка на сервер во время работ |
| Настройка памяти MS SQL / PostgreSQL | Сервер упирается в диск, хотя памяти много | Бесплатно, нужен перезапуск службы |
| Переход с файлового варианта на клиент-сервер | От 5–10 активных пользователей, частые блокировки | Лицензия сервера, работа администратора |
| Оптимизация запросов и кода | Медленная одна операция при нормальном железе | Время программиста |
| Замена дисков на NVMe, рост частоты CPU | Замер показал очередь к диску или загрузку ядра | Деньги, простой на переезд |
Сначала замер: как найти, где 1С теряет скорость
Жалоба «1С тормозит» ничего не говорит. Нужно ответить на три вопроса: что именно медленно, у кого и с какого момента.
📌 Соберите факты до любых настроек:
- 🐢 Какая операция. Запуск, открытие списка, проведение документа, конкретный отчёт, закрытие месяца .
- 👥 У кого. У всех сразу или у одного пользователя. Если у одного — смотрите его компьютер, сеть и кэш, а не сервер.
- 🕐 Когда. Всегда, по утрам, в конце месяца, после обновления. Внезапное замедление обычно связано с изменением: релиз, новые данные, обновление Windows или антивируса.
- 🔒 Ждёт или считает. Если операция висит, а процессор и диск почти не загружены, причина часто в блокировке: другой пользователь держит те же данные.
Инструменты замера
- Оценка производительности в типовой конфигурации. В БП 3.0, ЗУП 3.1 и УТ 11 включается в
Администрирование → Обслуживание → Оценка производительности. Подсистема копит время ключевых операций и считает показатель APDEX. Удобно, чтобы сравнить «до» и «после». - Замер в конфигураторе. Запустите отладку, включите
Отладка → Замер производительности, выполните медленную операцию. Отчёт покажет строки кода и запросы, где ушло больше всего времени. - Технологический журнал. Настраивается файлом
logcfg.xmlв каталогеconfплатформы. Пишет длинные запросы, ожидания на блокировках, исключения. Включайте только нужные события: полный журнал быстро съедает диск. - Монитор ресурсов Windows (
resmon) и счётчики производительности (perfmon). Смотрите загрузку каждого ядра, длину очереди диска и свободную память на сервере 1С и сервере СУБД. - Тест Гилёва. Внешняя бесплатная обработка, которая даёт условный балл однопоточной производительности связки «платформа — СУБД — железо». Полезна, чтобы сравнить два сервера или проверить эффект настройки.
Файловая база или клиент-сервер: когда пора переезжать
Файловый вариант хранит всё в одном файле 1Cv8.1CD. Он хорош для одного-пяти пользователей на одном компьютере или в небольшой сети. С ростом числа активных пользователей начинаются взаимные ожидания: файловая база блокирует данные грубее, чем СУБД.
⚡ Как ускорить файловую базу без переезда:
- 🛡️ Исключите из проверки антивирусом каталог базы и каталог кэша
%APPDATA%\1C\1cv8. Сканирование каждого обращения к1Cv8.1CD— одна из самых частых причин тормозов. - 💾 Держите базу на SSD и на том компьютере, где работает большинство пользователей. Доступ к файлу через сетевую папку по SMB медленнее локального в разы.
- 🖥️ Удалённых пользователей подключайте через RDP (терминальный сервер ) или веб-публикацию, а не открывайте файл по VPN. Через медленный канал толстый клиент к файловой базе работает плохо.
- 🔋 План электропитания Windows — «Высокая производительность». В режиме энергосбережения процессор сбрасывает частоту, а 1С чувствительна именно к частоте.
Переходить на клиент-серверный вариант (сервер 1С + MS SQL или PostgreSQL) стоит, когда работают 5–10 человек одновременно и больше, база выросла до десятков гигабайт, а пользователи регулярно ждут друг друга при проведении.
Перенос делается выгрузкой в .dt из конфигуратора и загрузкой в новую серверную базу. Конфигурация и данные переезжают целиком, менять ничего не нужно.
Как ускорить СУБД: настройки MS SQL и PostgreSQL
В клиент-серверном варианте большая часть времени тратится в СУБД. Неправильные умолчания тут стоят дорого.
MS SQL Server
- Ограничьте память. В свойствах сервера задайте
Maximum server memory. Без ограничения SQL Server забирает почти всю память, и если на той же машине работает сервер 1С, они начинают драться. Ориентир: оставить операционной системе 4–8 ГБ и учесть память рабочих процессов 1С. - Параллелизм. Для баз 1С обычно ставят
Max Degree of Parallelism = 1. Параллельные планы на коротких запросах 1С чаще мешают, чем помогают. - tempdb — на быстрый диск. 1С активно пишет временные таблицы. Разнесите tempdb на отдельный SSD или NVMe, создайте несколько файлов данных одинакового размера.
- Модель восстановления. Если не нужен откат на произвольный момент времени, модель
Simpleизбавляет от разрастающегося журнала транзакций. Если нужна полная модель — настройте резервное копирование журнала, иначе файл.ldfвырастет до размера диска. - Автоприращение файлов задавайте в мегабайтах (например, 512 МБ), а не в процентах: мелкие частые приращения тормозят запись.
PostgreSQL
Используйте сборку PostgreSQL с патчами для 1С (дистрибутив от фирмы 1С или Postgres Pro). Обычный PostgreSQL без доработок с 1С работает хуже или не работает совсем.
- 🧠
shared_buffers— ориентир около 25% памяти сервера. - 📊
effective_cache_size— 50–75% памяти: подсказка планировщику, сколько данных лежит в кэше ОС. - 🧹 autovacuum не отключайте. Без него таблицы разбухают от мёртвых строк, а статистика устаревает.
- 🔧 Для подбора остальных параметров удобно начать с калькулятора конфигурации под объём памяти и тип дисков, а потом сверить с замерами.
Изменение памяти СУБД и части параметров PostgreSQL требует перезапуска службы. Все сеансы пользователей оборвутся — делайте это вне рабочего времени и предупредите людей заранее.
Настройка сервера 1С:Предприятие под нагрузку
Сервер 1С управляется через консоль администрирования кластера или утилиту rac. Параметры, влияющие на скорость, лежат в двух местах.
Свойства рабочего сервера:
- Количество ИБ на процесс и количество соединений на процесс. Задают, как сеансы распределяются по рабочим процессам. Если несколько крупных баз крутятся в одном процессе, тяжёлая операция в одной тормозит соседей. Значение 1 для «ИБ на процесс» изолирует базы друг от друга ценой расхода памяти.
- Максимальный объём памяти рабочих процессов. Предел, после которого сервер начинает ограничивать новые вызовы. Ставьте с учётом памяти, которую забирает СУБД на той же машине.
- Безопасный расход памяти за один вызов. Защищает сервер от одного «прожорливого» отчёта, который съедает всю память.
- Диапазон портов рабочих процессов. Сам на скорость не влияет, но должен быть открыт в брандмауэре, иначе клиенты ждут таймаутов при подключении.
Свойства кластера:
- Интервал перезапуска и допустимый объём памяти рабочих процессов. Плановый перезапуск процессов раз в сутки ночью избавляет от постепенного «распухания» памяти.
Проверить, что происходит прямо сейчас, можно командами rac cluster list и rac session list: видно, сколько сеансов, у каких баз и пользователей. Остальные параметры смотрите в справке rac help.
Завершение рабочего процесса или перезапуск службы 1C:Enterprise 8.3 Server Agent обрывает сеансы. Несохранённые документы пользователи потеряют. Только по согласованию и вне рабочего времени.
Оптимизация запросов и кода конфигурации
Если железо и настройки в порядке, а медленная одна операция, — ищите причину в коде. Замер в конфигураторе покажет строку. Типовые ошибки повторяются от базы к базе.
🔍 Что чаще всего тормозит в запросах:
- Запрос в цикле. Сто строк документа — сто обращений к базе. Соберите нужные ссылки во временную таблицу и получите данные одним запросом с соединением.
- Условия вместо параметров виртуальной таблицы. Для
ОстаткииОстаткиИОборотыотбор задавайте в параметрах таблицы, а не вГДЕ. Иначе платформа сначала считает остатки по всему регистру, а потом отбрасывает лишнее. - Обращение «через точку» к полям составного типа. Поле
Регистратор.Датау составного типа превращается в соединение со всеми возможными таблицами. ИспользуйтеВЫРАЗИТЬ(Регистратор КАК Документ.РеализацияТоваровУслуг).Дата, если тип известен. ИЛИв условиях соединения и отбора. Мешает СУБД использовать индекс. Часто быстрее разбить на два запроса и объединить черезОБЪЕДИНИТЬ ВСЕ.- Большие временные таблицы без индекса. Если по временной таблице потом соединяются, добавьте
ИНДЕКСИРОВАТЬ ПОнужному полю.
Пример правильного получения остатков с отбором в параметрах:
ВЫБРАТЬ
Остатки.Номенклатура,
Остатки.КоличествоОстаток
ИЗ
РегистрНакопления.ТоварыНаСкладах.Остатки(
&НаДату,
Склад = &Склад И Номенклатура В (&Список)
) КАК Остатки
💡 Ещё два приёма практика:
- Режим управляемых блокировок. В автоматическом режиме СУБД блокирует данные шире, чем нужно, и пользователи ждут друг друга. Современные типовые конфигурации уже работают в управляемом режиме; в старых самописных базах перевод даёт заметный прирост при параллельном проведении.
- Общие модули с повторным использованием возвращаемых значений. Если функция много раз за сеанс читает одну и ту же настройку, свойство модуля «на время вызова» или «на время сеанса» убирает лишние обращения к базе.
Доработки типовой конфигурации делайте в расширении. Так исправление не потеряется при обновлении, а конфигурацию не придётся снимать с поддержки.
Железо и сеть: на что тратить деньги
Апгрейд оправдан, когда замер показал конкретный ресурс на пределе. Вот что реально влияет на скорость 1С.
| Компонент | Что важно | Ориентир |
|---|---|---|
| Процессор | Частота одного ядра важнее числа ядер | Высокая частота в турборежиме; ядра — по числу одновременных тяжёлых операций |
| Память | Хватает ли СУБД и рабочим процессам 1С | Чтобы активная часть базы помещалась в кэш СУБД |
| Диски | Задержка и случайный доступ | NVMe или SSD под данные, tempdb и журнал транзакций |
| Сеть | Задержка между сервером 1С и СУБД | Один сервер или 1–10 Гбит в одной стойке |
| Рабочие места | Частота CPU и SSD у клиента | Важно для толстого клиента и файловой базы |
🌐 Про сеть отдельно:
- 🔗 Сервер 1С и СУБД ставьте на одну машину или рядом. Каждый вызов 1С порождает десятки запросов к СУБД, и задержка сети между ними умножается.
- 📡 Для MS SQL на той же машине, что и сервер 1С, используйте протокол Shared Memory — он быстрее TCP.
- 🏠 Филиалы и удалённых сотрудников подключайте через тонкий клиент, веб-клиент или RDP. Толстый клиент по медленному VPN — гарантированные тормоза.
Виртуализация допустима, но следите, чтобы виртуальной машине СУБД не урезали частоту процессора и не делили диск с «шумными» соседями.
Регламентное обслуживание: чтобы база не замедлялась снова
Даже настроенная база со временем медленнее: растут таблицы, устаревает статистика, копятся служебные данные. Регулярный регламент держит скорость.
📅 Что делать и как часто:
| Операция | Где | Частота |
|---|---|---|
| Обновление статистики СУБД | План обслуживания MS SQL, VACUUM ANALYZE в PostgreSQL | Ежедневно ночью |
| Перестроение и реорганизация индексов | План обслуживания MS SQL, REINDEX в PostgreSQL | Раз в неделю |
| Тестирование и исправление базы | Конфигуратор → Администрирование → Тестирование и исправление | Раз в месяц–квартал, при сбоях |
| Пересчёт итогов регистров | Флажок в «Тестировании и исправлении» или Все функции → Стандартные → Управление итогами | После массовых исправлений, при расхождениях |
| Сокращение журнала регистрации | Конфигуратор → Администрирование → Настройка журнала регистрации | Когда журнал разросся до гигабайт |
| Очистка кэша клиента | Запуск с параметром /ClearCache или удаление папок кэша | При странных тормозах у пользователя |
Перед «Тестированием и исправлением» сделайте резервную копию. Режим требует монопольного доступа: всех пользователей нужно вывести из базы. Исправление ссылок и пересчёт на большой базе может идти часами.
Отдельно проверьте регламентные задания типовой конфигурации: Администрирование → Обслуживание → Регламентные операции → Регламентные и фоновые задания. Обмены, загрузка курсов, полнотекстовый индекс, запущенные каждые несколько минут в рабочее время, отнимают ресурсы у пользователей. Ненужные отключите, тяжёлые перенесите на ночь.
Для баз с многолетней историей помогает свёртка — перенос старых периодов в остатки. Это необратимая операция: сделайте полную копию, согласуйте с главным бухгалтером, какие годы сворачиваются, и не сворачивайте период, по которому ещё может прийти проверка.
Очистка кэша клиента вручную — закройте 1С и удалите папки с именами-идентификаторами в %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8. Или добавьте в строку запуска:
"C:\Program Files\1cv8\common\1cestart.exe" /ClearCache