CPU0 завалений перервами eth1

У мене є Ubuntu VM, який працює в Xen XCP на базі Ubuntu. Ззаду розміщується спеціальна послуга HTTP на основі FCGI nginx.

Під навантаженням з ab першого ядра процесора насичується, а решта - недостатньо навантажена.

В /proc/interruptsя бачу , що CPU0 служить порядок більше переривань , ніж будь-яке інше ядро. Більшість із них походить eth1.

Чи можна щось зробити, щоб поліпшити продуктивність цього віртуального комп'ютера? Чи є спосіб збалансувати перерви більш рівномірно?

Деталі Горі:

$ унаме -а
Linux MYHOST 2.6.38-15-virtual # 59-Ubuntu SMP Пт 27 квітня 16:40:18 UTC 2012 i686 i686 i386 GNU / Linux

$ lsb_release -a
Немає модулів LSB.
Ідентифікатор дистриб'ютора: Ubuntu
Опис: Ubuntu 11.04
Реліз: 11.04
Кодове ім'я: natty

$ cat / proc / перериває 
           CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU7       
283: 113720624 0 0 0 0 0 0 0 xen-dyn-event eth1
284: 1 0 0 0 0 0 0 0 xen-dyn-event eth0
285: 2254 0 0 3873799 0 0 0 0 xen-dyn-event blkif
286: 23 0 0 0 0 0 0 0 xen-dyn-подія hvc_console
287: 492 42 0 0 0 0 0 295324 xen-dyn-event xenbus
288: 0 0 0 0 0 0 0 222294 xen-percpu-ipi callfuncsingle7
289: 0 0 0 0 0 0 0 0 xen-percpu-virq debug7
290: 0 0 0 0 0 0 0 151302 xen-percpu-ipi callfunc7
291: 0 0 0 0 0 0 0 3236015 xen-percpu-ipi змінено7
292: 0 0 0 0 0 0 0 60064 спинлок xen-percpu-ipi7
293: 0 0 0 0 0 0 0 12355510 xen-percpu-virq timer7
294: 0 0 0 0 0 0 803174 0 xen-percpu-ipi callfuncsingle6
295: 0 0 0 0 0 0 0 0 xen-percpu-virq debug6
296: 0 0 0 0 0 0 60027 0 xen-percpu-ipi callfunc6
297: 0 0 0 0 0 0 5374762 0 xen-percpu-ipi змінено6
298: 0 0 0 0 0 0 64976 0 xen-percpu-ipi spinlock6
299: 0 0 0 0 0 0 15294870 0 таймер xen-percpu-virq6
300: 0 0 0 0 0 264441 0 0 xen-percpu-ipi callfuncsingle5
301: 0 0 0 0 0 0 0 0 xen-percpu-virq debug5
302: 0 0 0 0 0 79324 0 0 xen-percpu-ipi callfunc5
303: 0 0 0 0 0 3468144 0 0 xen-percpu-ipi змінено5
304: 0 0 0 0 0 66269 0 0 xen-percpu-ipi spinlock5
305: 0 0 0 0 0 12778464 0 0 таймер xen-percpu-virq5
306: 0 0 0 0 844591 0 0 0 xen-percpu-ipi callfuncsingle4
307: 0 0 0 0 0 0 0 0 xen-percpu-virq debug4
308: 0 0 0 0 75293 0 0 0 xen-percpu-ipi callfunc4
309: 0 0 0 0 3482146 0 0 0 xen-percpu-ipi змінено4
310: 0 0 0 0 79312 0 0 0 xen-percpu-ipi spinlock4
311: 0 0 0 0 21642424 0 0 0 xen-percpu-virq timer4
312: 0 0 0 449141 0 0 0 0 xen-percpu-ipi callfuncsingle3
313: 0 0 0 0 0 0 0 0 xen-percpu-virq debug3
314: 0 0 0 95405 0 0 0 0 xen-percpu-ipi callfunc3
315: 0 0 0 3802992 0 0 0 0 xen-percpu-ipi змінено3
316: 0 0 0 76607 0 0 0 0 xen-percpu-ipi spinlock3
317: 0 0 0 16439729 0 0 0 0 xen-percpu-virq timer3
318: 0 0 876383 0 0 0 0 0 xen-percpu-ipi callfuncsingle2
319: 0 0 0 0 0 0 0 0 xen-percpu-virq debug2
320: 0 0 76416 0 0 0 0 0 xen-percpu-ipi callfunc2
321: 0 0 3422476 0 0 0 0 0 xen-percpu-ipi resched2
322: 0 0 69217 0 0 0 0 0 xen-percpu-ipi spinlock2
323: 0 0 10247182 0 0 0 0 0 xen-percpu-virq timer2
324: 0 393514 0 0 0 0 0 0 xen-percpu-ipi callfuncsingle1
325: 0 0 0 0 0 0 0 0 xen-percpu-virq debug1
326: 0 95773 0 0 0 0 0 0 xen-percpu-ipi callfunc1
327: 0 3551629 0 0 0 0 0 0 xen-percpu-ipi змінено1
328: 0 77823 0 0 0 0 0 0 xen-percpu-ipi spinlock1
329: 0 13784021 0 0 0 0 0 0 xen-percpu-virq timer1
330: 730435 0 0 0 0 0 0 0 xen-percpu-ipi callfuncsingle0
331: 0 0 0 0 0 0 0 0 xen-percpu-virq debug0
332: 39649 0 0 0 0 0 0 0 xen-percpu-ipi callfunc0
333: 3607120 0 0 0 0 0 0 0 xen-percpu-ipi resched0
334: 348740 0 0 0 0 0 0 0 xen-percpu-ipi spinlock0
335: 89912004 0 0 0 0 0 0 0 xen-percpu-virq timer0
NMI: 0 0 0 0 0 0 0 0 Немаскуючі переривання
LOC: 0 0 0 0 0 0 0 0 Локальний таймер переривається
SPU: 0 0 0 0 0 0 0 0 Неправдиві переривання
PMI: 0 0 0 0 0 0 0 0 Переривання моніторингу продуктивності
IWI: 0 0 0 0 0 0 0 0 IRQ робота переривається
RES: 3607120 3551629 3422476 3802992 3482146 3468144 5374762 3236015 Переривання перенесення графіків
CAL: 770084 489287 952799 544546 919884 343765 863201 373596 Переривання функції виклику
TLB: 0 0 0 0 0 0 0 0 Знищення TLB
TRM: 0 0 0 0 0 0 0 0 Термічна подія переривається
THR: 0 0 0 0 0 0 0 0 Поріг APIC переривається
MCE: 0 0 0 0 0 0 0 0 Винятки з машинної перевірки
MCP: 0 0 0 0 0 0 0 0 Машинні контрольні опитування
Помилка: 0
МІС: 0

