АйТи Фреш
Главная / Статьи / Серверы и хостинг
Серверы и хостинг

Добавил vCPU на горячую в vSphere 9, а SQL Server 2025 их не взял: почему старый рецепт с Hot Add пора выбросить

Автор: Семёнов Евгений Сергеевич, директор ООО «АйТи-Фреш» · · ~27 мин чтения
Добавил vCPU на горячую в vSphere 9, а SQL Server 2025 их не взял: почему старый рецепт с Hot Add пора выбросить
Иллюстрация к статье «Добавил vCPU на горячую в vSphere 9, а SQL Server 2025 их не взял: почему старый рецепт с Hot Add пора выбросить».

Ночь закрытия месяца, расчёт идёт четвёртый час, все нервничают. Дежурный админ добавляет виртуалке с SQL Server ещё четыре vCPU на горячую — vSphere это умеет, гостевую ОС перезагружать не надо. Диспетчер задач Windows честно рисует новые ядра. А расчёт как шёл, так и идёт. Ниже — где именно рвётся цепочка, что поменялось в SQL Server 2025, какую цену вы платите за галочку «CPU Hot Add» даже когда ей ни разу не пользовались, и как я перенастраиваю SQL-виртуалки у клиентов, чтобы такие ночи не повторялись.

Windows показывает новые ядра, SQL Server — нет. Где рвётся цепочка

Разберём механику по слоям, иначе непонятно, кого винить. Слой первый — гипервизор: ESX действительно умеет подсунуть работающей машине дополнительные vCPU, если у виртуалки включён CPU Hot Add. Слой второй — гостевая Windows: она обрабатывает событие горячего подключения, поднимает новые логические процессоры, и диспетчер задач начинает рисовать лишние графики. Слой третий — SQL Server. Вот здесь всё и останавливается, причём совершенно осознанно со стороны Microsoft.

Документация на этот счёт предельно конкретна: «SQL Server doesn't automatically use CPUs after they are added. This prevents SQL Server from using CPUs that might be added for some other purpose. After adding CPUs, execute the RECONFIGURE statement, so that SQL Server recognizes the new CPUs as available resources». То есть движок намеренно не хватает всё, что появилось в системе, — вдруг эти ядра добавили не ему, а соседнему сервису на той же машине. Пока вы не выполните RECONFIGURE, пользовательские планировщики (schedulers) для новых процессоров работу не берут. В sys.dm_os_schedulers у столбца status для этого случая есть отдельное документированное значение HOT_ADDED — «schedulers were added in response to a hot add CPU event», а ONLINE/OFFLINE там описывает, попадает ли процессор в affinity mask.

-- сколько CPU видит ОС и сколько реально использует движок
SELECT cpu_count, scheduler_count, socket_count, cores_per_socket,
       numa_node_count, softnuma_configuration_desc, affinity_type_desc
FROM sys.dm_os_sys_info;

-- пользовательские планировщики (id < 1048576), включая HOT_ADDED
SELECT parent_node_id, scheduler_id, cpu_id, status, is_online
FROM sys.dm_os_schedulers
WHERE scheduler_id < 1048576
ORDER BY parent_node_id, scheduler_id;

-- узлы SQLOS и их состояние
SELECT node_id, node_state_desc, online_scheduler_count, memory_node_id
FROM sys.dm_os_nodes
WHERE node_state_desc <> N'ONLINE DAC';

Первое, что смотрю в такой ситуации, — расхождение между cpu_count и scheduler_count. Если ОС видит 20, а планировщиков 12 — вы попали ровно в описанный сценарий. Есть и второй нюанс, про который вспоминают редко: max worker threads движок рассчитывает при старте службы, в документации это сформулировано как «SQL Server dynamically configures the max worker threads server configuration option at startup», исходя из числа доступных CPU и архитектуры. RECONFIGURE перечитывает конфигурацию, но службу не перезапускает, поэтому рассчитывать, что пул рабочих потоков волшебно вырастет вслед за ядрами, я бы не стал. Даже удачный hot add даёт вам планировщики, но не гарантирует пропорционального роста параллелизма.

Новые планировщики, которые не берут работу до RECONFIGURE, — не поломка, а штатное поведение, описанное в документации. Но и RECONFIGURE спасёт не всех: сначала проверьте редакцию SQL Server и наличие soft-NUMA, об этом ниже.

