Настройка BIOS для серверов под базы данных без риска

Зачем трогать BIOS под СУБД и какие есть риски

BIOS влияет на то, как сервер распределяет нагрузку между процессорами и памятью, как он уходит в энергосбережение и как быстро возвращается к работе. Для базы данных это часто про предсказуемость: одинаковая нагрузка должна давать одинаковые цифры. Настройка BIOS под СУБД обычно оправдана, когда вы упираетесь в задержки или видите «неровную» производительность, а ОС и сама база уже настроены адекватно.

BIOS часто проявляется по таким симптомам: запросы то быстрые, то внезапно медленные при одинаковой нагрузке; просадки TPS (или QPS) без понятной причины; редкие пики времени отклика ночью или в моменты частичного простоя; разные результаты одинаковых тестов в разное время; «прыгающая» загрузка CPU (то 40%, то 90%) при похожем потоке.

Универсально «правильной» конфигурации нет. OLTP (короткие транзакции и много параллельности) обычно сильнее чувствителен к задержкам и планированию потоков. Здесь важны NUMA, SMT (Hyper-Threading) и C-states. Аналитика и пакетные задачи чаще выигрывают от максимальной пропускной способности и долгой ровной загрузки CPU, и те же параметры могут дать обратный эффект.

Риски реальны, даже если изменения выглядят безобидно. Можно получить редкие сбои, которые проявятся через неделю. Или «скрытую деградацию»: средняя скорость выросла, а хвостовые задержки (p95/p99) стали хуже. Еще одна типичная проблема - сложность отката, если вы поменяли сразу несколько пунктов и не зафиксировали исходное состояние.

Успех здесь - не рекорд в одном прогоне. Нужны стабильность и повторяемость: одинаковая нагрузка дает одинаковые метрики, а эффект оценивается не только средним TPS, но и задержками, поведением фоновых операций и тем, как система ведет себя после простоя.

Подготовка: базовая линия и план безопасного отката

Перед тем как менять NUMA, SMT или C-states, зафиксируйте отправную точку. Иначе вы не поймете, стало ли лучше, и не сможете быстро вернуться к рабочей конфигурации.

Сначала соберите исходные данные по железу и прошивкам. Это важно: одинаковые настройки могут вести себя по-разному на разных поколениях CPU и версиях микрокода.

Минимум, который стоит записать в один документ:

• модель сервера и состав: CPU (сокеты, ядра), объем и схема памяти (каналы, частоты), диски/NVMe, сетевые карты;
• версии BIOS/UEFI, BMC, микрокода CPU (если видно), режим загрузки (UEFI/Legacy);
• роль сервера и тип нагрузки СУБД (OLTP/аналитика), ограничения (SLA по задержке, окно простоя);
• текущие настройки BIOS (фото экрана или экспорт профиля, если поддерживается);
• параметры ОС, которые могут влиять на тест: профиль питания, настройки планировщика, huge pages, pinning/affinity, версия ядра и драйверов.

Дальше запланируйте окно работ. Любая правка BIOS требует перезагрузки, а иногда и полного выключения питания, чтобы настройки применились корректно. Сразу заложите время на 2-3 перезагрузки и проверку.

План отката должен быть готов до первого изменения. Лучший вариант - сохранить текущий профиль BIOS в файл или слот профиля. Если такой функции нет, сделайте полный набор скриншотов нужных разделов и отдельно выпишите значения, которые меняете.

Заранее определите критерии остановки, чтобы не довести систему до нестабильности:

• ошибки в системных логах (Machine Check, WHEA), внезапные перезагрузки, рост corrected errors;
• зависания, таймауты I/O, аномальные паузы в ответах СУБД;
• ухудшение ключевых метрик больше оговоренного порога (например, p95 задержки);
• невозможность повторить результат в двух прогонах подряд.

Если что-то из этого появляется, откатывайтесь на базовый профиль и разбирайте причину отдельно, не продолжая эксперимент «на удачу».

Методика тестирования шаг за шагом без риска для продакшена

Аккуратная настройка BIOS начинается не с параметров, а с цели. Выберите один показатель, который важен именно вашей базе: снизить p95 задержки, поднять TPS или убрать редкие длинные паузы.

Дальше снимите базовую линию. Запустите одну и ту же нагрузку с той же длительностью и тем же объемом данных, на полностью одинаковых настройках ОС и СУБД. Если тестируете на стенде, максимально приблизьте железо и прошивки к продакшену.

