При настройке клиент-серверного варианта работы «1С:Предприятие» системные администраторы часто сталкиваются с неочевидным поведением оборудования и СУБД. Почему процессор с заявленной частотой Turbo Boost в 3.7 ГГц работает медленнее, чем на стабильной частоте 3.4 ГГц? И почему разделение базы данных на несколько файлов, которое так активно рекомендуется для системной базы tempdb, приводит к катастрофическому падению скорости работы обычной пользовательской базы (например, «1С:Управление торговлей»)?
В этой статье мы подробно, по шагам разберем внутренние механизмы работы процессоров Intel, алгоритмы распределения данных в MS SQL Server и выясним причины возникновения этих аномалий. Мы также подготовим пошаговые инструкции по оптимизации сервера, которые помогут вам добиться максимальной производительности вашей системы.
Рассмотрим ситуацию, описанную автором темы: на стабильной частоте 3.4 ГГц при отключенном энергосбережении сервер выдает больше условных единиц («попугаев») производительности, чем при включенном Turbo Boost с пиковой частотой 3.7 ГГц. На первый взгляд это кажется парадоксом, ведь 3.7 ГГц чисто математически больше, чем 3.4 ГГц. Давайте разберем физику этого процесса.
1. Специфика нагрузки 1С (однопоточность операций)
Большинство критически важных бизнес-операций в 1С (проведение документов, расчет себестоимости, формирование сложных отчетов) выполняются последовательно, в один поток. Популярные тесты производительности (включая тест Гилева) оценивают именно скорость работы одиночного процессорного ядра. Следовательно, для 1С критически важна максимальная производительность одного конкретного ядра здесь и сейчас.
2. Как устроен Turbo Boost и почему ему мешают C-States
Технология Intel Turbo Boost работает динамически. Чтобы процессор мог безопасно поднять частоту одного активного ядра до максимальных 3.7 ГГц, не превышая лимиты тепловыделения (TDP), остальные ядра должны простаивать и находиться в глубоких состояниях энергосбережения (так называемых C-States, например, C6 или C7, когда с неактивных ядер практически полностью снимается напряжение).
Если мы отключаем C-States в BIOS, процессор считает, что все ядра условно активны, и блокирует максимальный одноядерный Turbo Boost, переходя на стабильную частоту All-Core Turbo (в нашем примере — 3.4 ГГц). Но почему же производительность при этом возрастает?
3. Проблема микрозадержек (Latency) при переключении контекста
Когда функции энергосбережения активны, операционная система и процессор постоянно пытаются сэкономить электричество. Как только поток выполнения «1С:Предприятия» или SQL Server прерывается хотя бы на долю миллисекунды, операционная система «паркует» ядро или отправляет его в глубокий сон (C-state). При поступлении следующего пакета данных ядро необходимо «разбудить».
Переход ядра из состояния глубокого сна (C6) в рабочее состояние (C0) занимает определенное время (от десятков до сотен микросекунд). База данных и сервер приложений 1С генерируют тысячи мелких запросов в секунду. Постоянное «засыпание» и «пробуждение» ядер процессора создает огромные суммарные задержки (Latency). Процессор физически не успевает использовать пиковую частоту 3.7 ГГц, так как большая часть времени тратится на транзиты между состояниями питания. В итоге стабильная частота 3.4 ГГц без простоев и засыпаний оказывается гораздо эффективнее динамических 3.7 ГГц.
Чтобы заставить сервер работать на максимально возможной стабильной частоте без микрозадержек, выполним следующие шаги:
Выполнив эти настройки, мы устраним «парковку ядер» и задержки на пробуждение процессора. Ядра сервера будут постоянно находиться в состоянии готовности C0 на стабильно высокой частоте.
Теперь проанализируем вторую проблему, описанную автором: чистая база данных «1С:Управление торговлей 11» на SSD, разделенная изначально на два файла данных по 2 Гб, работала с колоссальными задержками (простой документ установки цен открывался почти минуту). После объединения файлов в один проблема полностью исчезла. Почему так произошло?
Автор темы столкнулся с последствиями классической ошибки — слепого переноса рекомендаций по оптимизации системной базы данных tempdb на обычные рабочие (пользовательские) базы данных.
1. Почему делят именно tempdb?
База tempdb в MS SQL Server — это глобальный «черновик», который используется всеми базами данных на сервере для создания временных таблиц, сортировок, хэширования и хранения версий строк. При высокой нагрузке сотни потоков одновременно обращаются к страницам распределения пространства в tempdb. Возникает так называемая конкуренция (contention) за системные страницы распределения (GAM, SGAM, PFS).
Чтобы расшить это узкое горлышко, Microsoft рекомендует разделять базу tempdb на несколько файлов данных одинакового размера (обычно по числу логических ядер процессора, но не более 8). В этом случае SQL Server распределяет обращения к системным страницам параллельно по разным файлам.
2. Почему разделение пользовательской базы 1С на одном SSD вредит производительности?
Для обычной пользовательской базы данных (например, файла .mdf вашей УТ 11) механизмы работы СУБД выглядят совершенно иначе. Когда вы создаете несколько файлов данных (например, один .mdf и один .ndf) и размещаете их на одном и том же физическом SSD-накопителе, вы получаете целый ряд проблем:
Разделять основную базу данных на несколько файлов целесообразно исключительно в двух случаях:
D:\, файл 2 на диске E:\). Это позволит распараллелить физические операции ввода-вывода между разными контроллерами.Вывод: Если ваша база данных работает на одном SSD-накопителе (или одном RAID-массиве), у вас должен быть строго один файл данных (.mdf) и один файл лога транзакций (.ldf). Любое искусственное дробление файлов внутри одного физического диска гарантированно снизит производительность.
Давайте проанализируем структуру файлов вашей базы данных с помощью простого SQL-запроса. Для этого откроем SQL Server Management Studio (SSMS), создадим новый запрос к вашей базе данных и выполним следующий код:
-- Проверка конфигурации файлов базы данных, их размера и шага роста
SELECT
df.name AS LogicalName,
df.physical_name AS PhysicalName,
df.size * 8 / 1024 AS SizeMB,
CASE
WHEN df.is_percent_growth = 1 THEN CAST(df.growth AS VARCHAR) + '%'
ELSE CAST(df.growth * 8 / 1024 AS VARCHAR) + ' MB'
END AS GrowthSetting,
fg.name AS FileGroupName
FROM sys.database_files df
LEFT JOIN sys.filegroups fg ON df.data_space_id = fg.data_space_id;
Если в результате запроса для вашей рабочей базы в строке с типом данных (ROWS) вы видите более одного файла на одном и том же диске (например, base.mdf и base_log.ndf на диске C:\), рекомендуется выполнить консолидацию данных:
.ndf) в основной с помощью операции сжатия файла (Shrink File) с параметром EMPTYFILE.Также обязательно проверим, включена ли мгновенная инициализация файлов на вашем сервере. Выполним следующий запрос:
-- Проверка включения мгновенной инициализации файлов (IFI) в SQL Server
SELECT
servicename,
instant_file_initialization_enabled
FROM sys.dm_server_services
WHERE servicename LIKE 'SQL Server%';
Если значение в колонке instant_file_initialization_enabled равно N, обязательно включите эту функцию. Для этого добавьте учетную запись, от имени которой запущена служба SQL Server, в локальную политику безопасности Windows «Выполнение задач по обслуживанию томов» (Perform volume maintenance tasks) и перезапустите службу SQL Server. Это заставит базу данных мгновенно расширять файлы без задержек на обнуление диска.