Для ЛЛ: принцип работы cpu scheduler надо знать!
Коллеги рассказали, история не моя.
Унаследовали они какой-то сервер с 16 физическими ядрами на сокет, два сокета. HPE, кстати.
Что-то из линейки Xeon E5-2600 v4, неплохие были процессоры. Для 2016 года.
Конечно , с виртуализацией поверх, в том числе с SQL, 1с , и так далее. И с внезапно возникшей проблемой «тормозит, раньше не тормозило, мы ничего не нажимали».
Я даже не буду называть виртуализацию, хотя скажу сразу, параметра CPU Ready там не было, так что это не Nutanix AHV и не Broadcom ESXi.
Пока писал статью, увидел заметку new CPU jitter counters in Windows Server 2025, и после дописывания статьи, пойду ее читать. Затем, конечно, пойду тыкать бывших коллег носом, что посмотрите, где там такой счетчик в этом вашем импортозамещении?
Что было: все было отлично. На несколько серверов выделили по 48 ядер на VM, и они работали, пока что-то не пошло не так.
Пойдем в теорию, что могло пойти не так
16 физических ядер на сокет у Intel означает 32 «всего» физических ядра на два сокета, и 64 потока.
Поток не дает особого прироста производительности. При некоторых, иногда (достаточно часто) встречаемых условиях, он даст .. ну 10%. Может 20%. Обещали 30%, но "не всегда".
Но может дать и минус, при определенных условиях.
Что делает планировщик, точнее cpu scheduler, при стандартных настройках.
Планировщик старается выдать каждому процессу (каждой VM, за исключением World 0 , и то, если вы не лазали в minroot кривыми ручонками) равное количество процессорного времени.
Что произойдет, если у вас в системе 32 физических ядра, и вы выдали суммарно 32 vCPU core, скажем? 8 VM по 4 CPU core? Ничего особенного, планировщик разложит задачи по физическим ядрам, и стандартные, не особо нагруженные VM, будут работать как работали. За, правда, исключением случая Storage space и storage space direct (S2D), там будет чуть сложнее. И с vSan не все так просто, но приемлимо.
Что произойдет, если у вас в системе те же 32 физических ядра, и вы выдали суммарно 96 vCPU core, скажем, 24 VM по 4 CPU core? Тоже ничего особенного, планировщик разложит задачи по физическим ядрам, потом попытается разложить задачи по виртуальным ядрам, потом построит очередь, и будет, так или иначе, эту очередь выполнять. Для ежедневных сценариев и нормальных гипервизоров ситуация с переподпиской CPU 1:1.5 и до 1:3 по физическим ядрам находится между «нормальной» и «терпимой».
Уточнение. Правильнее сказать «годится для начала разговора и осмотра CPU ready». Потому что одно дело у тебя система, которая почти ничего не считает, но крутит данные в памяти, как не в себя, другое дело VDI, третье дело NTP или еще какой сервер, у которого 2 vCPU только из вежливости. Кроме просмотра CPU ready, еще надо смотреть co-stop (%CSTP).
Для VDI сценариев, где 99.99% времени система ждет, пока пользователь нажмет что-то на клавиатуре, нормально будет работать и 1:10.
Оговорка: конечно, не во всех сценариях, и не во всех гипервизорах. Для нагрузки, чувствительной к задержкам, c ESXi 5.5, есть режим Latency-Sensitive. Для VM размером в хост, тоже есть свои настройки. См. разделы литература ниже.
Что произойдет, если у вас в системе те же 32 физических ядра, и вы выдали суммарно 64 vCPU core, скажем по 48 vCPU 2 VM (#1, #2), и по 8 еще оставшимся 4 (#3, #4, #5, #6)? Напоминаю, всего у вас в системе 32 ядра / 64 потока.
Будет очень интересно, не переключайтесь
Допустим, планировщик начал с первой машины (VM #1). Первым делом планировщику надо дождаться, пока остальные пять сделают свои дела с CPU, или, пока не пройдет таймаут. Допустим, что планировщику и VM свезло, и Vm #1 полезла на 48 vCPU.
А 48 физических ядер нет. Есть 32. Надо выкидывать остальные задачи куда-то в кеш 2-3-N уровня. Освобождать весь кеш 32+16 потоков, и всякие регистры к ним еще раз. Выполнить сначала одно, потом второе, и при этом попытаться уложиться в таймслот. Начинается то, что зовется context switches. И это я еще не лезу в пособие по архитектуре HT, потому что я даже не представляю, как именно построены очереди исполнения и всякие регистры по отношению к HT и тому, что называется speculative execution.
Окей, худо-бедно выполнились, и !
И пришла беда, откуда не ждали. У Intel Xeon давно есть режим авторазгона. Одни ядра разгоняются, другие нет, в результате угадать, какие ядра останутся на 2.2 , какие захотят работать на 2.4, какие на 2.6 – невозможно. Со всеми последствиями для попытки поддержать синхронность выполнения задач на ядрах со стороны планировщика.
Со стороны почти любого мониторинга это выглядит так, что процессор ничего не делает, и это чистая правда.
Сделаем еще шаг назад. Кроме ядер, в работе фигурирует и оперативная память. И желательно, чтобы данные в памяти (в физической памяти) были поближе к нужному ядру. NUMA, non uniform memory access, в полном расцвете сил. Хорошо, что в этом сценарии она не работает.
Сделаем еще шаг назад. Процессор – это не только калькулятор, это еще и всякие EAX EBX ECX EDX, и прочие данные, и очень не хотелось бы, чтобы специально обученные злодеи выдернули из этих ESI EDI ваш пароль, или хеш от него. Ага, Meltdown и Spectre (там чуть сложнее, конечно).
Начинается шаг 2 - исполнение VM #2 еще на 48 ядер. Даже и не на 48, кстати.
Планировщик пытается сказать процессору «давай, исполняй».
Планировщик пытается сказать процессору «давай, исполняй».
Процессор пытается разогнаться, при этом выкинуть лишние данные из своих кешей, памяти, регистров, и так далее. Точнее, конечно, планировщик командует, ядра делают.
VM #2 пытается всеми своими 48 ядрами, с криками «мне положено, вас тут не стояло», залезть на 32 ядра. Может, успевает даже что-то выполнить на разогнанных ядрах. Может, нет. И планировщик начинает ее выгонять с ядер со словами «завтра досчитаешь, СЛЕДУЮЩИЙ», напевая под нос What You Waiting For?
What You Waiting For? Time ? Take a chance, you stupid hoe
На 32 ядра лезут оставшиеся 4 по 8, быстро исполняются, ну как могут, и на следующем шаге планировщик опять пытается выполнить VM #1. Но VM 3, 4, 5, 6 работают за разное время, поэтому VM 1 придется подождать, пока выполнятся все задачи на всех ядрах, у всех машин, и только потом планировщик будет пытаться утрамбовать VM #1, примерно так же, как Lock, Shock and Barrel пропихивали Sandy Claws в трубу.
Все это время ядра не делают ничего. Ну как ничего. Сидят и курят.
С точки зрения мониторинга, загрузка на считающую часть процессоров - ноль.
Планировщик сидит, курит, и поет
Goodbye
Yes, it's time to say goodbye
Sad, I know, but, hey, you're done with living
It's time to give in
And go and so, goodbye
(но это не точно, может относится к этому более филосовски. Как говорилось, We all bloody die. Except this one here.)
Взяли, и вопреки всем крикам «да что вы делаете, как жить то» - отобрали у самых толстых машин, 1с кстати, лишние ядра. Все равно она ими пользоваться не умеет. И настройки в BIOS покрутили. И стало хорошо.
PS. Логика Пикабу зачем-то советует тег "другой мир". Окей. Тега broadcom нет, тега Nutanix нет
