Почему тормозит 1С и как найти узкое место: замеры по шагам

Чтобы измерить производительность 1С, начните с двух замеров: включите технологический журнал с фильтром по длительным событиям и снимите «Замер производительности» в Конфигураторе на медленной операции. Первый покажет, что тормозит на сервере и в СУБД, второй — какие строки кода съедают время. Остальное (тест базы, анализ индексов, нагрузочный тест, проверка сети) подключается по результатам.

Типичная картина: бухгалтер жалуется, что проведение реализации идёт 40 секунд, а в понедельник утром база «встаёт» совсем. Без цифр вы будете гадать между диском, сетью и кодом. С цифрами за полчаса видно, где именно теряется время: в запросе, в блокировке, в клиенте или в канале связи.

С чего начать оценку скорости работы 1С

Сначала зафиксируйте симптом. «Всё тормозит» не измерить. Нужна конкретная операция и время, которое она занимает.

📌 Что записать до любых замеров:

• 🕐 Операция: проведение документа, формирование отчёта, открытие формы, запуск базы.
• ⏱ Время: секундомер или замер в коде. Повторите 3 раза, возьмите среднее.
• 👥 Условия: один пользователь в базе или 30, утро или вечер, сразу после запуска или через час работы.
• 🖥 Вариант работы: файловая база или клиент-серверная, тонкий клиент, веб-клиент или RDP.
• 📦 Версии: номер платформы и релиз конфигурации (видно в Справка → О программе).

Затем ответьте на главный вопрос: тормозит у всех или у одного? Если у одного пользователя — смотрите его компьютер, сеть и права. Если у всех — сервер, СУБД, код и блокировки.

Технологический журнал: замер работы сервера 1С

Технологический журнал (ТЖ) — встроенный механизм платформы. Он пишет в текстовые файлы события: вызовы сервера, запросы к СУБД, блокировки, исключения. Каждая запись содержит длительность, пользователя, контекст кода и текст запроса.

Как включить технологический журнал

Журнал настраивается файлом logcfg.xml. Его кладут в каталог conf установки платформы, например C:\Program Files\1cv8\conf\. Платформа подхватывает файл без перезапуска, обычно в течение минуты.

Пример настройки: длительные запросы к MS SQL и ожидания на блокировках дольше 1 секунды.

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\TJ\slow" history="24">
    <event>
      <eq property="name" value="DBMSSQL"/>
      <ge property="duration" value="1000000"/>
    </event>
    <event>
      <eq property="name" value="TLOCK"/>
      <ge property="duration" value="1000000"/>
    </event>
    <event>
      <eq property="name" value="TTIMEOUT"/>
    </event>
    <event>
      <eq property="name" value="TDEADLOCK"/>
    </event>
    <property name="all"/>
  </log>
</config>

Здесь history="24" — сколько часов хранить файлы. Длительность в 8.3 указывается в микросекундах, поэтому 1000000 — это одна секунда. Для PostgreSQL вместо DBMSSQL укажите DBPOSTGRS.

Какие события смотреть

Как читать результаты

Файлы .log лежат в подкаталогах по процессам (rphost_1234, rmngr_5678). Каждая строка начинается со времени и длительности. Удобнее всего сортировать по длительности и группировать по контексту (Context) — это стек вызовов кода 1С.

💡 Для разбора больших логов администраторы пишут скрипты на PowerShell или bash либо используют бесплатные парсеры ТЖ. Главное — получить топ-10 контекстов по суммарной длительности, а не по одному самому долгому событию.

Замер производительности в отладчике и мониторинг

Технологический журнал говорит, что тормозит на сервере. Замер в отладчике показывает, какая строка кода это вызывает.

Замер в Конфигураторе

1. Откройте базу в Конфигураторе и запустите отладку (F5) или подключитесь к уже запущенному клиенту.
2. В Конфигураторе выберите Отладка → Замер производительности.
3. В клиенте выполните медленную операцию: проведите документ, сформируйте отчёт.
4. Снова выберите Отладка → Замер производительности, чтобы остановить замер.
5. Изучите таблицу: модуль, строка, количество выполнений, время и процент от общего.

Сортируйте по проценту времени. Обычно 1-3 строки дают 70-90% длительности. Чаще всего это запрос в цикле, обращение к реквизиту через точку в цикле или запись набора записей по одной строке.

Показатели производительности клиента

Тонкий клиент можно запустить с параметром /DisplayPerformance. В окне появятся показатели: число вызовов сервера и объём переданных данных для каждого действия. Если открытие простой формы даёт 15-20 вызовов сервера, проблема в коде формы, а не в железе.

Мониторинг в типовых конфигурациях

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

APDEX удобен для наблюдения в динамике: после обновления релиза или переезда на новый сервер видно, стало лучше или хуже.

На уровне Windows дополните картину счётчиками Монитора ресурсов и Системного монитора (perfmon):

• 🧠 загрузка процессора по процессам rphost, ragent, sqlservr;
• 💾 очередь диска и время отклика (выше 10-20 мс на запись — тревожный знак);
• 📈 доступная память и использование файла подкачки.

