Почему 1С тормозит: шесть узлов, которые определяют скорость базы

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

Ускорение 1С всегда начинается с поиска узкого места, а не с покупки железа. Если тормозит проведение одного документа у одного пользователя — виноват, скорее всего, код или блокировки. Если медленно всё и у всех — смотрите сервер, диски и СУБД.

Процессор, память и диски: какое железо реально ускоряет 1С

Сервер 1С и СУБД нагружают железо по-разному. Поэтому ориентироваться на «общую мощность» бессмысленно — важны конкретные параметры.

🔹 Процессор. Проведение документа, формирование отчёта, пересчёт итогов в рамках одного сеанса идут в одном потоке. Значит, решает частота ядра и поколение процессора. Много ядер нужно, когда одновременно работают десятки пользователей и фоновые задания.

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

🔹 Диски. Для СУБД критична задержка, а не объём. NVMe SSD под файлы базы и tempdb дают кратный выигрыш по сравнению с HDD и сетевыми хранилищами среднего класса.

🔹 Рабочая станция. Для тонкого клиента мощный компьютер не нужен, но на старом ПК с HDD и 4 ГБ памяти тормозит уже интерфейс: открытие форм, прорисовка списков.

Виртуализация сама по себе не мешает. Мешает переподписка: когда на одном физическом хосте виртуальным машинам выдано больше ядер и памяти, чем есть. Тогда сервер 1С ждёт процессорного времени, и это выглядит как «случайные тормоза».

Файловый вариант или клиент-сервер: как архитектура базы влияет на скорость

Файловая база хранит всё в одном файле 1Cv8.1CD. Каждый клиент сам читает и пишет в этот файл, а блокировки ставятся на целые таблицы. Пока пользователей несколько человек и база лежит на локальном SSD, это работает быстро. При росте числа пользователей начинаются очереди: один проводит документ — остальные ждут.

Клиент-серверный вариант переносит работу с данными на сервер 1С и СУБД (MS SQL Server или PostgreSQL). Блокировки становятся точечными, на уровне записей, а клиент получает только результат.

Настройки MS SQL Server, которые влияют на 1С

• 🧠 Max server memory. Ограничьте память SQL Server так, чтобы осталось место ОС и серверу 1С, если они на одном хосте. Без ограничения SQL забирает почти всё.
• 💾 Модель восстановления. При модели «Полная» без регулярного резервного копирования журнала файл журнала растёт бесконечно. Если восстановление на момент времени не нужно — модель «Простая».
• 📂 tempdb — на быстрый диск, несколько файлов данных одинакового размера.
• 📊 Статистика и индексы. Обновление статистики ежедневно, перестроение или реорганизация индексов — еженедельно в нерабочее время. После обновления статистики принято очищать процедурный кэш, чтобы планы запросов перестроились.

Настройки PostgreSQL для 1С

Для 1С используйте сборку PostgreSQL с патчами для 1С — обычный дистрибутив без них работает с базами 1С хуже или не работает совсем. Базовые параметры в postgresql.conf:

shared_buffers = 4GB            # ориентир ~25% RAM сервера СУБД
effective_cache_size = 12GB     # ориентир ~75% RAM
work_mem = 64MB                 # память на операцию сортировки
maintenance_work_mem = 1GB      # для VACUUM и построения индексов

Значения выше — для сервера с 16 ГБ, выделенного под СУБД. Пересчитайте под свой объём. Регулярный VACUUM ANALYZE (автовакуум плюс ночной ручной проход для крупных таблиц) так же важен, как обновление статистики в MS SQL.

Код конфигурации и блокировки: где база теряет больше всего времени

Самое мощное железо не спасёт от неудачного запроса. Доработки конфигурации — главный источник локальных тормозов: «вот этот документ проводится минуту».

Типовые проблемы в коде

• 🔁 Запрос в цикле. Вместо одного запроса на 1000 строк выполняется 1000 запросов. Каждый — это круг до СУБД и обратно.
• 🔗 Обращение к реквизитам «через точку». Конструкция Документ.Контрагент.ИНН в коде на сервере неявно читает весь объект контрагента. В цикле это сотни лишних чтений.
• 🧮 Условия не в параметрах виртуальных таблиц. Отбор по остаткам и оборотам нужно задавать в параметрах Остатки(...) или Обороты(...), а не в ГДЕ. Иначе СУБД сначала считает остатки по всем аналитикам, а уже потом отбрасывает лишнее.
• 📋 Тяжёлый код в событиях форм. Обработчики ПриОткрытии и ПриИзменении, которые лезут на сервер по каждому чиху, превращают ввод документа в ожидание.

Пример. Плохо:

Для Каждого Строка Из Товары Цикл
    Запрос = Новый Запрос("ВЫБРАТЬ Цена ИЗ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(, Номенклатура = &Номенклатура)");
    Запрос.УстановитьПараметр("Номенклатура", Строка.Номенклатура);
    Строка.Цена = Запрос.Выполнить().Выгрузить()[0].Цена;