Меняйте один параметр BIOS за раз и обязательно перезагружайте сервер. Так вы отделяете влияние NUMA, SMT (Hyper-Threading) или C-states от случайных факторов. Если очень хочется поменять несколько пунктов, сохраните это как отдельный профиль и отложите на потом - сначала разберите вклад каждого изменения.

Чтобы не поймать ложный эффект, повторяйте один и тот же прогон 3-5 раз и смотрите на медиану и разброс, а не на «лучший» результат. Если p95 то падает, то растет, чаще всего проблема в нестабильной среде теста, а не в пользе настройки.

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

Фиксируйте контекст каждого теста, иначе сравнения будут нечестными:

• версии BIOS/UEFI, микрокода CPU, прошивок RAID/NVMe, BMC;
• конкретное значение параметра (например, SMT: On/Off, C-states: Enabled/Disabled);
• профиль питания, частоты, температурные условия, обороты вентиляторов;
• версии ОС и СУБД, ключевые параметры (пулы памяти, параллелизм);
• метрики: TPS, p50/p95/p99 latency, CPU steal/iowait, промахи кэша (если есть).

Финальный шаг - длинный прогон на стабильность. Когда выбрали лучший профиль, прогоните нагрузку часами, а лучше сутки: проверьте отсутствие ошибок в логах, WHEA, деградации производительности и перегрева. В продакшене применяйте изменения только в окно работ и с понятным планом отката (сохраненный профиль BIOS и проверенный путь возврата).

NUMA: что тестировать и как понять, что стало лучше

NUMA простыми словами - это когда у сервера не одна общая память на все ядра, а несколько «островков» памяти рядом со своими процессорными ядрами. Доступ к «своей» памяти обычно быстрее, чем к памяти другого узла. Для СУБД это важно: база постоянно читает и пишет в RAM, и лишние микрозадержки на удаленной памяти быстро превращаются в потерю производительности.

Что имеет смысл тестировать в BIOS, зависит от платформы, но чаще встречаются:

• NUMA включено или выключено (иногда это называется Node Interleaving: Enabled делает систему более похожей на UMA);
• режим распределения памяти между узлами (интерливинг, локальная привязка, auto);
• число видимых NUMA-узлов (редко, но иногда можно объединять или делить);
• настройки топологии CPU (например, NPS на некоторых платформах).

NUMA чаще дает эффект на многоядерных системах с большим объемом RAM и высокой конкуренцией потоков: когда одновременно идут фоновые процессы СУБД, отчетные запросы и репликация. На двухсокетном сервере под OLTP база может чаще промахиваться по кэшу и «гулять» по удаленной памяти, если планировщик ОС и политика памяти не совпадают с реальной топологией.

Тестируйте так же осторожно: один параметр - один прогон (и несколько повторов), сравнение не только среднего времени, но и хвостов задержек.

Чтобы понять, что стало лучше, смотрите на три вещи: задержки (p95/p99), пропускную способность (транзакции или запросы в секунду) и долю удаленной памяти. В ОС обычно можно увидеть, сколько памяти и какие потоки оказались на каждом NUMA-узле, и растет ли «remote» под нагрузкой.

Фиксируйте результаты в журнале, чтобы потом можно было повторить:

• модель сервера и версия BIOS;
• число NUMA-узлов и включен ли интерливинг;
• настройки привязки процессов и памяти на уровне ОС (если применяете);
• ключевые метрики СУБД и ОС до и после;
• точное описание теста: длительность, объем данных, параллельность.

SMT (Hyper-Threading): когда выключать и как проверять эффект

SMT (Hyper-Threading) добавляет логические потоки на каждое физическое ядро. Это часто повышает общую загрузку CPU, но не всегда ускоряет реальные запросы СУБД. Важно оценивать не среднюю скорость, а задержки и предсказуемость.

SMT чаще мешает, когда база чувствительна к задержкам и упирается в CPU: растет конкуренция за кэши и исполнительные блоки, появляются лишние контекстные переключения, иногда усиливается нагрев и включается троттлинг. Типичная картина - стабильные 80-95% CPU и одновременное ухудшение p95/p99 latency.

SMT чаще помогает при смешанной нагрузке, когда много ожидания I/O или много параллельных легких запросов. Тогда логические потоки заполняют «пустоты» в работе ядра, и throughput растет без заметной потери по хвостовым задержкам.

