Много се чудих къде да я шибна тая тема, затова просто я пускам в общите.

Предупреждение към хората, които ползват 14-ти генерации (потенциално, ще е същото и за 12-та и 13-та) процесори на intel за Proxmox. Много внимавайте, когато раздавате ядра по виртуалните машини! По принцип, ако процесорът е 28-нишков, примерно, Proxmox го докладва като 28-ядрен и позволява да дадем максимум 28 ядра на виртуална машина. Дори и 10 виртуални да си подредим една до друга, на същото желязо, можем да им раздадем по 28 ядра на всяка, няма проблем. Това не означава, че ни трябва 280-ядрен процесор. Ядрата, които назначаваме в конфигурацията на QEMU, са един вид "обещани", не са завещани. С други думи, обещаваме на виртуалката, че ѝ отдаваме 28 ядра във виртуалния процесор и тя си създава schedule-а за инструкциите към процесора като за 28 ядра, но как QEMU фактически ще ги предаде тези инструкции към физическия процесор, си е негова работа. Отделно пък, как и кога самият процесор ще ги изпълни - това е съвсем друг въпрос, тъй като вътрешният му scheduling между ядрата е скрита картинка за всички над него.

Та, няма никакъв проблем да си правим такъв overprovisioning, виртуалките си работят нормално. Единственото ограничение, което ни налага Proxmox, е да не можем да дадем на една виртуална машина повече ядра, отколкото нишки има процесора. Т.е., ако имаме 28-нишков процесор, няма как да изплюем виртуалка с 32-ядрен виртуален процесор. Това е ясно, пише го и в документацията на Proxmox.

Така, къде е драмата?

Имам hypervisor при клиент, оборудван с i7-14700KF. На тази машина вървят 2 Windows-а и няколко контейнера за мониторинг, TrueNAS, ownCloud и т.н. Един от Windows-ите започна да гасне внезапно с грешки в ntdll , IRQL и какво ли още не - всеки син екран беше нова тъпотия, никаква очевидна закономерност. Накрая видях в Proxmox това:

Mar 07 10:06:21 pve kernel: x86/split lock detection: #AC: CPU 5/KVM/626195 took a split_lock trap at address: 0x7ee9d050
Mar 07 10:06:21 pve kernel: x86/split lock detection: #AC: CPU 7/KVM/626197 took a split_lock trap at address: 0x7ee9d050
Mar 07 10:06:21 pve kernel: x86/split lock detection: #AC: CPU 4/KVM/626194 took a split_lock trap at address: 0x7ee9d050
Mar 07 10:06:21 pve kernel: x86/split lock detection: #AC: CPU 10/KVM/626200 took a split_lock trap at address: 0x7ee9d050
Mar 07 10:06:21 pve kernel: x86/split lock detection: #AC: CPU 2/KVM/626192 took a split_lock trap at address: 0x7ee9d050
Mar 07 10:06:21 pve kernel: x86/split lock detection: #AC: CPU 8/KVM/626198 took a split_lock trap at address: 0x7ee9d050
Mar 07 10:06:21 pve kernel: x86/split lock detection: #AC: CPU 3/KVM/626193 took a split_lock trap at address: 0x7ee9d050
Mar 07 10:06:21 pve kernel: x86/split lock detection: #AC: CPU 11/KVM/626201 took a split_lock trap at address: 0x7ee9d050
Mar 07 10:06:21 pve kernel: x86/split lock detection: #AC: CPU 9/KVM/626199 took a split_lock trap at address: 0x7ee9d050
Mar 07 10:06:21 pve kernel: x86/split lock detection: #AC: CPU 1/KVM/626191 took a split_lock trap at address: 0x7ee9d050

Очевидно, 2 виртуални машини се карат коя кои ядра да окупира. Това на машини преди 12-та генерация Core не се е случвало в практиката ми. Решението, което приложих и засега изглежда да работи, беше да понамаля бройката ядра на всяка виртуална машина с Windows и да им активирам NUMA. До този момент, дали с NUMA или без, никъде не съм имал нито проблеми, нито някакви ползи. Явно Lake-овете имат някакъв скрит тъпизъм при миграцията на инструкции между ядрата. Та, на процесор от 12-та (включително) нагоре, полека с overprovisioning-a на процесора, ако планирате такъв билд за някъде.