Подивіться в /proc/irq/283каталог. Є smp_affinity_listфайл, який показує, які процесори отримають переривання 283. Для вас цей файл, ймовірно, містить "0" (і, smp_affinityймовірно, містить "1").

Ви можете записати діапазон процесора у smp_affinity_listфайл:

echo 0-7 | sudo tee /proc/irq/283/smp_affinity_list

Або ви можете написати маску, де кожен біт відповідає процесору, щоб smp_affinity:

printf %x $((2**8-1)) | sudo tee /proc/irq/283/smp_affinity

Однак, як відомо , irqbalance має власне уявлення про те, яку спорідненість повинен мати кожен переривання, і це може відновити ваші оновлення. Тож найкраще, якщо ви просто видаліть irqbalance повністю. Або принаймні зупиніть його і забороніть його з’являтися при перезавантаженні.

Якщо навіть без irqbalance вам нецікаво smp_affinityперервати 283 після перезавантаження, вам доведеться вручну оновити спорідненість процесора в одному зі своїх запуску сценаріїв.

Якщо у вас є правильна модель Intel NIC, ви можете значно підвищити продуктивність.

Цитувати перший абзац:

Багатоядерні процесори та новітні адаптери Ethernet (включаючи 82575, 82576, 82598 та 82599) дозволяють оптимізувати потоки переадресації TCP шляхом призначення потоків виконання окремим ядрам. За замовчуванням Linux автоматично призначає переривання процесорним ядрам. В даний час існує два способи автоматичного призначення переривань, балансир IRQ інкенера та демон балансу IRQ в просторі користувача. Обидва пропонують компроміси, які можуть знизити використання процесора, але не збільшити максимальну швидкість переадресації IP. Оптимальну пропускну здатність можна отримати, вручну закріпивши черги адаптера Ethernet до конкретних процесорних ядер.