Тестирование и исправление информационной базы

Иногда база тормозит не из-за кода, а из-за накопленных проблем: раздутых таблиц, сбитых итогов, ошибок в индексах. Это проверяется штатной процедурой.

Порядок запуска

1. Сделайте резервную копию: выгрузку .dt или копию базы средствами СУБД.
2. Попросите всех пользователей выйти. Процедура требует монопольного доступа.
3. В Конфигураторе откройте Администрирование → Тестирование и исправление.
4. Отметьте нужные пункты и запустите.

Что даёт каждый пункт

Для файловой базы есть отдельная утилита chdbfl.exe в каталоге bin платформы. Она проверяет физическую целостность файла 1Cv8.1CD без запуска Конфигуратора.

💡 В клиент-серверной базе реиндексацию и обновление статистики лучше делать средствами СУБД регулярно, а не через тестирование и исправление.

Анализ запросов к СУБД и индексов

Если в технологическом журнале видны долгие DBMSSQL или DBPOSTGRS, дальше работаем на стороне СУБД.

MS SQL Server

• 🔍 План запроса. Скопируйте текст запроса из журнала и выполните его в SQL Server Management Studio с включённым фактическим планом. Ищите Index Scan и Table Scan по большим таблицам, «толстые» стрелки на миллионы строк.
• 📊 Статистика. Устаревшая статистика — частая причина плохих планов. Настройте план обслуживания: ежедневное обновление статистики, еженедельное перестроение индексов.
• 📁 Query Store и динамические представления показывают самые тяжёлые запросы за период без включения трассировки.

PostgreSQL

• 🔍 EXPLAIN (ANALYZE, BUFFERS) для плана с реальными цифрами.
• 📊 Расширение pg_stat_statements для топа запросов по суммарному времени.
• 🧹 Регулярный VACUUM ANALYZE: без него таблицы раздуваются, а статистика устаревает.

-- PostgreSQL: 10 самых тяжёлых запросов по суммарному времени
SELECT calls,
       round(total_exec_time::numeric, 0) AS total_ms,
       round(mean_exec_time::numeric, 1)  AS avg_ms,
       left(query, 120)                    AS query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

Индексы на стороне 1С

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

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

Нагрузочное тестирование 1С

Замер на одном пользователе не покажет, что будет при 50 одновременных сеансах. Для этого нужен нагрузочный тест.

Чем нагрузить базу

Тест Гилёва — самый быстрый способ понять, нормальное ли железо. Он не покажет проблему в коде, зато сразу выявит медленный диск или неудачную настройку электропитания.

Как провести тест правильно

1. Работайте на копии рабочей базы, а не на демо-базе: объём данных сильно влияет на результат.
2. Снимите базовые замеры на одном пользователе.
3. Увеличивайте число сеансов ступенями: 5, 10, 25, 50.
4. На каждой ступени записывайте время ключевых операций, загрузку процессора и диска, ожидания на блокировках.
5. Найдите ступень, на которой время операций резко выросло. Это и есть предел текущей конфигурации.

💡 Отдельно проверьте план электропитания сервера. Режим «Сбалансированный» в Windows Server снижает частоту процессора, и сервер 1С работает заметно медленнее. Для сервера 1С ставят «Высокая производительность». Для 1С важна частота одного ядра: многие операции выполняются в один поток.

Клиентская часть и сеть

Если сервер в порядке, а у пользователя всё равно медленно — проблема между ним и сервером.

Файловая база по сети

Файловая база через сетевую папку — самый частый источник жалоб. Каждое действие гоняет по сети блоки файла 1Cv8.1CD. При 5-7 одновременных пользователях и обычной офисной сети скорость падает заметно.

Варианты решения:

• 🌐 публикация базы на веб-сервере и работа через тонкий клиент по HTTP;
• 🖥 работа через терминальный сервер (RDP), где база лежит на локальном диске;
• 🏢 переход на клиент-серверный вариант при росте числа пользователей.

Что проверить на рабочем месте

• 📶 Пинг до сервера: в локальной сети — до 1-2 мс без потерь. Потери пакетов даже 1-2% дают ощутимые зависания.
• 🛡 Антивирус: добавьте в исключения каталог базы, каталог платформы и кэш %APPDATA%\1C\1cv8. Проверка каждого обращения к файлу базы замедляет работу в разы.
• 🗂 Кэш клиента: запуск с параметром /ClearCache сбрасывает кэш конфигурации. Помогает, когда после обновления у одного пользователя всё медленно.
• 🔌 Порты: для клиент-серверной базы клиент обращается к агенту сервера (1540), затем к менеджеру кластера (1541) и рабочим процессам (диапазон по умолчанию 1560-1591). Блокировка портов файрволом даёт долгий запуск и обрывы.

Тонкий клиент против толстого

Толстый клиент тянет больше данных по сети и чувствительнее к её качеству. Если пользователи работают в толстом клиенте только по привычке, переход на тонкий часто ускоряет работу без замены железа. Проверить разницу можно параметром /DisplayPerformance: сравните объём трафика на одной и той же операции.

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