Странна работа, не съм пробвал да правя виртуални машини по този начин, винаги гледам да разпределям/пускам машините така, че да не ми 'свършат' ядрата. Но моя proxmox е на стара машина, с E5-2680 v4 и не я държа включена постоянно, само когато ми трябва нещо да тествам. Дори и на vmware на основната машина (ryzen 5800x) не съм пробвал да стартирам виртуалки така, че да свършат ядрата или да се препокриват. Дори и RAM паметта гледам да разпределя по този начин. Тук гледам дават да се изключи това нещо, може и да си ги чел тези теми, пробва ли да изключиш детектването?

x86/split lock detection | Proxmox Support Forum

Split lock detection - Proxmox VE

Ето и chatGPT какво казва по въпроса:

Цитат

Точно така! Split lock детекцията в Proxmox (и изобщо в Linux) е механизъм, който следи за операции, при които множество процеси се опитват да заключат една и съща памет, но достъпът до нея не е подравнен към размера на кеш-линията на процесора (обикновено 64 байта при x86_64). Това може да доведе до сериозни забавяния, защото:

1. Кеш линията трябва да бъде заключена – когато един CPU core се опитва да модифицира памет, която се споделя между няколко ядра, цялата кеш линия трябва да се заключи и синхронизира между всички CPU ядра.
2. Широко разпространено блокиране – ако процесът прави така наречените split lock операции, те могат да доведат до забавяния за всички CPU ядра, защото се налага споделен достъп до паметта.
3. Intel и AMD започнаха да ограничават това поведение – съвременните процесори, особено Intel, вече включват хардуерни механизми за откриване и предотвратяване на split lock.

Какво значи това за Proxmox?

В Proxmox (който работи с KVM/QEMU) split lock може да се появи при виртуални машини, особено ако вътре в тях работи софтуер, който използва неправилно подравнени атомарни операции. В ядрото на Linux има параметър split_lock_detect, който може да бъде:

• off – напълно изключено (без проверка)
• warn – ядрата ще логват предупреждения, ако засекат split lock
• fatal – ще убие процеса, ако се опита да направи split lock

Как да провериш и конфигурираш това?

Можеш да провериш текущата настройка така:

cat /proc/sys/kernel/split_lock_detect

Ако искаш да я промениш, например да изключиш детекцията:

echo off | sudo tee /proc/sys/kernel/split_lock_detect

Или ако искаш да я направиш по-строга:

echo fatal | sudo tee /proc/sys/kernel/split_lock_detect

Ако split lock забавя работата на Proxmox виртуалните машини, може да се наложи да промениш настройките на ядрото. Ако искаш да ги направиш постоянни, можеш да добавиш в /etc/sysctl.conf:

kernel.split_lock_detect = off

и после да приложиш с:

sudo sysctl -p

Ще следя какво точно искаш да направиш – искаш да го изключиш, да дебъгнеш или да разбереш дали влияе на производителността?

 

Четох за детектването във форума на Proxmox, но за да я има тази детекция по дифолт, значи има защо. Да изключиш механизма, който ти прихваща конфликтите, е като просто да си затвориш очите пред проблема. Виртуалките може и вече да не крашват, но загуба или поне повреда на данните не е изключена. Според мен, истинското решение е това, което аз съм приложил. Другото е замитане на проблема под килима, поне така ги усещам аз нещата.

А на твоя Xeon този проблем няма да го има. И на моя го няма. И на сума ти други Core i-нещо-си съм деплойнал Proxmox и няма драма. Само на тая конкретна 14-та генерация изядох дървото. В интерес на истината, преди този i7 бях правил същия сетъп на i9-14900, но там бях ги пуснал на по-малко ядра виртуалките: едната на 16 кора, а другата - 8. Тук им ги раздадох всичките и това предизвика проблем с KVM на 3-тия ден след пускането в експлоатация. На първоначалните тестове всичко летеше и сега изведнъж се сговни. На по-стари процесори, отпреди 2022-ра година, нямам такива изцепки.

