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

Продолжаем разбор производительности 1С уже на уровне диагностики: технологический журнал, CPU, NUMA, диски, кластер, блокировки и СУБД.

Автор статьи:

Владимир Баданов

Специалист поддержки КОРП клиентов в Инфостарт

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

После публикации читатели попросили больше конкретики. Поэтому теперь разберем несколько технических сценариев и покажем ход расследования на реальных примерах. При этом задача статьи не в том, чтобы дать универсальную инструкцию по диагностике. Ее не существует. В крупных системах одни и те же симптомы могут иметь разные причины, а устранение одного ограничения иногда просто открывает следующее.

Определяем, где система теряет время

Когда говорят, что 1С тормозит, то фактически эта формулировка не содержит технической информации.

Что именно тормозит? Клиент? Сервер 1С? Запрос к СУБД? Диск? Пользователь ждет блокировку другого сеанса? Сервер занят выполнением кода?

Нагрузку создает код. Если ничего не запускать, ресурсов практически любого современного оборудования будет достаточно. Поэтому самый надежный способ повысить производительность – оптимизировать выполняемые операции. 

Но на практике добавить аппаратные ресурсы часто проще и быстрее, чем разбираться с кодом.

В клиент-серверном варианте 1С работает по трехзвенной архитектуре и итоговое время выполнения состоит из:

• работы кода на стороне пользователя
• передачи данных на сервер 1С
• работы кода на стороне сервера 1С
• передачи запроса в СУБД

Важно понимать вклад каждой компоненты в общее время выполнения.

Поэтому первый вопрос диагностики: «Какой компонент занимает основную часть времени выполнения проблемной операции?» Для этого необходимо настроить сбор следующих событий:

• EXCP – информация об ошибках, эти данные полезны при любом сценарии диагностики;
• VRSREQUEST, VRSRESPONSE – определяют границы времени выполнения серверного вызова с клиента. Простыми словами серверный вызов на клиенте начинается с VRSREQUEST и заканчивается VRSRESPONSE. Все, что происходит до и после, в данном случае не представляет интереса. 
• SCALL – нужен на клиенте и сервере, определяет длительность, объем и получателя серверного вызова. 
• CALL – нужен на сервере. Определяет длительность, объем и получателя входящего от клиента вызова;
• PROC – следим за запуском и завершением рабочих процессов. При нормальной работе рабочий процесс работает несколько часов. Параллельно могут стартовать рабочие процессы для фоновых заданий. Большое количество (>100) рабочих процессов запущенных в день это подозрительно.
• TLOCK – важны события с отбором WaitConnections <> «». Проверяем, ожидает ли кто-то на блокировках.
• TTIMEOUT – следим за превышением времени блокировок. Наличие таких событий – плохой знак. 
• SDBL – информация о длительности запросов к СУБД. Нужно исключить события, где Func = ‘HoldConnection’ или Func = ‘CommitTransaction’

Далее:

1. В клиентском ТЖ находим границы операции по VRSREQUEST, VRSRESPONSE. Сами события ищем по контексту, например:
   grep -r -P 'VRSREQUEST.*ПоступлениеТоваровУслугФормыКлиент.ПередЗаписью'
   grep -r -P 'VRSRESPONSE.*ПоступлениеТоваровУслугФормыКлиент.ПослеЗаписи'

2. Запоминаем интервал между ПередЗаписью и ПослеЗаписи: 2026-08-20T13:24:09 – 2026-08-20T13:24:11.

3. В клиентском ТЖ находим SCALL. Он идет следом за VRSREQUEST, поэтому можно просто получить следующую строку:
grep -r -A1 -P '"2026-08-20T13:24:09.561010"'

Нам нужен "CallID":"22631".

4. В серверном ТЖ находим CALL от клиента по CallID: grep -r -P 'CallID":"22631"'.

5. Запоминаем номер соединения: "t:connectID":"67".

6. В серверном ТЖ по номеру соединения фильтруем все события CALL. Суммируем длительность CpuTime:
grep -r -P '2026-08-20T13:24:(09|10|11).*"CALL".*connectID":"67»' | awk -F '"CpuTime":"' '{split($2, a, "\""); sum += a[1]} END {print sum}'

7. В серверном ТЖ по номеру соединения фильтруем все события SDBL. Суммируем длительность:
grep -r -P '2026-08-20T13:24:(09|10|11).*DBMSSQL.*connectID":"67»' | grep -v -P 'HoldConnection|CommitTransaction' | awk -F '"duration":"' '{split($2, a, "\""); sum += a[1]} END {print sum}'

