При развертывании клиент-серверной версии платформы «1С:Предприятие» системные администраторы часто сталкиваются с парадоксальной ситуацией. На мощном современном оборудовании (например, многоядерных процессорах с высокой тактовой частотой и производительных NVMe-накопителях) синтетический тест производительности TPC-1C (известный как тест Гилёва) показывает неожиданно скромные результаты для Microsoft SQL Server, в то время как PostgreSQL «из коробки» выдает значительно более высокие показатели. Например, на процессоре Intel Core i7-9700K с NVMe SSD показатели MS SQL Server могут составлять всего 34 балла («попугая»), тогда как PostgreSQL демонстрирует 47 баллов, а файловый режим работы — более 100.
В этой статье мы подробно разберем причины такого поведения систем управления базами данных, выясним, почему синтетический тест не всегда отражает реальную скорость работы пользователей, и рассмотрим пошаговые инструкции по оптимизации MS SQL Server, операционной системы и BIOS для достижения максимальной производительности.
Прежде чем приступать к изменению системных настроек, проанализируем, почему возникает столь существенная разница в баллах между СУБД. Главный секрет кроется в механизмах подтверждения записи транзакций на диск.
Тест производительности Гилёва является жестко однопоточным. Он выполняет огромное количество последовательных мелких транзакций (записей, изменений и удалений) в одну таблицу. При этом общая оценка напрямую зависит от задержки (latency) дисковой подсистемы при записи лога транзакций.
По умолчанию MS SQL Server работает в режиме полной долговечности (FULL DURABILITY). Это означает, что при каждом коммите (завершении транзакции) СУБД приостанавливает выполнение потока и ожидает физического подтверждения от контроллера SSD о том, что запись в журнал транзакций (файл .ldf) успешно завершена. Даже самые быстрые NVMe-накопители упираются в физические ограничения контроллера при обработке сотен тысяч синхронных микрозапросов в секунду.
Специализированные сборки PostgreSQL (например, Postgres Pro для 1С) по умолчанию оптимизированы под логику работы платформы. В их конфигурационных файлах часто активирована асинхронная запись транзакций (параметр synchronous_commit = off или local). СУБД подтверждает платформе «1С:Предприятие» успешность транзакции еще до того, как данные физически сброшены из кэша оперативной памяти на диск. Это дает колоссальное преимущество в синтетических однопоточных тестах.
Для того чтобы уравнять условия тестирования и существенно поднять производительность MS SQL Server в однопоточных операциях записи, мы можем включить механизм отложенной фиксации транзакций (Delayed Durability). Рассмотрим, как это сделать с помощью выполнения SQL-скрипта:
USE [master];
GO
ALTER DATABASE [Имя_Вашей_Базы_1С] SET DELAYED_DURABILITY = FORCED;
GO
Важное предупреждение: Принудительное включение режима DELAYED_DURABILITY = FORCED несет в себе минимальный риск потери данных последних транзакций (объемом до 60 Кб), находившихся в буфере СУБД в момент внезапного аварийного отключения питания сервера (BSOD или отключение электричества при отсутствии ИБП). Однако для тестовых баз, баз разработки, а также систем с надежными ИБП и дублированием питания этот режим позволяет поднять скорость записи в разы.
Реальный опыт эксплуатации показывает, что при обычном перепроведении документов за длительный период разница между СУБД сглаживается. В реальных многопользовательских сценариях MS SQL Server за счет более зрелого оптимизатора запросов и эффективного кэширования планов выполнения часто показывает паритет или даже превосходит PostgreSQL, несмотря на разницу в синтетических «попугаях».
Вторая важнейшая причина деградации производительности в однопоточном режиме — поведение процессора под управлением операционной системы. Современные процессоры обладают агрессивными технологиями энергосбережения, которые конфликтуют с логикой работы высокопроизводительных СУБД.
Рассмотрим детально, что происходит во время теста. Однопоточный тест нагружает ровно одно ядро процессора. Планировщик задач Windows Server из соображений равномерного распределения тепла и износа начинает постоянно перекидывать этот единственный активный поток с одного ядра процессора на другое (ядерная миграция). При этом незадействованные ядра процессора находятся в глубоких режимах энергосбережения (C-States, начиная с C1E до C6/C7).
В момент переноса потока новое ядро должно мгновенно «проснуться», поднять частоту до максимальной (Turbo Boost) и принять задачу. Этот процесс занимает микросекунды, но при частоте выполнения транзакций в десятки тысяч в секунду эти микросекунды складываются в огромные задержки. Процессор физически не успевает удерживать стабильно высокую частоту на одном ядре.
Чтобы решить эту проблему, выполним комплексную настройку электропитания:
Maximum Performance (Максимальная производительность). Также следует полностью отключить поддержку состояний энергосбережения процессора C-States (или ограничить их только состоянием C0/C1). Это заставит все ядра процессора постоянно работать на базовой частоте или частоте Turbo Boost без ухода в спящий режим.Откроем файл конфигурации загрузчика:
nano /etc/default/grub
Найдем строку GRUB_CMDLINE_LINUX_DEFAULT и добавим в ее конец параметры отключения энергосбережения процессоров Intel:
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_idle.max_cstate=0 processor.max_cstate=1"
Обновим конфигурацию загрузчика и перезагрузим операционную систему:
update-grub
reboot
После перезагрузки процессор перестанет сбрасывать частоты при отсутствии многопоточной нагрузки, что сразу даст прирост производительности как в тестах, так и в реальной работе 1С.
Одной из частых ошибок администраторов является слепое отключение параллелизма в MS SQL Server. Существует популярная рекомендация устанавливать параметр Max Degree of Parallelism (максимальная степень параллелизма, или MaxDOP) в значение 1. Это делается для того, чтобы тяжелые неоптимальные запросы отдельных пользователей не захватывали все ядра процессора, парализуя работу остальных коллег.
Однако установка MaxDOP = 1 полностью лишает СУБД возможности распараллеливать сложные аналитические выборки, тяжелые отчеты и регламентные операции (индексацию, пересчет итогов). Это приводит к тому, что при наличии 16 или 24 ядер сервер утилизирует процессор всего на 5-6%, а пользователи подолгу ждут формирования отчетов.
Рассмотрим сбалансированный подход к настройке параллелизма:
1, установите значение, равное половине физических ядер одного процессора (NUMA-узла), но не более 4 или 8. Например, для 8-ядерного процессора i7-9700K оптимальным выбором будет значение 4.5. Это заставляет СУБД параллелить даже простейшие быстрые запросы, тратя ресурсы на накладные расходы по созданию и синхронизации потоков. Увеличьте этот параметр до 50 или 80.Таким образом, легкие транзакции (проведение документов, ввод на основании) будут выполняться в один поток мгновенно, а тяжелые регламентные операции и отчеты задействуют выделенное количество ядер, существенно ускоряя работу.
Еще один скрытый фактор, который может снижать производительность дисковых операций и процессора почти в два раза — это активная роль Hyper-V в операционной системе Windows Server.
Выясним причину этого влияния. Когда на физическом сервере устанавливается роль Hyper-V, сама хостовая операционная система (Parent Partition) фактически превращается в виртуальную машину, работающую поверх гипервизора. Планировщик задач и драйверы дисковой системы начинают работать через прослойку виртуализации. Если сервер не планируется использовать под виртуализацию сторонних ресурсов, роль Hyper-V должна быть полностью удалена.
Практический опыт администраторов показывает, что простое отключение служб Hyper-V или полное удаление этой роли на "голом" железе способно поднять показатели однопоточного теста с 34 до 70-74 баллов без изменения аппаратной конфигурации.
Не менее критичным является влияние встроенного антивирусного ПО (например, Windows Defender или сторонних систем безопасности). По умолчанию антивирус пытается в реальном времени сканировать каждый записываемый и считываемый блок файлов баз данных. Настоятельно рекомендуем добавить в исключения антивируса:
sqlservr.exe для MS SQL или postgres.exe для PostgreSQL).rphost.exe, rmngr.exe)..mdf, .ldf, .ndf, а также папки с данными табличных пространств Postgres).Подводя итоги нашего анализа, можно сделать вывод: отставание MS SQL Server от PostgreSQL в синтетических тестах часто вызвано разницей в дефолтных политиках безопасности данных (синхронная запись лога) и чувствительностью однопоточного алгоритма тестирования к настройкам процессора. Для получения максимальной отдачи от связки 1С и СУБД рекомендуем применить следующий чек-лист:
C-States) в BIOS сервера.SET DELAYED_DURABILITY = FORCED.MaxDOP от 4 до 8, Cost Threshold for Parallelism установите на уровень 50-80).Помните, что синтетические тесты — это лишь инструмент первичной диагностики оборудования. Реальным показателем эффективности настройки вашей системы всегда остается время выполнения ключевых бизнес-операций пользователями и скорость проведения регламентных документов в реальной рабочей базе.