Каждый системный администратор и специалист по оптимизации систем на базе «1С:Предприятие» рано или поздно сталкивается с удивительным парадоксом. Пользователи жалуются на то, что программа работает крайне медленно: проведение документов занимает минуты, а построение сложных отчетов тянется часами. При этом графики производительности сервера показывают полную идиллию: загрузка процессора колеблется в пределах 5–15%, очереди к дискам отсутствуют, а оперативная память занята лишь наполовину.
Возникает логичный вопрос: поможет ли покупка нового, более мощного сервера, если текущее железо практически простаивает? Давайте подробно разберем эту проблему, выясним скрытые причины медленной работы и найдем оптимальные пути решения.
Для того чтобы понять, почему простаивает процессор, проанализируем архитектуру выполнения кода в платформе «1С:Предприятие 8». Большинство тяжелых бизнес-операций (проведение документов, закрытие месяца, расчет себестоимости, выполнение сложных алгоритмов на встроенном языке) выполняются строго последовательно — в один поток.
Рассмотрим, как это выглядит на практике. Представим, что на нашем сервере установлен современный процессор, имеющий 16 физических ядер (с поддержкой Hyper-Threading это дает 32 виртуальных ядра или потока). Когда один пользователь запускает тяжелую процедуру перепроведения документов, рабочий процесс 1С rphost загружает ровно одно ядро процессора на 100%. При этом в Диспетчере задач общая загрузка процессора будет отображаться на уровне всего 3% (1 ядро из 32 доступных). Очередей к процессору не возникнет, однако пользователь будет испытывать сильные тормоза, упираясь в технологический предел производительности одного ядра.
Если мы заменим этот сервер на другой, где ядер будет не 16, а 32, но с более низкой тактовой частотой, производительность 1С станет еще хуже! В данном случае «более мощный сервер» должен означать процессор не с большим количеством ядер, а с **максимальной тактовой частотой на одно ядро (ГГц)** и высокой производительностью на такт (IPC). Замена процессора с частотой 2.4 ГГц на процессор с частотой 4.2 ГГц даст мгновенный и пропорциональный прирост скорости работы single-thread операций, хотя графики общей загрузки процессора в операционной системе останутся на тех же 3%.
Работа пользователей в 1С носит импульсный характер: долгая пауза (заполнение реквизитов на экране), затем резкое нажатие кнопки «Провести», требующее мгновенной стопроцентной отдачи от сервера, и снова пауза. По умолчанию в BIOS сервера и в операционной системе включены агрессивные функции энергосбережения (состояния C-States и P-States).
Когда сервер простаивает, процессор сбрасывает свою частоту до минимума (например, до 1.2 ГГц при номинале 3.6 ГГц). Из-за того, что транзакция в 1С обычно длится доли секунды или секунды, процессор физически не успевает выйти из режима энергосбережения и поднять частоту до максимума. Операция выполняется на минимальной частоте, а счетчики загрузки показывают, что сервер свободен.
Для исправления этой ситуации переведем систему в режим максимальной производительности:
В эпоху твердотельных накопителей (SSD и NVMe) классическая длина очереди к дискам перестала быть главным показателем проблем. Однако медленная работа 1С часто кроется именно в дисковой подсистеме, даже если она загружена на 1%.
База данных 1С генерирует гигантское количество мелких, последовательных операций записи в таблицы транзакций СУБД. В этом сценарии глубина очереди запросов к диску почти всегда равна единице (Queue Depth = 1). Пиковая скорость последовательного чтения (например, 3500 МБ/с, заявленная производителем SSD) здесь абсолютно не важна. На передний план выходит **латентность (время отклика)** диска при случайной записи блоками по 4КБ.
Если в сервере установлены медленные диски без аппаратного RAID-контроллера с кэшем записи, или используются бытовые SSD вместо корпоративных накопителей, задержка записи каждой мелкой транзакции будет тормозить общую работу СУБД. Нам поможет установка специализированных корпоративных NVMe-накопителей с ультранизким временем отклика (микросекунды), что кардинально ускорит запись логов транзакций.
Очереди к ресурсам могут возникать не только на уровне физического железа, но и внутри самой СУБД (MS SQL Server или PostgreSQL). 1С активно использует временные таблицы, которые создаются и уничтожаются с огромной скоростью в системной базе данных TempDB.
При высокой интенсивности работы пользователей СУБД начинает испытывать задержки при выделении страниц памяти под временные таблицы (конфликты распределения страниц PFS и SGAM). Операционная система при этом не фиксирует очереди к дискам, так как все происходит в оперативной памяти SQL-сервера. Но транзакции 1С начинают выстраиваться в очередь ожидания внутри самого SQL-движка.
Выполним рекомендации по оптимизации СУБД:
TempDB на несколько файлов данных равного размера. Рекомендуется создавать количество файлов, равное числу логических ядер процессора, но обычно не более 8 файлов.rphost.lpc:. Это позволит обмениваться данными напрямую через ОЗУ, минуя виртуальный сетевой стек операционной системы.Если в вашем сервере установлено два или более физических процессора, в системе активируется архитектура NUMA (Non-Uniform Memory Access). Оперативная память физически разделена и привязана к конкретным процессорным сокетам. Если процесс 1С rphost запущен на первом процессоре, а СУБД или часть данных в ОЗУ находятся на шине второго процессора, возникает задержка на обращение через межпроцессорную шину UPI/QPI.
Внешне это выглядит как медленная работа 1С при околонулевой загрузке дисков и процессора. В данном случае более мощный двухпроцессорный сервер без правильной настройки NUMA может работать медленнее, чем простой однопроцессорный сервер с высокой частотой. Нам поможет тонкая настройка распределения рабочих процессов по NUMA-узлам (например, использование Affinity Mask в SQL Server и запуск нескольких процессов rphost с привязкой к ядрам).
Также проанализируем сетевую инфраструктуру. Любые микросекундные задержки в сетевых адаптерах, некорректная маршрутизация в подсетях или использование IPv6 могут замедлить обмен пакетами между сервером 1С и базой данных. Убедимся, что сетевые карты работают в режиме максимальной производительности, а функции энергосбережения сетевого адаптера отключены.
Рассмотрим важный нюанс лицензирования 1С. Лицензия уровня «1С:Предприятие 8 Сервер ПРОФ» имеет жесткое ограничение: один рабочий процесс сервера 1С может использовать не более 12 ядер процессора. Если вы купили мощный сервер с 32 или 64 ядрами, платформа 1С просто проигнорирует «лишние» ядра. В результате общая загрузка процессора в ОС будет показывать низкие значения (ведь простаивает большая часть процессора), но используемые 12 ядер будут перегружены. В данном случае решением станет переход на лицензию уровня КОРП или ручная настройка нескольких рабочих процессов в кластере 1С.
Мы выяснили, что низкие показатели загрузки процессора и жестких дисков — это опасная иллюзия. Она скрывает под собой неэффективную работу одного потока, неоптимальные настройки энергосбережения, скрытые ожидания в памяти СУБД и задержки сетевого стека. Более мощный сервер с упором на высокую частоту ядра процесора, быструю дисковую подсистему с ультранизкой латентностью и грамотно настроенное ПО гарантированно даст колоссальное преимущество по производительности 1С.