Да, може би това е вариант, но трябва хубаво да се чете, обмисли и експериментира с това нещо, когато е включено и изключено точно какво се случва. Уж пише, че в по-новите intel процесори е оправено, но изглежда не съвсем. За AMD не видях да пише нещо. Общо-взето какво се случва - даден процес работи с част от паметта, която да кажем е на една от виртуалните машини. Ако друга виртуална машина се опита да достъпи тази памет, тя е заключена и не е достъпна за втората машина/процес, затова процеса се 'приспива' за 10 милисекунди, докато се обработят евентуално данните. И това уж трябва да сработи с минимално забавяне на съответния втори процес, но реално се получава някакъв краш при теб. Според мен това не е само от ползване на споделени ядра.

И още един вариант - процесора да е започнал да деградира - познатия бъг за тези intel процесори.

Цитат

As explained by this LWN article, split locks occur when an atomic instruction accesses memory that spans two cache lines, for example because of a misaligned memory access. To ensure that the instruction sees consistent data, the processor core acquires a global bus lock. This is much slower than an access within one cache line, and also slows down other cores. In case the host is a hypervisor running potentially untrusted VMs, this opens the door for denial-of-service attacks: A VM that performs a lot of unaligned memory accesses can force the processor to repeatedly acquire the global bus lock, which indirectly slows down other VMs.