Проверяйте эффект парным тестом: SMT On против SMT Off на одном и том же наборе данных и одной версии ПО. Не «подгоняйте» результат - держите одинаковое число активных сессий и одинаковые лимиты подключений, иначе вы просто меняете давление на CPU.

Практичный порядок теста:

• сделайте короткий прогрев, затем несколько одинаковых прогонов (минимум 3) для каждого режима;
• фиксируйте частоты CPU и температуры, чтобы исключить скрытый троттлинг;
• не меняйте параллельно NUMA, план питания ОС и параметры СУБД.

Смотрите не только на TPS/QPS, но и на p95/p99 latency по ключевым запросам, CPU utilization по ядрам и рост context switches, стабильность частоты (Turbo может вести себя по-разному).

Пример: на сервере уровня GSE S200 под OLTP иногда выигрывает SMT Off, если важны ровные задержки, а под отчетную нагрузку с параллельными сканами может оказаться лучше SMT On. Решение принимайте по повторяемым замерам, а не по одному «удачному» прогону.

C-states, Turbo и лимиты мощности: задержки против экономии

C-states отвечают за то, насколько глубоко ядра и весь процессор могут «засыпать» в простое. Для СУБД это иногда оборачивается микрозадержками: короткий запрос приходит, ядро просыпается, и время ответа слегка плавает. На длинных пакетных задачах (ETL, бэкапы, отчеты) эффект может быть незаметен, а на OLTP с большим числом коротких транзакций колебания latency часто видно.

Обычно имеет смысл сравнить не десятки опций, а 2-3 понятных режима на одинаковой нагрузке. Чаще всего трогают:

• C-states: включено против отключено;
• Package C-states (сон всего сокета): ограничить до «легких» состояний или отключить;
• энергопрофиль платформы (Performance/Balanced), если он есть в BIOS.

Turbo повышает частоту на части ядер, но упирается в температуру и лимиты мощности (PL1/PL2, иногда power limits). На тесте «все ядра 100%» Turbo может быстро «сдуться» из-за нагрева. Тогда результаты зависят не от СУБД, а от того, поймал ли сервер троттлинг. Поэтому важны не только цифры, но и стабильность частоты.

Как тестировать без сюрпризов

Делайте один шаг за раз и гоняйте тест достаточно долго, чтобы система вышла на тепловое равновесие (часто 30-60 минут, для уверенности - дольше). Держите одинаковые условия: температура в стойке, режим вентиляторов, версия микрокода/BIOS, один и тот же профиль нагрузки.

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

Что фиксировать

Чтобы потом не спорить «стало ли лучше», записывайте:

• p95/p99 latency и число таймаутов (если есть);
• частоты CPU под нагрузкой и их просадки;
• температуру CPU и скорость вентиляторов;
• признаки троттлинга (thermal/power);
• потребление (если доступно), чтобы понимать цену прироста.

Если при отключении C-states p99 улучшается, но температура растет и появляется троттлинг, итог на длинной дистанции может стать хуже. Хорошая настройка - быстрая и предсказуемая изо дня в день.

Память и RAS в BIOS: настройки, которые лучше трогать осторожно

Для баз данных важны не только «быстрые цифры», но и стабильность. Память в BIOS - зона, где небольшой выигрыш легко купить ценой редких ошибок, странных «подвисаний» или падений производительности под нагрузкой.

Память: что может повлиять на задержки и стабильность

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

Имеет смысл тестировать только изменения, которые легко объяснить и откатить:

• частота памяти (Auto против фиксированного значения, поддерживаемого CPU и модулями);
• профили памяти (если доступны) - разумнее начинать со штатных JEDEC, а не с агрессивных профилей;
• интерливинг каналов и рангов (Channel/Rank Interleaving) - часто помогает выровнять доступ;
• режимы, влияющие на задержку (например, «performance»/«balanced» для контроллера памяти, если есть).

Если BIOS показывает тайминги, фиксируйте их, но не подкручивайте вручную без причины. Автонастройки иногда выбирают значения «на грани», и ручные правки усложняют откат.

RAS: где надежность важнее скорости

RAS-настройки (Reliability, Availability, Serviceability) нужны, чтобы система годами работала и исправляла одиночные ошибки. Для СУБД это часто ценнее, чем небольшой прирост.

Осторожно относитесь к:

• ECC режимам (обычно лучше оставить включенным);
• memory scrubbing (patrol/background scrubbing): снижает риск накопления ошибок, но может добавить небольшой постоянный фон нагрузки;
• порогам и политике исправления ошибок (если доступны): агрессивные режимы чаще «лечат», но и чаще сигнализируют о проблеме модулей.