8. В данном примере за 2,5 секунды сервер 1С работал 0,8 секунды, сервер СУБД – 0,9 секунды. Это пример с тестовой базы, поэтому цифры в порядке и перекоса нет.

В итоге мы получим время выполнения всей операции с точки зрения клиента, время выполнения кода на стороне 1С и время выполнения запросов. Теперь мы можем определить, какой компонент занимает большую часть времени выполнения операции.

Если серверная часть отработала быстро, а основное время осталось на клиенте, исследуем клиентскую часть и передачу данных. 

Длительные операции на клиенте

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

Большой объем передаваемых данных по сети

• Легко диагностируется тем же самым ТЖ – необходим глянуть Content-Length в событиях VRSREQUEST и  VRSRESPONSE. Например:

• Видно, что с сервера было передано более мегабайта данных.

Низкая скорость и проблемы сети

Как правило, проблемы не связаны непосредственно с недостаточной пропускной способностью сети. Подключения со скоростью ниже 1 Гбит/с встречаются редко. Но различные проблемы сети могут снизить скорость обмена. Рекомендуется проверить сеть обычным ping и iperf. Этих проверок может быть недостаточно. Дополнительно рекомендуем проверить в ТЖ события:

• EXCP – на предмет сетевых ошибок. Например: No such host is known.
• ATTN – на предмет доступности элементов кластера. Искать сообщения:
  • Server unavailable. Рабочий сервер недоступен.
  • Server check error. Возникла непредвиденная ошибка при опросе рабочего сервера.
  • Main manager inaccessible. Локальный главный менеджер недоступен.
  • Main manager not responding. Локальный главный менеджер не отвечает.
  • Process inaccessible. Процесс кластера недоступен.
  • Process not responding. Процесс кластера не отвечает.
  • Process exceeded critical memory limit. Указанный процесс будет принудительно завершен с целью освобождения памяти.
  • Memory exceeded temporary allowed limit. Память процессов сервера превысила временно допустимый объем.
  • Memory exceeded critical limit. Память процессов на сервере превысила критический объем.
  • Memory shortage detected. Свободной оперативной памяти осталось меньше безопасного расхода за один вызов.
  • Подробнее по ссылке: https://its.1c.ru/db/v8327doc#bookmark:adm:TI000000995

Работа в веб-клиенте:

Отрисовка в веб-клиенте занимает больше ресурсов и времени относительно тонкого клиента. При слабом процессоре скорость отрисовки в браузере может существенно замедлиться. Необходимо проверить поведение в тонком клиенте.

Длительные операции на сервере 1С

На сервере 1С причин для медленного выполнения гораздо больше, и их уже стоит сгруппировать:

Аппаратные:

• Процессор:
  • Низкая производительность процессора. Процессор загружен на 100%. Заголовок статьи предполагает, что нагрузки на процессор нет, но все же рассмотрим этот случай. Как увидеть, что процессор загружен? В диспетчере задач хорошо видна нагрузка на каждое логическое ядро.

• На картинке видно, что 12 ядер загружены почти на 80%. Это признак недостатка в процессоре. Требуется расследование источника нагрузки – это уже тема для отдельной статьи.
• Режим энергосбережения снижает частоты, и процессору требуется время на то, чтобы «проснуться». Если в диспетчере задачи видно, что текущая частота плавает, то это признак того, что высокая производительность не включена. Частота должна быть зафиксирована и желательно быть выше базовой – работать на частоте Turbo Boost. Проверяем в cmd «powercfg /getactivescheme» и устанавливаем режим высокой производительности. Иногда этого недостаточно и необходимо изменить настройки в BIOS.
• Важно смотреть нагрузку на каждое ядро. Если ориентироваться только на общую нагрузку ЦП, то на картинке выше кажется, что процессор загружен только наполовину. Но ПРОФ-версия 1С может использовать только 12 ядер, и поэтому для 1С загрузка составляет примерно 80%. Нагрузку со стороны 1С можно проверить через событие ТЖ CLSTR – необходимо искать свойство «Performance update».

• Значение CPU выше 60% и queue_length выше количества ядер сигнализируют о недостатке в процессоре.
• Желательно проверить количество NUMA-узлов и убедиться, что количество рабочих процессов равно или больше количества NUMA-узлов – иначе не все ядра будут задействованы.
• При закупках выбирайте высокочастотные процессоры – лучше меньше ядер, но с большей частотой. Правило не железное. Были случаи, когда процессор с меньшей частотой был производительнее, но чаще производительность на ядро в приоритете.

