Чи все ще є використання нерівностей на сучасному обладнанні?

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

Чи має irqbalance корисність у сучасних системах, де ми маємо сумісні з процесорами NUMA з обміном пам’яттю між їх ядрами?

Запуск irqbalance --oneshot --debugпоказує, що віртуальний гість у сучасному середовищі VMware ESXi обмінюється NUMA-вузлами між ядрами.

# irqbalance --oneshot --debug 3
Package 0:  numa_node is 0 cpu mask is 0000000f (load 0)
    Cache domain 0:  numa_node is 0 cpu mask is 0000000f  (load 0)
            CPU number 0  numa_node is 0 (load 0)           
            CPU number 1  numa_node is 0 (load 0)
            CPU number 2  numa_node is 0 (load 0)
            CPU number 3  numa_node is 0 (load 0)

У цьому випадку irqbalance виявить, що він працює в системі NUMA, і вийде. Це суперечить нашому моніторингу процесів.

Чи варто розглядати запущений numad замість нерівності в таких системах?

Це найбільше цікаво для віртуалізованих серверів VMware.

Ось одна відповідь від технічного персоналу RedHat. Хоча я вважаю, що більшість корпоративних апаратних засобів працює на NUMA. Наскільки я знаю, VMware також намагатиметься помістити ваші VM на той же вузол NUMA до тих пір, поки підходить його конфігурація процесора.

Досвід (особливо стосовно VMware) буде дуже вдячний.

Це правда «тому» сучасних серверів. Майте на увазі, що Multi-CPU / Muli-Core - це не те саме, що NUMA. Існує багато систем Multi-CPU / Core, які не мають NUMA.

Перш ніж прочитати моє пояснення нижче, будь ласка, прочитайте документ IRQ Affinity вище, а також наступні посібники:

Посібник з настройки продуктивності RHEL 6

Налаштування продуктивності з низькою затримкою для RHEL 6

Здобули все, що прочитали? Чудово, вам більше нічого від мене не чути! ;-) Але на випадок, коли ви були нетерплячі, ось чому ви хочете їх ...

IRQbalance утримує резервні копії всіх запитів IRQ на одному процесорі. Я бачив, що багато систем з ядрами процесора 4+ працюють повільно, оскільки всі процеси на різних процесорах очікують на процесор 0 для обробки мережевих запитів або запитів IRQ. CPU 0 виглядає дуже, дуже зайнято, всі інші процесори не зайняті, але додатки дуже повільні. Додатки повільно, оскільки вони чекають на свої запити вводу-виводу з ЦП 0.

IRQbalance намагається збалансувати це інтелектуальним способом у всіх процесорах і, коли це можливо, ставить обробку IRQ максимально наближеною до процесу. Це може бути одне ядро, ядро ​​на одній матриці, що ділиться тим самим кешем, або ядро ​​в одній зоні NUMA.

Ви повинні використовувати irqbalance, якщо:

Ви вручну закріплюєте свої додатки / IRQ до конкретних ядер з дуже вагомих причин (низька затримка, вимоги в режимі реального часу тощо)

Віртуальні гості. Це насправді не має сенсу, тому що, якщо ви не прив’яжете гостя до конкретних процесорів та IRQ та виділених мережевих пристроїв / пристроїв для зберігання даних, ви, швидше за все, не побачите переваг, які ви мали би від голого металу. Але ваш KVM / RHEV хостин повинен використовувати ірбаланс, numad і налаштовувати .

Іншими дуже важливими інструментами налаштування є налаштовані профілі та numad. Про них читайте! Використовуйте їх!

Numad схожий на irqbalance тим, що він намагається переконатися, що процес і його пам'ять знаходяться в одній зоні numa. З багатьма ядрами ми бачимо значне скорочення затримок, що призводить до набагато більш плавної надійності роботи під навантаженнями.

Якщо ви кваліфіковані, старанні та регулярно стежите за роботою або маєте передбачуване навантаження, ви можете досягти кращої продуктивності, ввімкнувши вручну процеси / IRQ до процесорів. Навіть у цих ситуаціях нерівність і нумада дуже близькі до узгодження. Але якщо ви невпевнені або ваша завантаженість непередбачувана, вам слід використовувати нерівність і нумедантність.