Почему 1С тормозит и что ускорит её на самом деле: от замера до железа

· 11 мин

Содержание

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

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

МетодКогда помогаетЦена и риск
Исключения антивируса, план питанияФайловая база, тормозит всё подрядБесплатно, риска нет
Очистка кэша клиентаМедленный запуск, странные зависания формБесплатно, нужно закрыть 1С
Обслуживание СУБД (индексы, статистика)Отчёты и проведение замедлялись постепенноБесплатно, нагрузка на сервер во время работ
Настройка памяти MS SQL / PostgreSQLСервер упирается в диск, хотя памяти многоБесплатно, нужен перезапуск службы
Переход с файлового варианта на клиент-серверОт 5–10 активных пользователей, частые блокировкиЛицензия сервера, работа администратора
Оптимизация запросов и кодаМедленная одна операция при нормальном железеВремя программиста
Замена дисков на NVMe, рост частоты CPUЗамер показал очередь к диску или загрузку ядраДеньги, простой на переезд

Сначала замер: как найти, где 1С теряет скорость

Жалоба «1С тормозит» ничего не говорит. Нужно ответить на три вопроса: что именно медленно, у кого и с какого момента.

📌 Соберите факты до любых настроек:

  • 🐢 Какая операция. Запуск, открытие списка, проведение документа, конкретный отчёт, закрытие месяца .
  • 👥 У кого. У всех сразу или у одного пользователя. Если у одного — смотрите его компьютер, сеть и кэш, а не сервер.
  • 🕐 Когда. Всегда, по утрам, в конце месяца, после обновления. Внезапное замедление обычно связано с изменением: релиз, новые данные, обновление Windows или антивируса.
  • 🔒 Ждёт или считает. Если операция висит, а процессор и диск почти не загружены, причина часто в блокировке: другой пользователь держит те же данные.

Инструменты замера

  1. Оценка производительности в типовой конфигурации. В БП 3.0, ЗУП 3.1 и УТ 11 включается в Администрирование → Обслуживание → Оценка производительности. Подсистема копит время ключевых операций и считает показатель APDEX. Удобно, чтобы сравнить «до» и «после».
  2. Замер в конфигураторе. Запустите отладку, включите Отладка → Замер производительности, выполните медленную операцию. Отчёт покажет строки кода и запросы, где ушло больше всего времени.
  3. Технологический журнал. Настраивается файлом logcfg.xml в каталоге conf платформы. Пишет длинные запросы, ожидания на блокировках, исключения. Включайте только нужные события: полный журнал быстро съедает диск.
  4. Монитор ресурсов Windows (resmon) и счётчики производительности (perfmon). Смотрите загрузку каждого ядра, длину очереди диска и свободную память на сервере 1С и сервере СУБД.
  5. Тест Гилёва. Внешняя бесплатная обработка, которая даёт условный балл однопоточной производительности связки «платформа — СУБД — железо». Полезна, чтобы сравнить два сервера или проверить эффект настройки.
Диагностика: выберите симптом

Файловая база или клиент-сервер: когда пора переезжать

Файловый вариант хранит всё в одном файле 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

  1. Ограничьте память. В свойствах сервера задайте Maximum server memory. Без ограничения SQL Server забирает почти всю память, и если на той же машине работает сервер 1С, они начинают драться. Ориентир: оставить операционной системе 4–8 ГБ и учесть память рабочих процессов 1С.
  2. Параллелизм. Для баз 1С обычно ставят Max Degree of Parallelism = 1. Параллельные планы на коротких запросах 1С чаще мешают, чем помогают.
  3. tempdb — на быстрый диск. 1С активно пишет временные таблицы. Разнесите tempdb на отдельный SSD или NVMe, создайте несколько файлов данных одинакового размера.
  4. Модель восстановления. Если не нужен откат на произвольный момент времени, модель Simple избавляет от разрастающегося журнала транзакций. Если нужна полная модель — настройте резервное копирование журнала, иначе файл .ldf вырастет до размера диска.
  5. Автоприращение файлов задавайте в мегабайтах (например, 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. Запрос в цикле. Сто строк документа — сто обращений к базе. Соберите нужные ссылки во временную таблицу и получите данные одним запросом с соединением.
  2. Условия вместо параметров виртуальной таблицы. Для Остатки и ОстаткиИОбороты отбор задавайте в параметрах таблицы, а не в ГДЕ. Иначе платформа сначала считает остатки по всему регистру, а потом отбрасывает лишнее.
  3. Обращение «через точку» к полям составного типа. Поле Регистратор.Дата у составного типа превращается в соединение со всеми возможными таблицами. Используйте ВЫРАЗИТЬ(Регистратор КАК Документ.РеализацияТоваровУслуг).Дата, если тип известен.
  4. ИЛИ в условиях соединения и отбора. Мешает СУБД использовать индекс. Часто быстрее разбить на два запроса и объединить через ОБЪЕДИНИТЬ ВСЕ.
  5. Большие временные таблицы без индекса. Если по временной таблице потом соединяются, добавьте ИНДЕКСИРОВАТЬ ПО нужному полю.

Пример правильного получения остатков с отбором в параметрах:

ВЫБРАТЬ
    Остатки.Номенклатура,
    Остатки.КоличествоОстаток
ИЗ
    РегистрНакопления.ТоварыНаСкладах.Остатки(
        &НаДату,
        Склад = &Склад И Номенклатура В (&Список)
    ) КАК Остатки

💡 Ещё два приёма практика:

  • Режим управляемых блокировок. В автоматическом режиме СУБД блокирует данные шире, чем нужно, и пользователи ждут друг друга. Современные типовые конфигурации уже работают в управляемом режиме; в старых самописных базах перевод даёт заметный прирост при параллельном проведении.
  • Общие модули с повторным использованием возвращаемых значений. Если функция много раз за сеанс читает одну и ту же настройку, свойство модуля «на время вызова» или «на время сеанса» убирает лишние обращения к базе.

Доработки типовой конфигурации делайте в расширении. Так исправление не потеряется при обновлении, а конфигурацию не придётся снимать с поддержки.

Железо и сеть: на что тратить деньги

Апгрейд оправдан, когда замер показал конкретный ресурс на пределе. Вот что реально влияет на скорость 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

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

Поможет ли просто добавить оперативной памяти?
Только если её не хватает: в мониторе ресурсов видно постоянное обращение к файлу подкачки или СУБД упирается в диск. Если память свободна, добавка ничего не даст.
Что быстрее для 1С — MS SQL или PostgreSQL?
При грамотной настройке разница на типовых задачах невелика. Важнее версия сборки, настройки памяти и регулярное обслуживание, чем выбор самой СУБД.
Почему 1С медленно запускается, а потом работает нормально?
При запуске клиент загружает конфигурацию и сверяет кэш. Медленный старт дают разросшийся или испорченный кэш, проверка антивирусом, медленный канал до сервера и много подсистем на начальной странице.
Ускорит ли работу переход на веб-клиент или тонкий клиент?
Для удалённых пользователей — да: по сети идут только данные форм, вся обработка — на сервере. В локальной сети с быстрым сервером разница заметна меньше.
Нужно ли обновлять платформу ради скорости?
Новые версии платформы нередко содержат исправления производительности. Обновляйте на версию, которую поддерживает ваш релиз конфигурации, и сначала проверьте на копии базы.