Простой пример: на сервере под PostgreSQL вы подняли частоту памяти, получили +3% в синтетике, но через неделю в журнале появились исправленные ECC-ошибки. Формально система работает, но риск уже вырос: лучше вернуть безопасный режим и проверить модули.

Как тестировать без риска и что фиксировать

Сначала сравните задержки и пропускную способность памяти, затем сделайте длительную проверку стабильности под нагрузкой СУБД (не в продакшене) - минимум несколько часов, лучше сутки.

В журнал запишите:

• модель сервера, версия BIOS, состав модулей памяти;
• частоту/режим памяти и интерливинг;
• все RAS параметры, которые меняли;
• метрики задержек/пропускной способности и результаты нагрузочных тестов;
• события коррекции ошибок (ECC corrected/uncorrected) и их частоту.

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

PCIe, сетевые и NVMe устройства: что в BIOS может влиять на I/O

Даже если CPU и память настроены идеально, узким местом для СУБД часто становится ввод-вывод: диски, сеть, контроллеры и то, как они общаются с процессором по PCIe. В BIOS есть несколько пунктов, которые могут менять задержки и стабильность I/O.

PCIe и сетевые функции

Первое, что имеет смысл проверить, - режим PCIe. На многих платах Auto работает нормально, но иногда фиксированное значение (например, конкретное поколение PCIe) убирает редкие проблемы согласования линии и делает латентность стабильнее. Если видите странные просадки, протестируйте оба варианта.

Также обращайте внимание на опции, которые нужны не всем:

• SR-IOV - актуально, если сеть или сторидж пробрасываются в виртуальные машины или используются специальные сетевые функции.
• IOMMU - нужно для виртуализации и изоляции устройств, но иногда добавляет небольшой оверхед и меняет задержки.

Если сервер работает без виртуализации и без проброса устройств, эти пункты лучше не трогать без причины.

NVMe и энергосбережение

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

Тестируйте в два этапа: сначала отдельной I/O нагрузкой (чтение/запись, маленькие и большие блоки), затем тем же профилем на фоне типовой нагрузки СУБД.

Чтобы результаты были воспроизводимыми, фиксируйте:

• версии BIOS и прошивок RAID/HBA/NVMe и сетевых адаптеров;
• согласованную скорость и ширину PCIe линии (Gen и x8/x16);
• включенные режимы SR-IOV/IOMMU и связанные опции;
• latency по дискам: среднее и p95/p99, плюс число IOPS при одинаковой нагрузке;
• условия теста: та же схема питания, те же версии драйверов и одна и та же конфигурация СУБД.

Как фиксировать результаты: метрики, журнал и повторяемость

Чтобы настройка BIOS для серверов под базы данных не превратилась в гадание, заранее решите, что именно вы сравниваете. Один параметр за раз, одинаковая нагрузка, одинаковые данные, одинаковая длительность. Тогда даже небольшой эффект будет виден, а случайные колебания не собьют с толку.

Набор метрик, который стоит собирать всегда

Выберите несколько метрик, которые отражают и скорость, и стабильность. Обычно достаточно такого набора:

• TPS или общий throughput;
• p95 и p99 latency;
• CPU: загрузка, частота, миграции по ядрам, контекстные переключения;
• память и I/O: page faults, чтение/запись, очередь диска;
• температуры и лимиты мощности (признаки троттлинга).

TPS может вырасти, а p99 станет хуже, и для СУБД это часто плохая сделка.

Простой журнал, который реально вести

Лучше всего работает одна таблица, куда вы заносите каждый прогон. Минимальный набор столбцов:

• дата и время, окно теста;
• модель сервера, версия BIOS, важные версии прошивок (если менялись);
• измененный параметр BIOS и его значение (только один за раз);
• описание окружения: версия СУБД, конфиг, размер данных, число клиентов, длительность;
• результаты 3-5 прогонов (медиана и разброс) и заметки об аномалиях.

Пример: вы тестируете SMT. Делаете 5 прогонов по 20 минут, после каждого прогреваете систему одинаково. Если один прогон «провалился» из-за фоновой задачи, отметьте это и не делайте вывод по одной цифре.

Отдельно фиксируйте признаки риска: перезагрузки, ошибки WHEA, просадки частоты, перегрев, неожиданные пики p99. Если такое появилось после изменения NUMA, C-states или SMT, это тоже результат, даже если TPS вырос.

