Многие технические специалисты сталкиваются с ситуацией, когда дорогостоящий апгрейд дисковой подсистемы (например, переход с SAS-дисков на высокоскоростные NVMe SSD) практически не меняет время выполнения тяжелых операций, таких как расчет зарплаты в 1С:Зарплата и управление персоналом 3.1. Разберем по шагам, почему так происходит, проанализируем влияние различных компонентов сервера и выясним, где на самом деле находится "узкое место" системы.
Первым делом проанализируем соотношение объема базы данных и доступной оперативной памяти. В рассматриваемом случае объем информационной базы составляет всего 7 Гб, в то время как сервер располагает 128 Гб ОЗУ, из которых свободно 80 Гб. Рассмотрим, как это влияет на работу MS SQL Server.
Современные СУБД стремятся максимально кэшировать данные. При первом же обращении к таблицам во время расчета зарплаты SQL Server считывает данные с диска и помещает их в Buffer Pool (оперативную память). Поскольку база полностью (и с огромным запасом) помещается в оперативную память, все последующие операции чтения происходят со скоростью оперативной памяти, которая на порядки выше скорости любого SSD. Таким образом, после прогрева кэша дисковая подсистема практически перестает участвовать в процессе чтения, и разница между SAS и SSD нивелируется.
Выясним, как распределяется нагрузка на процессор при выполнении расчетов. Рассмотрим ключевую особенность платформы 1С:Предприятие: расчеты в типовых конфигурациях (особенно в ЗУП) являются однопоточными. Это означает, что один конкретный расчет выполняется одним сеансом в рамках одного потока одного процесса rphost.
Если мы видим общую загрузку процессора на уровне 50% на многоядерной системе, это часто вводит в заблуждение. Проанализируем ситуацию подробнее: на сервере с включенным Hyper-Threading одно физическое ядро представляется системе как два логических. Когда один поток 1С полностью загружает физическое ядро, диспетчер задач показывает нагрузку 50% на это «ядро» (логический процессор). На самом деле ресурс производительности для этой задачи исчерпан полностью.
В данной ситуации используются процессоры Xeon E5 с частотой 2 Ггц. Для современных конфигураций на платформе 8.3 это крайне низкий показатель. Рассмотрим рекомендации: для комфортной работы и быстрого выполнения расчетов требуются процессоры с высокой частотой на одно ядро (от 3.5 ГГц и выше). Переход на SSD не может компенсировать медленную обработку данных внутри самого ядра процессора.
Рассмотрим, почему пользователи часто сравнивают производительность с версией 2.5 и не видят преимуществ в новой версии. ЗУП 3.1 построена на принципиально иных алгоритмах:
В отличие от версии 2.5, где многие расчеты выполнялись линейно, версия 3.1 создает колоссальную нагрузку на tempdb. Даже если вы перенесли основную базу на SSD, убедитесь, что файлы tempdb и временные файлы профиля пользователя (кэш 1С) также находятся на самом быстром диске. Однако, если процессор не успевает генерировать и обрабатывать эти запросы, скорость диска снова не будет иметь значения.
Проанализируем программную среду. Если сервер 1С и SQL Server развернуты внутри одной виртуальной машины, необходимо проверить настройки взаимодействия:
Во-первых, используем протокол Shared Memory для связи сервера 1С и SQL Server. Это позволит им обмениваться данными напрямую через оперативную память, минуя сетевой стек, что сокращает задержки (latency).
Во-вторых, обратим внимание на настройки электропитания. В настройках BIOS сервера и в самой операционной системе Windows Server должен быть строго установлен режим "High Performance" (Максимальная производительность). В режимах "Balanced" процессор может не успевать динамически поднимать частоту ядра (Turbo Boost) при кратковременных, но интенсивных запросах 1С, что приводит к микрозадержкам, суммирующимся в десятки секунд общего времени расчета.
Разберем конкретные шаги, которые помогут повысить скорость, раз диск уже не является узким местом:
Max Degree of Parallelism (MAXDOP) в значение 1. Это заставит SQL Server не пытаться дробить маленькие запросы на несколько ядер, что в условиях 1С часто работает быстрее из-за отсутствия накладных расходов на сборку результата.tempdb на несколько файлов одинакового размера (по количеству ядер процессора, но обычно не более 8), чтобы исключить конкуренцию за распределение страниц (PFS/GAM)..mdf, .ldf) и каталоги кэша сервера 1С были исключены из сканирования антивирусом. На быстрых SSD NVMe работа антивируса может стать "невидимым" тормозом, потребляющим ресурсы ядра.Подводя итог, отметим: 1200 сотрудников за 80 секунд в ЗУП 3.1 — это неплохой результат для процессора с частотой 2 ГГц. Дальнейшее ускорение возможно только через увеличение производительности "на такт" (IPC) и тактовой частоты центрального процессора, так как дисковая подсистема и объем памяти в данной конфигурации уже не являются ограничивающими факторами.