SQL Server 2025 объявил Hot Add CPU устаревшим — и это не формальность

В списке устаревших возможностей движка SQL Server 2025 (17.x) ровно два пункта, и один из них — Hot add CPU. Вторым идёт lightweight pooling вместе с режимом фиберов, компания за компанию. Формулировка в руководстве по потокам и задачам жёсткая: «Starting with SQL Server 2025 (17.x), the hot add CPU feature is deprecated, and is planned for removal in a future version of SQL Server. Because of known stability issues, Microsoft recommends that you avoid using this feature in SQL Server administration in any version of SQL Server».

Обратите внимание на «in any version». Это не про то, что в 2025-й что-то специально сломали. Это про то, что Microsoft наконец написала вслух: не пользуйтесь этим нигде — ни на 2019, ни на 2022, ни на 2016. Известные проблемы стабильности были и раньше, просто раньше о них говорили в саппорт-кейсах, а не в публичной документации. Я лет десять слышу от коллег истории про зависшую после hot add инстанцию, которую лечили только перезапуском службы в самый неподходящий момент.

Теперь про панику, точнее про её отсутствие. Deprecated не значит «удалено». В том же документе описан порядок: функция переходит в режим сопровождения, новые изменения в неё не вносят, совместимость с новыми возможностями не допиливают, но выпиливать её из ближайших релизов не планируют — «we strive not to remove a deprecated feature from future releases to make upgrades easier». Если у вас 2019 или 2022 и hot add физически работает, завтра он не отвалится. Меняется другое: закладывать hot add в регламент расширения ресурсов и в инструкцию дежурного админа больше нельзя.

Со стороны VMware сигнал ровно такой же, только резче. В обновлённых технических руководствах по SQL Server на VMware Cloud Foundation 9 (публикация от 12 февраля 2026 года) сказано прямым текстом: «CPU Hot-Add is no longer supported in SQL Server 2025 and you shouldn't enable it on those VMs». У Microsoft — deprecated и «избегайте», у вендора гипервизора — «не включайте вовсе». Расхождение в тоне есть, вывод один, и он совпадает.

Использование устаревших возможностей движка Microsoft предлагает отслеживать объектом производительности Deprecated Features: SELECT * FROM sys.dm_os_performance_counters WHERE object_name LIKE '%SQL%Deprecated Features%'; — но это про T-SQL и настройки экземпляра. Галочку CPU Hot Add в свойствах ВМ оттуда не увидеть, её ищут в vCenter (скрипт ниже).
Добавил vCPU на горячую в vSphere 9, а SQL Server 2025 их не взял: почему старый рецепт с Hot Add пора выбросить — схема
Схема к статье. Открыть схему в полном размере

Требования к Hot Add CPU, которые на практике почти никогда не выполняются

Даже до всякого deprecated у функции был список требований, и его читали примерно никогда. А там всё интересное. Документация перечисляет четыре условия, и провалиться можно на каждом.

Первое, обо что всё разбивается у моих клиентов, — редакция. Компания на 30–50 рабочих мест почти всегда сидит на SQL Server Standard, потому что Enterprise на 16 ядер стоит как половина серверной. А hot add CPU требует именно Enterprise. На Standard функция не поддерживается: документация прямо требует Enterprise, и на моих стендах RECONFIGURE на Standard возвращал управление без ошибки, а число рабочих планировщиков не менялось. Там же, в таблице редакций SQL Server 2025, отдельной строкой стоит «Hot add memory»: Enterprise — Yes, Standard — No. То есть и горячая память мимо.

Второе требование почти неразрешимо, и это моя любимая часть. В документации по soft-NUMA написано буквально: «Hot-add processors aren't supported by soft-NUMA». А теперь смотрим, когда soft-NUMA включается. Начиная с SQL Server 2016, если при старте движок обнаруживает больше восьми физических ядер на NUMA-узел или сокет, он сам, по умолчанию, без всяких трассировочных флагов, нарезает программные узлы — в идеале по восемь ядер, но документация допускает от четырёх до восьми. Никто эту опцию не включал — она включилась сама. Получается замкнутый круг: машина, которой действительно мог бы понадобиться hot add (то есть крупная, с десятками ядер), почти гарантированно работает с автоматическим soft-NUMA, а значит требование документации уже нарушено.