КонецЦикла;

Лучше — один запрос по списку номенклатуры, условие в параметрах среза:

Запрос = Новый Запрос("ВЫБРАТЬ Номенклатура, Цена
    |ИЗ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(, Номенклатура В (&Список))");
Запрос.УстановитьПараметр("Список", Товары.ВыгрузитьКолонку("Номенклатура"));
Цены = Запрос.Выполнить().Выгрузить();

Дальше цены разносятся по строкам через поиск в полученной таблице — без обращений к базе.

Режим блокировок

У конфигурации есть свойство «Режим управления блокировкой данных». Типовые конфигурации на 8.3 давно работают в управляемом режиме: блокируются только нужные записи. Старые самописные базы и конфигурации, переведённые с 8.1/8.2, могут оставаться в автоматическом режиме. Там блокировки СУБД ставятся шире, и пользователи ловят ошибку Превышено время ожидания установки блокировки или взаимоблокировки.

Перевод на управляемые блокировки — работа программиста, а не галочка: нужно проверить код, который полагается на автоматические блокировки.

Сеть и способ подключения: когда задержка важнее скорости канала

Для 1С ширина канала почти не важна, важна задержка (ping). Одна операция порождает много мелких обменов, и каждые лишние миллисекунды умножаются на их количество.

Три участка сети, которые стоит различать:

1. Сервер 1С ↔ СУБД. Самый чувствительный участок: здесь идёт каждый запрос к данным. Идеально — один физический хост или выделенная сеть 10 Гбит/с с задержкой заметно меньше миллисекунды. Если SQL Server стоит на той же машине, что и сервер 1С, включите протокол Shared Memory.
2. Клиент ↔ сервер 1С. Тонкий клиент передаёт немного данных и нормально работает даже через интернет . Порты: агент кластера — 1540, менеджер — 1541, рабочие процессы — диапазон, заданный в свойствах рабочего сервера (по умолчанию 1560–1591).
3. Файловая база по сети. Самый неудачный вариант. Клиент тянет страницы файла через сетевую папку SMB, и любая задержка — Wi-Fi, VPN, загруженный коммутатор — сразу превращается в тормоза.

Отдельно — антивирус. Проверка «на лету» файлов базы, каталога кэша %APPDATA%\1C\1cv8 и временных файлов сервера 1С замедляет каждое обращение. Добавьте эти каталоги в исключения по согласованию со службой безопасности.

Регламентные задания и фоновая нагрузка: кто нагружает базу без пользователей

Часть нагрузки создают не люди, а сама программа. Обмены данными, обновление полнотекстового индекса, загрузка курсов валют, получение почты, обмен с ЭДО и банком — всё это выполняется фоновыми заданиями. Если десяток таких заданий запускается каждые пять минут в рабочее время, пользователи чувствуют это как «волны» тормозов.

В БП 3.0, ЗУП 3.1 и УТ 11 список открывается так: Администрирование → Обслуживание → Регламентные операции → Регламентные и фоновые задания. Что проверить:

• ⏰ Расписание. Тяжёлые задания — обновление индекса полнотекстового поиска , пересчёт итогов, архивирование — перенесите на ночь.
• 🚫 Ненужные задания. Отключите то, чем не пользуетесь: обмен с сервисом, который не подключён, загрузку данных, которые никто не смотрит.
• ❗ Задания с ошибками. Задание, которое падает и перезапускается, тратит ресурсы впустую.

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

Обслуживание самой базы

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

Мониторинг: как найти, что именно тормозит

Гадать бесполезно. Сначала измерение, потом действие.

Инструменты платформы и конфигурации

• 📈 Оценка производительности (APDEX). В типовых конфигурациях есть подсистема оценки производительности: она замеряет время ключевых операций и считает индекс удовлетворённости пользователей. Удобно сравнивать «до» и «после» изменений.
• 🔍 Замер производительности. В конфигураторе при отладке (меню Отладка → Замер производительности) показывает, какие строки кода съели время. Это главный инструмент программиста.
• 📝 Технологический журнал. Включается файлом logcfg.xml в каталоге conf платформы на сервере 1С. Пишет события: длинные запросы к СУБД (DBMSSQL, DBPOSTGRS), ожидания блокировок (TLOCK, TTIMEOUT), взаимоблокировки (TDEADLOCK), исключения.

Минимальный пример — журнал запросов к СУБД дольше одной секунды:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\TechLog" history="24">
    <event>
      <eq property="name" value="DBMSSQL"/>
      <gt property="durationus" value="1000000"/>
    </event>
    <property name="all"/>
  </log>
</config>

Счётчики операционной системы и СУБД

В Windows через «Системный монитор» (perfmon) смотрите:

Синтетический тест

Тест Гилева — популярная бесплатная обработка, которая меряет однопоточную скорость связки «клиент — сервер 1С — СУБД — диск». Абсолютное значение мало о чём говорит. Полезно сравнение: тот же тест на другом сервере, до и после смены настроек, днём и ночью.

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