Для IP-переадресації пара черги передачі / прийому повинна використовувати одне ядро ​​процесора і зменшити будь-яку синхронізацію кешу між різними ядрами. Це може бути здійснено шляхом призначення переривань передачі та прийому певним ядрам. Починаючи з ядра Linux 2.6.27, на 82575, 82576, 82598 та 82599 можна використовувати декілька черг. Крім того, у чергових передавальних повідомленнях переривання сигналів (MSI-X) було включено кілька черг передачі. MSI-X підтримує більшу кількість перерв, які можуть бути використані, що дозволяє більш тонко контролювати та орієнтувати переривання на конкретні процесори.

Див.: Присвоєння переривань процесорним ядрам за допомогою Intel® 82575/82576 або 82598/82599 Ethernet Controller

Насправді рекомендується, особливо при роботі з повторюваними процесами протягом короткої тривалості, щоб усі перебої, генеровані чергою пристроїв, оброблялися одним і тим самим процесором, замість балансування IRQ, і, таким чином, ви побачите кращу ефективність, якщо один процесор обробляє переривання eth1 *** виняток, наданий нижче

Джерело, зв'язане вище, походить з симпозіуму Linux, і я рекомендую вам ознайомитись з параграфами, присвяченими SMP IRQ Affinity, оскільки це переконає вас більш ефективно, ніж ця публікація.

Чому?

Нагадаємо, кожен процесор має власний кеш, окрім можливості отримати доступ до основної пам'яті, ознайомтеся з цією схемою . Коли спрацьовує переривання, ядро ​​CPU доведеться отримати інструкції для обробки переривання з основної пам'яті, що займає набагато більше часу, ніж якщо вказівки, де в кеш-пам'яті. Після того, як процесор виконав завдання, він буде мати ці інструкції в кеші. Тепер скажіть, що одне і те ж ядро ​​CPU майже весь час обробляє одне і те ж переривання, функція обробника переривань навряд чи залишить кеш ядра CPU, підвищивши продуктивність ядра.

Крім того, коли IRQ врівноважений, він може призначити постійну обробку переривань різними процесорами, тоді новому процесорному ядру, ймовірно, не буде функціонувати обробник переривань у кеші, і для отримання належного обробника з головного потрібно буде тривалий час пам'ять.

Виняток : якщо ви рідко використовуєте eth1 переривання, тобто достатньо часу проходить, щоб кеш перезаписувався, виконуючи інші завдання, тобто у вас є дані, що переходять через цей інтерфейс з перервами з довгими періодами між ними, то ви, швидше за все, не побачите цих переваг бо вони є, коли ви використовуєте процес на високій частоті.

Висновок

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

 /proc/'IRQ number'/smp_affinity

або

/proc/irq/'IRQ number'/smp_affinity

Дивіться останній абзац у розділі Спорідненість SMP IRQ з джерела, пов'язаного вище, в ньому є вказівки.

Як варіант

Ви можете змінити частоту підняття прапора переривання, або збільшивши розмір MTU (джомбові кадри), якщо мережа дозволяє це, або змінити, щоб прапор був піднятий після отримання більшої кількості пакетів замість кожного пакету АБО змінити тайм-аут, тому піднімайте переривання через певний час. Будьте обережні з варіантом часу, оскільки розмір буфера може бути заповненим до закінчення часу. Це можна зробити за допомогою етилу, який викладений у пов'язаному джерелі.

ця відповідь наближається до тієї тривалості, коли люди не збираються її читати, тому я не буду детально описуватись, але залежно від вашої ситуації є багато рішень ... перевірте джерело :)