Проверяется это за минуту — одной строкой в SQL и парой запросов к журналу ошибок. Строка «Automatic soft-NUMA was enabled because SQL Server has detected hardware NUMA nodes with greater than 8 physical cores» в errorlog означает, что hot add на этой инстанции вы использовать не должны, независимо от редакции.

-- текущая конфигурация soft-NUMA
SELECT softnuma_configuration, softnuma_configuration_desc
FROM sys.dm_os_sys_info;

-- что движок написал при старте
EXEC xp_readerrorlog 0, 1, N'sockets';
EXEC xp_readerrorlog 0, 1, N'soft-NUMA';

-- выключение автоматического soft-NUMA требует рестарта службы
-- ALTER SERVER CONFIGURATION SET SOFTNUMA OFF;

И заодно посчитайте лимит редакции, прежде чем щедро раздавать ядра. В SQL Server 2025 верхняя планка Standard выросла: «Limited to lesser of 4 sockets or 32 cores», тогда как в SQL Server 2022 и более ранних было 4 сокета или 24 ядра. Буферный пул у Standard теперь 256 ГБ. Если вы годами упирались в потолок 24 ядра, апгрейд до 2025 даёт восемь ядер сверху абсолютно легально — и это заметно дешевле, чем прыжок в Enterprise. Хорошая новость на фоне похорон hot add.

Отдельно про лицензирование, потому что его путают с лимитами редакции. Лимит Standard в виртуальной машине считается не по физическим ядрам хоста: в статье Microsoft о compute capacity limits сказано, что «in a virtualized environment, the compute capacity limit is based on the number of logical processors, not cores» — то есть по числу vCPU, которые видит гость. Лицензируя SQL Server по ядрам на уровне ВМ, вы оплачиваете каждое выданное машине vCPU (с минимумом в четыре лицензии на ядро на ВМ по условиям SQL Server Licensing Guide), и неважно, взял ли движок эти ядра в работу. Добавили четыре vCPU на горячую, а SQL Server их не увидел — лицензии на них всё равно формально нужны. Альтернатива — Enterprise с Software Assurance или подпиской, где при лицензировании всех физических ядер хоста разрешена неограниченная виртуализация, но для компании на пару десятков рабочих мест это обычно избыточно.

Прежде чем добавлять vCPU виртуалке со Standard, посчитайте лимит: движок возьмёт максимум 32 ядра в SQL Server 2025 (24 на версиях до 2025) и не больше четырёх сокетов — при 1 ядре на сокет упрётесь уже в четыре vCPU. Всё сверх лимита вы оплатите лицензиями SQL Server по ядрам, Windows и прикладного ПО, а СУБД это даже не заметит.
Цифры и версии: Требования к Hot Add CPU, которые на практике почти никогда не выполняются — схема
Цифры и версии: Требования к Hot Add CPU, которые на практике почти никогда не выполняются. Открыть схему в полном размере

Главная цена галочки: CPU Hot Add выключает vNUMA

Даже если вы ни разу не добавляли процессоры на горячую, сама включённая галочка уже стоит вам производительности. В документации vSphere 9.0 по управлению ресурсами есть два предложения, которые стоит повесить над рабочим столом: «Virtual NUMA topology is available to virtual machines and is activated by default when the number of virtual CPUs is greater than eight» и следом — «Enabling CPU HotAdd will deactivate virtual NUMA». Там же уточняется, что топология вычисляется при первом включении ВМ по NUMA-топологии хоста и дальше не меняется, пока не изменится число vCPU.

Читаем вместе. По умолчанию виртуалка с более чем восемью vCPU получает виртуальную NUMA-топологию: гость видит несколько узлов, понимает, какие процессоры ближе к какой памяти, и раскладывает потоки соответственно. Включаете CPU Hot Add — vNUMA гаснет. Гость видит один плоский узел со всеми vCPU, а память ему выдаётся как получится, в том числе с чужого физического узла, через межпроцессорную шину. Для файлового сервера или контроллера домена это несущественно. Для SQL Server, который на NUMA-топологии строит свои memory nodes, потоки lazy writer и распределение планировщиков, — существенно очень.