Starting with Linux kernel 5.19, every time a thread takes a split lock, the Linux kernel artificially slows down the thread by making it sleep for 10 milliseconds and synchronizing it with other threads taking split locks. This is controlled by the split_lock_mitigate sysctl parameter. See the related LWN article for more details. This is done to make denial-of-service attacks infeasible and keeping the offending thread from affecting the other running processes. The first time a split lock is detected for a thread, the kernel prints a warning to the journal (x86/split lock detection: #AC: [...] took a split_lock trap at address: [...]).

If a VM performs a lot of misaligned memory access, the host kernel will artificially slow down the VM. The bpftrace command above prints a message every time the kernel artificially slows down a thread. In the VM, this will be noticeable as virtual CPU freezes with various kinds of effects. In the case of Windows VMs, in-guest latency monitors may report a high amount of time spent handling DPCs during that time.

Options

If a VM is artificially slowed down by split lock mitigation,

• the preferred solution is to fix the in-guest workload that is responsible for the misaligned memory accesses. The responsible in-guest process should be adjusted to only perform aligned memory access, which will eliminate the split locks and thus the artificial slowdowns. However, this is only possible if you control the responsible in-guest process (e.g., because you can modify its source code).
• If you cannot fix the in-guest workload, you can consider disabling the split lock mitigation. However, if the split lock mitigation is disabled, malicious VM guests can perform denial-of-service attacks against the host and other VM guests, as described on LWN:
  • If you are aware of the risks, you can disable split lock mitigation temporarily by running sysctl -w kernel.split_lock_mitigate=0 (see the kernel docs). You can disable it permanently by creating a file /etc/sysctl.d/50-split-lock.conf with contents kernel.split_lock_mitigate=0, and running sysctl -p /etc/sysctl.d/50-split-lock.conf. You will still get the warnings in the journal, but the bpftrace script should report no more artificial slowdowns.
  • Alternatively, and if you are aware of the risks, you can generally disable split lock detection by adding split_lock_detect=off parameter to the kernel command line and rebooting. See the kernel docs for more information on the split_lock_detect parameter.

Писах пак и на chat GPT, също предположи, че може да има някаква промяна в архитектурата при по-новите интел процесори и този процес на split lock да е по-агресивен. Също предложи и още евентуални решения, ако ти се занимава да експериментираш.

Цитат

Да, изглежда проблемът е свързан с по-новите Intel процесори (от 12-то поколение нагоре), където split lock механизмът е по-строг и може да доведе до нестабилност, особено в среди с виртуализация като Proxmox.

Основни наблюдения:

1. Split lock detection на по-новите Intel CPU – Този механизъм засича и блокира split lock операции, които забавят цялата система. В случая с i7-14700KF, изглежда, че някои инструкции, изпълнявани от Windows VM, се сблъскват с тази защита.

2. Различни сини екрани в Windows – Проблемите в ntdll, IRQL_NOT_LESS_OR_EQUAL и други грешки подсказват за ниско ниво на несъвместимост или конфликт в достъпа до ресурсите на процесора.

3. Проблемът не се среща в по-старите поколения – Възможно е това да се дължи на промени в архитектурата на процесора, включително хибридната архитектура (P-cores и E-cores), която може да влияе на начина, по който VM-ите разпределят задачите между ядрата.

4. NUMA и ограничаване на CPU ядрата като решение – Това има логика, защото намалява вероятността няколко виртуални машини да се "борят" за едни и същи физически ресурси, като така се минимизира рискът от split lock проблеми.

---

Как да избегнеш този проблем в Proxmox:

1. Намали броя на ядрата за всяка VM

   • В конфигурацията на VM в Proxmox задай по-малко виртуални CPU ядра (vCPU), така че да не се прави overprovisioning (да не се надвишава броят на реалните физически ядра).

2. Активирай NUMA

   • В Proxmox UI отиди в VM → Hardware → Processors и включи опцията NUMA.
   • Може също да добавиш numa=1 в конфигурацията на VM (/etc/pve/qemu-server/<VMID>.conf).

3. Деактивирай split lock detection (ако не може да се избегне по друг начин)

   • Провери дали е активен:

     cat /proc/sys/kernel/split_lock_detect
     

   • Ако се налага, може да го изключиш (но това може да маскира проблема, а не да го реши):

     echo off | sudo tee /proc/sys/kernel/split_lock_detect
     

     За постоянна промяна:

     echo "kernel.split_lock_detect = off" | sudo tee -a /etc/sysctl.conf
     sudo sysctl -p
     

4. Оптимизиране на pinned CPU за VM-ите

   • Вместо да оставяш Proxmox да разпределя ядрата динамично, може ръчно да пинираш определени ядра на дадена VM:

     cores: 4
     cpu: host
     numa: 1
     

   • Пробвай също така host-passthrough за CPU mode, за да намалиш евентуални проблеми с емулацията:

     cpu: host,flags=+pcid
     

5. Актуализиране на ядрото на Proxmox

   • Ако има нова версия на ядрото, особено ако използваш pve-kernel-6.x, възможно е да са пуснати фиксове за split lock проблеми.

---

Заключение

Изглежда, че това е специфичен проблем на по-новите Intel Core поколения (от 12-то нагоре), при който агресивната детекция на split lock в комбинация с виртуализация води до нестабилност в Windows VM. Най-сигурното решение е ограничаването на vCPU за VM-ите и активирането на NUMA. Ако проблемът не се решава, може да се пробва и изключване на split lock detection, но това е компромисен вариант.

 

преди 2 минути, Raze написа:

Да, може би това е вариант, но трябва хубаво да се чете, обмисли и експериментира с това нещо, когато е включено и изключено точно какво се случва. Уж пише, че в по-новите intel процесори е оправено, но изглежда не съвсем. За AMD не видях да пише нещо. Общо-взето какво се случва - даден процес работи с част от паметта, която да кажем е на една от виртуалните машини. Ако друга виртуална машина се опита да достъпи тази памет, тя е заключена и не е достъпна за втората машина/процес, затова процеса се 'приспива' за 10 милисекунди, докато се обработят евентуално данните. И това уж трябва да сработи с минимално забавяне на съответния втори процес, но реално се получава някакъв краш при теб. Според мен това не е само от ползване на споделени ядра.

И още един вариант - процесора да е започнал да деградира - познатия бъг за тези intel процесори.

Писах пак и на chat GPT, също предположи, че може да има някаква промяна в архитектурата при по-новите интел процесори и този процес на split lock да е по-агресивен. Също предложи и още евентуални решения, ако ти се занимава да експериментираш.

 

Никакъв шанс да е деградиращ процесор, машината я сглобих преди по-малко от месец, с висок клас дъно и с последния BIOS.

Да, само го давам като вариант, то ако има подобен проблем ще се разбере. И все пак, за подобни машини е по-добре да се слагат за по-сигурно xeon процесори и ECC памет, въпреки че такава принципно трябва да е съвместима с този процесор.

Между другото, ChatGPT ти е дал точните стъпки, които предприемам и аз при настройка и troubleshooting, изключая точка 3. Това ме успокоява, че грамотно си настройвам машините.