• Оперативная память:
  • Недостаток скорости обычно не является проблемой, но стоит проверить скорость ОЗУ приложениями AIDA64, maxxmem2 или PassMark PerformanceTest и сравнить с типовыми (https://en.wikipedia.org/wiki/DDR_SDRAM#Generations).
  • Недостаток объема. Признаки: в PerfMon растет значение счетчика «Paging File \ % Usage», а значение «Memory \ Pages/sec» превышает 20. Это означает, что используется файл подкачки, и системе не хватает ОЗУ. 
• Дисковая подсистема:
  • Недостаточная скорость. Синтетическими тестами тяжело определить, что диск не справляется. Нужно следить за реальной очередью на диск и средним временем обращения к диску. В идеале очередь должна быть близка к нулю. Если очередь больше, чем количество дисков в массиве, это повод разбираться. А время обращения к диску в идеале должно быть меньше 0,003 с (3 мс). Могут быть пики, но если задержка большую часть времени больше 10мс – также повод разбираться с ситуацией.

• Сеть:
  • Если между клиентом и сервером обычно нет недостатка в скорости сети, то между сервером 1С и СУБД бывает и нередко. Сейчас уже большинство использует сети со скоростю 10 Гбит/c – с ними обычно проблем нет. Но если между 1С и СУБД сеть со скоростью 1 Гбит/c, то есть большая вероятность упереться в сеть. Для проверки нужно определить предельную и фактическую скорость передачи:
    • запустить «iperf3 -s» на СУБД;
    • на сервере 1С запустить «iperf3 -c ИмяСервера»;
    • запустить perfmon со счетчиками «Получено байт/с» и «Отправлено байт/с».
  • Если скорость, полученная через PerfMon, приближается к скорости, полученной через iperf3, то сеть может быть слабым звеном.
  • Скорость, измеренная через iperf3, должна быть равна скорости интерфейса. Если стоит сетевая карта на 10 Гбит/c, а iperf3 показывает 4 Гбит/c – есть проблемы в сети.

В этой статье мы предполагаем, что проблемы в оборудовании уже нашли и исправили, поэтому теперь рассмотрим причины медленной работы помимо недостатка в оборудовании. 

Настройки:

• Настройки ОС:
  • Наличие антивируса на сервере. «1С» не рекомендует установку антивируса на сервере. Но если в этом есть необходимость – проверьте, что 1С и используемые ею папки были добавлены в исключения.
  • Режим экономии энергии. Необходимо включить производительный режим.
  • Нагрузка от сторонних приложений. Сторонние приложения не только снижают производительность сервера, но и влияют на балансировку в кластере 1С. Может показаться, что ничего страшного не произойдет, если в рабочее время сделать резервную копию базы на диск C: сервера 1С. Но из-за снижения производительности диска кластер 1С может обнаружить дисбаланс и начать перемещать пользователей с этого сервера на другой.
• Настройки кластера 1С:
  • Некорректная настройка количества сеансов на процесс. С этой настройкой встречается 2 ветки проблем:
    • на процесс установлено соединений больше возможного. В результате всегда работает только один рабочий процесс. Это приводит к следующим проблемам:
      • нагрузка распределяется по ядрам неоптимально, особенно если в системе больше одного NUMA-узла;
      • обычное или аварийное завершение единственного рабочего процесса вызывает задержки, т. к. всех пользователей приходится переводить на новый процесс.
    • установлено слишком маленькое значение. В результате формируется большое количество рабочих процессов:
      • менеджеру кластера уходит больше ресурсов на их обслуживание;
      • рабочие процессы запускаются и завершаются с высокой частотой – каждый старт рабочего процесса это загрузка контекста – возникает избыточная нагрузка на диск. 
  • Некорректная настройка количества баз на процесс:
    • часто ставят значение 1, мысль вроде бы правильная – одну главную рабочую базу отдать одному rphost. Но если у вас есть базы, в которых работают только регламентные задания, то каждый раз при запуске задания будет стартовать рабочий процесс и нагружать диск и процессор. Как это проверить? Включите любой ТЖ, посмотрите какое количество папок rphost_* сформировалось за день – если больше 50, это повод проверить настройки.
    • можем также получить ошибку «Ошибка установки соединения» при входе первого сеанса в базу из-за долгого запуска рабочего процесса.
  • Некорректная настройка администраторов сервера:
    • если в кластере более одного сервера и назначены администраторы, важно проверить, что на всех серверах есть один общий администратор. Включите ТЖ с событием EXCP – если есть сообщение «Центральный сервер не аутентифицирован», значит нужно привести администраторов к единому виду согласно пункту 5.2.4 документации https://its.1c.ru/db/v8325doc#bookmark:cs:TI000000146.
      Такая настройка приводит к нарушению обмена между серверами кластера и нарушается балансировка нагрузки. Возникают ситуации, когда серверы нагружены неравномерно. Все соединения могут быть перенаправлены на менее производительный сервер. 
  • Включенная отладка:
    • делать отладку настоятельно не рекомендуется на продуктовых серверах. Но если очень хочется, то есть лазейка – завести базу в другом кластере. Однако есть нюансы, описанные в пункте 5.2.1.3.8 документации: https://its.1c.ru/db/v8325doc#bookmark:adm:TI000000105
  • Тестовые базы:
    • производят нагрузку через регламентные задания. Такие задания нужно обязательно отключить. Как проверить? Ищем в ТЖ вызовы от этих баз: grep -r -P '"CALL".*"p:processName":"ИмяТестовойБазы"'

Код и запросы:

• Управляемые блокировки. Самая частая проблема – сделать доработку в коде и заблокировать данные чуть больше, чем нужно. В итоге сеансы ждут друг друга, процессор и СУБД простаивает, параллельности нет – работает один, остальные ждут. Как проверить? Найти в ТЖ события TLOCK, у которых атрибут WaitConnections не пустой. Если длительность таких событий превышает три секунды – это плохой знак. Пример команды для поиска события: grep -r -P 'WaitConnections=\d{1,}'. А если в ТЖ есть события TTIMEOUT, то, скорее всего, вы о них знаете.
• Неуправляемые блокировки. Это блокировки на уровне СУБД. Возникают в базах с автоматическим уровнем блокировки. Более высокий уровень изоляции убивает параллелизм, многие операции идут почти в один поток. Как понять, что большая часть времени затрачивается на ожидания блокировок СУБД? Для MSSQL выполнить запрос в представлению sys.dm_os_wait_stats и отсортировать по времени. Если самыми длительными являются строки с названием «LCK_M_*», то проблема кроется в автоматических блокировках. 
• Временные файлы. Редкая проблема, но удалять временные файлы нужно. При достижении количества файлов 65 тысяч в папке Temp, работа с этой папкой становится затруднительна. 
• Лишний код. В современных конфигурациях миллионы строк кода. Очень много кода выполняется впустую. Например, список дел на рабочем столе может формироваться 5 секунд. Да, он формируется в фоне, но если пользователь не смотрит дела и рекламную информацию, то нет смысла выполнять этот код, это тоже нагрузка, и на некоторых проектах это была существенная нагрузка. Важно грамотно провести внедрение продукта и отключать неиспользуемые модули.

Ошибки:

• Падения рабочих процессов. Имеются ввиду, аварийные завершения. Как минимум заставляют сеансы переподключаться к другому процессу, как максимум завершаются серверные вызовы с ошибкой. Это очень большая нагрузка. Как проверить? Включаем ТЖ со строкой «<dump create="true" location="C:\1C\tehlog\Dump" type="3" prntscrn="false" externaldump="false"/>» – если в папке C:\1C\tehlog\Dump есть файлы, значит процесс падает, необходимо искать причины.

Пример одного обращения

История одной диагностики: клиент обратился с просьбой разобраться в тормозах.
Проводим сбор данных:

• ТЖ: события ATTN, CLSTR, CONN, EXCP, EXCPCNTX, PROC, SDGC, SESN, TDEADLOCK, TLOCK, TTIMEOUT, SDBL, DBMSSQL, CALL, SCALL;
• perfmon: загрузка процессора общая и по процессам 1С, используемое ОЗУ, очередь на дисках, скорость на дисках, скорость по сети;
• замеры скорости диска fio;
• замеры скорости сети iperf3;
• настройки и представления в СУБД MSSQL.

Видим запредельные очереди на дисках: среднее значение – 167:

Мы предложили заменить диск на твердотельный. Через некоторое время клиент провел оптимизацию оборудования на сервере СУБД. Очереди пропали. Но на сервере 1С, который не менялся, резко возросла нагрузка на процессор:

Повторный аудит выявил новые проблемы, а самое главное, анализ ожиданий на СУБД показал, что имеются критические ожидания на блокировках СУБД:

Причин этих задержек также может быть много, есть признаки того, что неактуальная статистика и плохое покрытие индексами провоцируют длительные запросы с более широкими блокировками. А как вы боролись с автоматическими блокировками? Расскажите в комментариях.

Этой историей хотели показать, что, как правило, проблем несколько и после исправления одного узкого места, возникает другое. Не всегда обновление железа исправляет все проблемы. Так, замена дисков СУБД на более производительные вызвала рост нагрузки на сервер 1С. И автоматические блокировки никуда не денутся при установке новых дисков.

А что с СУБД?

Мы будем говорить про MSSQL. Если интересно увидеть статью по PostgreSQL, напишите об этом в комментарии – мы подготовим материал.

Также сгруппируем проблемы по темам.

Аппаратное обеспечение:

• Процессор. Обычно MSSQL эффективно использует ресурсы процессора, поэтому в первую очередь стоит следить за нагрузкой процессора. Но есть нюанс – ограничение на количество ядер в зависимости от редакции. Например, в Standard – 24 ядра.
• Оперативная память. Главный признак, по которому можно судить о недостаточности памяти для СУБД, – время жизни страницы в памяти – «Page life expectancy» из «sys.dm_os_performance_counters». Если значение меньше 1000 секунд, это указывает на проблемы с памятью. При этом должны быть «Page reads/sec» > 1000 и «Lazy writes/sec» > 20. На самом деле это лишь ориентировочные значения. Но если в этих параметрах значения выше нормы – нужно разбираться в причинах. В идеале время жизни страницы в памяти должно быть более 3000 секунд, а остальные значения близки к нулю. И к тому же «Buffer cache hit ratio» должен быть 0.99 и выше.

Настройки:

• Настройки СУБД:
  • «max degree of parallelism» и «cost threshold for parallelism». Сильное влияние на производительность. Рекомендация 1С: Max DOP = 1. На практике же можно подобрать такое значение «cost threshold for parallelism», когда параллелизм будет помогать. Как проверить что параллельность вредит?
    • косвенно – по ожиданию CXPACKET;
    • по затратам на параллелизм в планах запросов.
  • «max server memory» – СУБД использует всю отведенную ей память. Важно оставить часть памяти для ОС и 1С. Иначе из-за нехватки памяти может тормозить весь сервер.
  • файлы tempdb и баз данных на одном диске. Размещение этих файлов на одном диске существенно нагружает диск. Получить статистику ввода/вывода можно через представление sys.dm_io_virtual_file_stats. Если у какого-то файла задержка (io_stall_read_ms или io_stall_write_ms) больше 3 мс, то с этим надо разбираться. Подробнее о настройке MSSQL можно почитать на ИТС: https://its.1c.ru/db/metod8dev/content/5904/hdoc
• Настройки базы:
  • AUTO_SHRINK – включение этой опции вызывает постоянную очистку базы и нагрузку на диск. 
  • AUTO_UPDATE_STATISTICS_ASYNC – рекомендуется включить вместе с AUTO_UPDATE_STATISTICS = ON. В противном случае перед выполнением запросов возможны тормоза на пересчете статистики. Признаком таких ожиданий служит WAIT_ON_SYNC_STATISTICS_REFRESH.

Запросы и индексы:

• Актуальная статистика – также одна из причин, которые могут вызвать заметное замедление работы. Проверяется через представление «sys.dm_db_stats_properties». Если есть таблицы, у которых процент строк с изменением («modification_counter») больше 20% от общего числа строк («rows»). Главная причина неактуальной статистики – отсутствие регламентных операций по обновлению статистики. Обновление статистики должно быть не реже одного раза в день с полным сканированием. В случае если обновление не успевает выполниться за день, можно обновлять только самые активные таблицы. А раз в неделю все остальные. 
• Индексы. Они также существенно влияют на производительность, но индексы требуются под конкретные запросы, и поэтому поиск начинают с проблемных запросов. Хотя есть и возможность найти недостающие индексы на основании системных представлений. Этот запрос и многие другие можно найти по ссылкам:
  • https://glennsqlperformance.com/resources/ запросы от Glenn Berry.
  • https://github.com/BrentOzarULTD/SQL-Server-First-Responder-Kit – запросы от Brent Ozar. Отдельно можно выделить запрос «sp_Blitz» который проводит общий анализ СУБД.

Мы попытались рассказать лишь о самых частых и вероятных причинах медленной работы. Со многими из них мы столкнулись при работе с обращениями клиентов.

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

В приведенном выше примере на первом этапе казалось, что замена HDD решит проблему. Однако замена HDD на SSD лишь выявила другие проблемы: нехватку процессорных ресурсов и автоматические блокировки.

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

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

1С:Расширенная корпоративная лицензия (1С:РКЛ)

Оформляйте в Инфостарт и получайте качественную поддержку ваших корпоративных 1С-систем с дополнительной выгодой

Узнать о подробнее

Корпоративные решения   Проектный офис   ИНФОСТАРТ Enterprise Актуальные новости, кейсы, новые решения 1С и для 1С, анонсы вебинаров. Присоединяйтесь! Telegram → MAX →