Дальше начинается совсем весёлое. Гость видит один узел на 16 «физических» ядер, SQL Server 2016 и новее смотрит на это и говорит: больше восьми ядер на узел, включаю автоматический soft-NUMA, — и нарезает поверх заведомо неправильной картинки свои программные узлы. То есть галочка hot add не просто убирает полезную информацию, она подсовывает движку ложную, а он на её основе принимает решения о размещении внутренних структур. И всё это ради возможности, которой вы, скорее всего, не воспользуетесь ни разу за жизненный цикл машины.

Откуда вообще берётся эта галочка? В девяти случаях из десяти — из шаблона виртуальной машины. Кто-то один раз собрал golden image «чтобы было гибко», и с тех пор каждая новая ВМ, включая продуктивный SQL, приезжает с включёнными CPU Hot Add и Memory Hot Add. Проверьте свои шаблоны прямо сегодня, это пять минут работы и один из самых дешёвых способов ускорить базу, какие я знаю.

Снять CPU Hot Add можно только на выключенной виртуалке. «Горячо выключить горячее добавление» нельзя — планируйте окно обслуживания заранее, а не в ночь закрытия месяца.

Разбор: маркетинговое агентство на 26 рабочих мест

Условный клиент — маркетинговое агентство «Аналитика спроса», 26 рабочих мест. Кроме бухгалтерской базы 1С у них живёт своё аналитическое хранилище на 600 ГБ: выгрузки из рекламных кабинетов, CRM и счётчиков сайтов, по которым к первому числу собираются ежемесячные отчёты для клиентов агентства. Два хоста, в каждом по два Xeon Silver 4310 (12 ядер на сокет, то есть два физических NUMA-узла по 12 ядер и 128 ГБ памяти), 256 ГБ на хост, vSphere 9.0. Виртуалка SQL01: Windows Server 2022, SQL Server 2022 Standard, 16 vCPU одним виртуальным сокетом, 96 ГБ RAM. Ночная сборка витрин и пересчёт отчётов в конце месяца шли 3 часа 10 минут и, судя по мониторингу, упирались в процессор.

В последнюю ночь месяца дежурный админ добавил на горячую четыре vCPU. Windows отрапортовал 20 логических процессоров, диспетчер задач нарисовал двадцать графиков. В SQL Server по-прежнему шестнадцать рабочих планировщиков: cpu_count 20, scheduler_count 16. Выполнили RECONFIGURE — ничего не изменилось. Причина простая и обидная: Standard edition, а hot add требует Enterprise. Сборка как шла больше трёх часов, так и шла, только теперь хост обслуживал четыре бесполезных vCPU, а у соседних машин вырос %RDY.

Дальше я полез смотреть топологию целиком — и нашёл вторую половину проблемы, куда более дорогую. CPU Hot Add на этой ВМ был включён с момента развёртывания в 2022 году: прилетел из шаблона, никто и не заметил. Значит, vNUMA была выключена все эти годы, хотя 16 vCPU не помещаются в 12-ядерный физический узел. Coreinfo внутри гостя показывал ровно один NUMA-узел, а в журнале ошибок SQL Server лежала знакомая строка: «Automatic soft-NUMA was enabled because SQL Server has detected hardware NUMA nodes with greater than 8 physical cores». Движок нарезал два программных узла по восемь ядер поверх плоской картинки, а память виртуалка получала вперемешку с обоих физических узлов хоста.

Окно на сорок минут в субботу утром. Выключили ВМ, сняли CpuHotAddEnabled и MemoryHotAddEnabled, число vCPU вернули к 16. Вариант ужаться до 12 vCPU и целиком лечь в один физический узел обсуждали, но ETL агентства хорошо параллелится, и решили оставить 16. vNUMA ESXi построил сам — два узла по восемь vCPU, каждый внутри 12-ядерного физического; cores per socket выставили 8, чтобы гость видел два сокета в соответствии с узлами (на vNUMA в vSphere 9 это не влияет, но так проще читать errorlog и не упереться в лимит четырёх сокетов Standard). 96 ГБ памяти по 48 ГБ на узел спокойно помещаются в 128 ГБ физического. Включили, по журналу убедились, что видно два узла по восемь ядер и автоматический soft-NUMA больше не срабатывает. Дальше сделали то, что надо было сделать ещё при запуске: MAXDOP 8 вместо 0, cost threshold for parallelism 50 вместо дефолтной пятёрки, max server memory 84 ГБ, tempdb разложили на восемь файлов вместо одного.