Главное правило повторяемости: сравнивайте только сопоставимые тесты. Те же данные, тот же профиль нагрузки, тот же интервал времени и минимум внешних изменений в системе.

Частые ошибки, из-за которых настройка BIOS дает ложные выводы

Ложные выводы чаще всего появляются, когда BIOS меняют как набор «улучшений», а не как проверку гипотез. В итоге кажется, что стало быстрее или стабильнее, но повторить результат уже нельзя.

Типичные промахи:

• меняют сразу несколько пунктов (например, NUMA-режим, SMT и C-states за один заход). Если производительность сдвинулась, вы не узнаете, что именно сработало, и не сможете безопасно вернуть часть настроек;
• сравнивают тесты в разных условиях: другие данные, другой размер буфера, разная прогретость кэшей ОС и СУБД, разные фоновые задачи. На коротких прогонах «везение» с кэшем легко рисует красивую цифру;
• смотрят только среднее время или общий TPS и игнорируют хвосты. Для базы данных важнее p95/p99, потому что редкие пики задержки бьют по пользователям и очередям запросов;
• тестируют Turbo, лимиты мощности и энергосбережение, но не смотрят на температуру и троттлинг. Сервер может показать быстрый старт, а через 10-20 минут уйти в ограничения, и результаты «поплывут»;
• делают вывод по короткому бенчмарку и не проверяют длительным прогоном. Для SMT и C-states важно увидеть поведение под устойчивой нагрузкой, с ночным окном, бэкапом или типичными фоновыми джобами.

Отдельная ловушка - разные BIOS-профили на одинаковых серверах в одном кластере. Даже одна «забытая» настройка (например, SMT включен на одной ноде и выключен на другой) усложняет сравнение и может давать нестабильные роли в репликации или разные задержки. Договоритесь о едином профиле и фиксируйте версию прошивки и полный набор параметров, особенно если это парк однотипных серверов.

И всегда проверяйте, что откат действительно выполнен. Иногда профиль «сохранен», но часть параметров остается в Auto, и вы тестируете уже не то, что думаете.

Короткий чеклист и следующие шаги после выбора настроек

Когда вы уже поняли, какие изменения в BIOS реально помогают СУБД, закрепите результат так, чтобы не потерять стабильность при следующем обновлении прошивки или замене железа.

Быстрый чеклист перед тестами и во время них

• сохраните базовый профиль BIOS (фото экранов или экспорт профиля, если доступен) и договоритесь об окне перезагрузок;
• подготовьте план отката: что возвращаем, в какой последовательности, кто отвечает, какой максимум простоя допустим;
• меняйте только один параметр за раз (NUMA, SMT/Hyper-Threading, C-states и т.д.), иначе вы не поймете причину эффекта;
• делайте 3-5 повторов одного и того же теста и фиксируйте p95/p99 задержки, а не только среднее;
• параллельно смотрите температуру, частоты CPU и любые признаки ошибок (падения, таймауты, пики латентности).

После коротких прогонов выделите время на проверку стабильности. Практичное правило: если настройка дала прирост на 2-3% в синтетике, но добавила редкие хвосты по p99 в реальной нагрузке, это почти всегда плохой обмен.

Что делать после выбора «лучшего» профиля

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

• сделайте финальный длительный прогон под типичной нагрузкой (ночь или выходные) и проверьте логи на аппаратные ошибки и исправления памяти;
• зафиксируйте итоговый профиль как стандарт: версия BIOS/прошивок, список включенных/выключенных опций, условия теста, итоговые метрики;
• опишите границы применимости: для каких баз и сценариев профиль подходит (например, OLTP с чувствительностью к задержкам), а где нужен другой;
• включите профиль в процедуру изменений: обновление BIOS, замена CPU/памяти, перенос в другую стойку - все это повод перепроверить ключевые метрики;
• если серверов много, стандартизируйте профиль по моделям.

Если вы используете серверы GSE S200 Series или планируете обновление парка, удобно один раз согласовать базовый профиль и порядок проверки с инженерами GSE.kz (gse.kz), а затем поддерживать единые настройки при обновлениях прошивок и замене компонентов.

Если внутри команды нет времени на методичные прогоны, нормальный вариант - подключить системного интегратора, который подберет профиль под конкретную СУБД и реальную нагрузку, а не «среднюю по больнице»."}