Результат: сборка отчётов 1 час 50 минут вместо 3 часов 10 минут. И вот здесь я обязан быть честным, иначе получится реклама NUMA. Из сэкономленных восьмидесяти минут примерно 45 дали MAXDOP и cost threshold, ещё около пятнадцати — нормальный max server memory и разложенный tempdb, и только оставшиеся двадцать минут можно отнести на счёт восстановленной vNUMA. Зато после правки топологии исчез разброс: раньше одна и та же сборка занимала от 2:40 до 3:40 в зависимости от того, как лягут карты, теперь укладывается в 1:45–1:55. Для агентства, которое обещало клиентам отчёты к девяти утра первого числа, предсказуемость ценнее среднего значения.

Если бы мы просто оставили 20 vCPU и перешли на Enterprise, получили бы плоский узел на двадцать ядер, лишние лицензии по ядрам и, с высокой вероятностью, результат хуже исходного. Количество ядер само по себе ничего не лечит — лечит правильная топология плюс настройки параллелизма.
Цифры и версии: Разбор: маркетинговое агентство на 26 рабочих мест — схема
Цифры и версии: Разбор: маркетинговое агентство на 26 рабочих мест. Открыть схему в полном размере

Как я меняю CPU у SQL-виртуалки и как за пять минут проверить весь парк

Мой регламент простой и скучный: изменение конфигурации процессоров у продуктивной SQL-виртуалки — это плановая операция с выключением, а не «щёлкнул в vCenter, пока никто не видит». Да, это означает согласованное окно и уведомление пользователей. Зато на выходе предсказуемая топология и никакого гадания, почему база после «расширения ресурсов» стала работать медленнее.

Правила размера, которых я держусь. Считаем, сколько физических ядер в одном NUMA-узле хоста, и стараемся уложить виртуалку целиком в один узел — тогда вопрос vNUMA закрывается сам собой. Если не влезаем, число vCPU делаем кратным разумному размеру узла и даём ESXi построить vNUMA самому. Важная поправка к старым рецептам: в документации vSphere 9.0 прямо сказано, что «the virtual NUMA topology is not influenced by the number of virtual sockets and number of cores per socket», так что cores per socket я выставляю ради того, как гость видит сокеты (и лимита четырёх сокетов у Standard), а не ради vNUMA. Память режем так, чтобы на каждый vNUMA-узел приходилось не больше, чем есть в физическом узле хоста, с запасом процентов на десять под накладные расходы гипервизора. И не забываем: топология вычисляется при первом включении и держится, пока не поменяется число vCPU.

Инвентаризация парка — одна команда PowerCLI. Я прогоняю её у каждого нового клиента в первую неделю, и почти всегда нахожу от трёх до десятка машин с включённым hot add, о котором никто не помнит.

Connect-VIServer vcenter.example.local

Get-VM | Where-Object { $_.ExtensionData.Config.CpuHotAddEnabled -or
                        $_.ExtensionData.Config.MemoryHotAddEnabled } |
  Select-Object Name, NumCpu, MemoryGB,
    @{n='CoresPerSocket'; e={ $_.ExtensionData.Config.Hardware.NumCoresPerSocket }},
    @{n='CpuHotAdd';      e={ $_.ExtensionData.Config.CpuHotAddEnabled }},
    @{n='MemHotAdd';      e={ $_.ExtensionData.Config.MemoryHotAddEnabled }} |
  Sort-Object -Descending NumCpu | Format-Table -AutoSize

Чинить начинаю с машин, у которых больше восьми vCPU: именно они теряют vNUMA, у остальных потери нулевые, потому что vNUMA там и так не включилась бы. Само отключение — три строки, но только на выключенной ВМ.

$vm = Get-VM SQL01
if ($vm.PowerState -ne 'PoweredOff') { throw 'Сначала выключите виртуальную машину' }

$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.CpuHotAddEnabled    = $false
$spec.MemoryHotAddEnabled = $false
$vm.ExtensionData.ReconfigVM($spec)

# 16 vCPU; сокеты 2x8 — для гостя и лимитов Standard, vNUMA ESXi строит сам
Set-VM -VM $vm -NumCpu 16 -CoresPerSocket 8 -Confirm:$false
Start-VM -VM $vm -Confirm:$false

После включения обязательно проверяю картину изнутри гостя и изнутри движка. Windows должна показать нужное число логических процессоров, Coreinfo от Sysinternals и sys.dm_os_nodes — ожидаемое число NUMA-узлов, а SQL Server в журнале ошибок — строку про сокеты и ядра без упоминания автоматического soft-NUMA. Если soft-NUMA всё равно включился, значит на узел приходится больше восьми физических ядер, и это уже отдельное архитектурное решение: либо уменьшить виртуалку, либо осознанно оставить soft-NUMA и просто забыть про hot add навсегда.

Меньше — иногда быстрее. Я не раз уменьшал число vCPU у SQL-виртуалки и получал ускорение: падал CPU ready на переподписанном хосте, машина укладывалась в один NUMA-узел, планы переставали разлетаться по чужой памяти.

Надо срочно, а окна нет: что делать вместо Hot Add

Сначала убедитесь, что вы вообще упёрлись в процессор. Классическая ошибка ночного дежурного: видит 100 % CPU внутри гостя и добавляет ядра. А в esxtop у этой ВМ %RDY 12 % — то есть виртуалка не считает, а стоит в очереди к перегруженному хосту. Добавление vCPU в такой ситуации делает строго хуже: планировщику гипервизора теперь нужно одновременно найти свободными не шестнадцать физических ядер, а двадцать. Порог, за которым я начинаю беспокоиться, — примерно 5 % ready на vCPU. Второй частый случай — упор не в CPU, а в ожидания блокировок или в дисковую подсистему, и тогда ядра тем более не помогут.

Если убедились, что дело всё-таки в процессоре: на Standard edition hot add не вариант в принципе, даже не тратьте время. На Enterprise технически сработает, но помните две вещи. Первая — Microsoft прямо рекомендует избегать этой функции в любой версии из-за проблем со стабильностью, и делать это на боевой базе в ночь закрытия месяца — примерно худший момент из возможных. Вторая — раз у вас включён hot add, значит vNUMA у этой машины уже выключена, и вы всё это время недополучали производительность. Добавленные ядра лягут в тот же плоский узел.

Что реально помогает ночью, без выключения и без риска. Найти запрос-виновника через sys.dm_exec_query_stats и разобраться с ним точечно — в моей практике в семи случаях из десяти всю нагрузку даёт один отчёт или один регламент. Снять с сервера конкурирующую активность: перенести бэкап, приостановить обслуживание индексов, отключить на пару часов проверку антивирусом файлов базы. Ограничить фоновых пожирателей через Resource Governor, если он у вас настроен. Поднять cost threshold for parallelism, если сервер захлебнулся в CXCONSUMER от мелких параллельных планов. И, наконец, вспомнить про vMotion: перевезти виртуалку на менее загруженный хост — операция горячая, безопасная и часто дающая больше, чем любые манипуляции с ядрами.

-- топ-20 запросов по потреблению CPU с момента старта службы
SELECT TOP 20
       qs.total_worker_time / 1000 AS cpu_ms,
       qs.execution_count,
       qs.total_worker_time / qs.execution_count / 1000 AS avg_cpu_ms,
       SUBSTRING(st.text, (qs.statement_start_offset / 2) + 1,
         ((CASE qs.statement_end_offset WHEN -1
             THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END
           - qs.statement_start_offset) / 2) + 1) AS stmt
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
ORDER BY qs.total_worker_time DESC;

И про приоритеты, чтобы не распыляться. В первую очередь — снять hot add с продуктивных SQL-виртуалок, у которых больше восьми vCPU, и починить шаблоны, из которых эта галочка расползается. Во вторую — привести в порядок MAXDOP, cost threshold for parallelism и tempdb: это по-прежнему даёт больше выигрыша, чем любые игры с NUMA, и стоит бесплатно. А на что можно спокойно забить: на hot add у файловых серверов, контроллеров домена и терминальных машин с четырьмя-шестью vCPU. Там vNUMA всё равно не работает, вреда никакого, и трогать это ради красоты отчёта смысла нет.

Если в ночь аврала очень хочется нажать hot add на Enterprise — сделайте это, но сразу заведите задачу на плановое окно. Иначе временное решение живёт в инфраструктуре пять лет, как в разобранном выше случае.
Порядок действий: Надо срочно, а окна нет: что делать вместо Hot Add — схема
Порядок действий: Надо срочно, а окна нет: что делать вместо Hot Add. Открыть схему в полном размере

Частые вопросы

Hot Add CPU в SQL Server 2025 уже удалён или ещё работает?

Ещё работает. Microsoft пометила функцию как deprecated и заявила о планах удалить её в будущей версии, но в 2025 (17.x) она на месте. При этом в документации прямо рекомендуется избегать её в любой версии SQL Server из-за известных проблем со стабильностью, так что строить на ней регламент расширения ресурсов больше не стоит.

Почему после добавления vCPU Windows видит новые ядра, а SQL Server — нет?

Так задумано: движок не забирает автоматически появившиеся в системе процессоры, чтобы не отнять ресурсы, добавленные для другого приложения. Нужно выполнить RECONFIGURE. Но документация требует для hot add CPU редакцию Enterprise и отсутствие soft-NUMA, а если настроен affinity64 mask — его придётся поправить под новые CPU. На Standard рассчитывать на новые планировщики не стоит.

Правда ли, что галочка CPU Hot Add вредит, даже если ей не пользоваться?

Да. Документация vSphere 9.0 говорит однозначно: включение CPU HotAdd деактивирует виртуальную NUMA. Виртуалка с более чем восемью vCPU перестаёт видеть реальную топологию, получает один плоский узел и память вперемешку с разных физических узлов хоста. Для SQL Server это прямая потеря производительности и нестабильность времени выполнения тяжёлых расчётов.

Как понять, включён ли автоматический soft-NUMA, и мешает ли он?

Посмотрите softnuma_configuration_desc в sys.dm_os_sys_info и поищите в журнале ошибок строку «Automatic soft-NUMA was enabled because SQL Server has detected hardware NUMA nodes with greater than 8 physical cores». Начиная с SQL Server 2016 он включается сам, если на узел приходится больше восьми физических ядер. Сам по себе soft-NUMA обычно полезен, но он несовместим с горячим добавлением процессоров.

Сколько vCPU можно дать SQL Server Standard в 2026 году?

В SQL Server 2025 Standard использует не больше, чем меньшее из четырёх сокетов и 32 ядер, буферный пул ограничен 256 ГБ. В SQL Server 2022 и более ранних версиях потолок был 24 ядра. В виртуальной машине лимит считается по логическим процессорам, то есть по vCPU гостя. Всё, что выдано сверх лимита редакции, движок проигнорирует, а лицензии SQL Server по ядрам, Windows Server и прикладной системы вы за эти vCPU всё равно заплатите.

Что делать, если производительности не хватает прямо сейчас, а окна на выключение нет?

Сначала проверить %RDY в esxtop: если он выше примерно 5 %, проблема в переподписке хоста, и лишние vCPU сделают хуже. Дальше — найти запрос-виновника через sys.dm_exec_query_stats, убрать конкурирующую нагрузку (бэкапы, реиндексация, антивирус), при необходимости перевезти виртуалку на менее загруженный хост через vMotion. Это горячие и безопасные меры, а топологию править уже в плановое окно.

Помогут ли cores per socket вернуть vNUMA, если hot add оставить включённым?

Нет. В vSphere 9.0 включённый CPU HotAdd деактивирует виртуальную NUMA, а сама vNUMA-топология, по документации, не зависит от числа виртуальных сокетов и cores per socket. Единственный путь — выключить ВМ, снять CPU Hot Add и включить её снова: топология будет вычислена при включении.

Столкнулись с похожей задачей? Обращайтесь — решим

Если у вас происходит что-то из описанного в этой статье — или любая другая проблема с ИТ-инфраструктурой, — обращайтесь в любое время. Мои специалисты и я лично разберём ситуацию, найдём настоящую причину и доведём до решения.

Возьмёмся и за разовую задачу, и за постоянное обслуживание. Первичная консультация — бесплатно и без обязательств.

📞 +7 903 729-62-41 💬 MAX: +7 903 729-62-41 ✈ Telegram @ITfresh_Boss

С уважением, Семёнов Евгений Сергеевич, директор «АйТи Фреш» — IT-аутсорсинг для компаний до 50 рабочих мест, 15+ лет практики

Источники

© ООО «АйТи-Фреш» · Москва · Все статьи