Soft-IRQ und ähnl. auch mit irqbalance verteilen?

[Deleted member 11691]

Hallo,

beim checken der Interrupts pro CPU ist mir folgendes aufgefallen:

           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       
  0:        131          0          0          0          0          0          0          0  IR-IO-APIC-edge      timer
  1:          2          0          0          0          0          0          0          0  IR-IO-APIC-edge      i8042
  5:          0          0          0          0          0          0          0          0  IR-IO-APIC-edge      parport0
  8:          1          0          0          0          0          0          0          0  IR-IO-APIC-edge      rtc0
  9:          0          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   acpi
 12:          4          0          0          0          0          0          0          0  IR-IO-APIC-edge      i8042
 16:    2735571          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   ehci_hcd:usb1
 18:  550416335          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   aacraid
 23:        148          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   ehci_hcd:usb2
 24:          0          0          0          0          0          0          0          0  DMAR_MSI-edge      dmar0
 25:          0          0          0          0          0          0          0          0  DMAR_MSI-edge      dmar1
 26:      19147          0          0          0          0          0          0          0  IR-HPET_MSI-edge      hpet2
 27:          0          0          0          0          0          0          0          0  IR-HPET_MSI-edge      hpet3
 28:          0          0          0          0          0          0          0          0  IR-HPET_MSI-edge      hpet4
 29:          0          0          0          0          0          0          0          0  IR-HPET_MSI-edge      hpet5
 30:          0          0          0          0          0          0          0          0  IR-HPET_MSI-edge      hpet6
 32:          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      i915
 33:   20129940          0          0          0          0          0          0          0  IR-PCI-MSI-edge      ahci
 34:   82188041          0          0          0          0          0          0          0  IR-PCI-MSI-edge      eth1
 35: 3062546582          0          0          0          0          0          0          0  IR-PCI-MSI-edge      eth0
 36:          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      xhci_hcd
 37:       9755          0          0          0          0          0          0          0  IR-PCI-MSI-edge      snd_hda_intel
NMI:    4483506    4032188    3913713    3702739    4058929    3815765    3803281    3612254   Non-maskable interrupts
LOC: 4165798626 4111426596  185597620 4143491341   35345619 4253529842 3548288390 3720028749   Local timer interrupts
SPU:          0          0          0          0          0          0          0          0   Spurious interrupts
PMI:    4483506    4032188    3913713    3702739    4058929    3815765    3803281    3612254   Performance monitoring interrupts
IWI:          0          0          0          0          0          0          0          0   IRQ work interrupts
RES: 1510712034 1393243859  553407912  397805250  620145429  421845432  341766734  332861280   Rescheduling interrupts
CAL:    1700097    1682816    1686323    1678066    1686986    1685736    1675627    1651601   Function call interrupts
TLB:  430454686  465341653  447586295  458128510  359551691  419048414  412605672  425915488   TLB shootdowns
TRM:          0          0          0          0          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0          0          0          0          0   Machine check exceptions
MCP:      19147      19147      19147      19147      19147      19147      19147      19147   Machine check polls
ERR:          0
MIS:          0

Man sieht also klar und deutlich, dass der erste CPU-Kern alle folgende Aufgaben übernimmt:

• timer
• i8042
• rtc0
• i8042
• ehci_hcd:usb1
• aacraid
• ehci_hcd:usb2
• dmar0
• dmar1
• hpet2
• hpet3
• hpet4
• hpet5
• hpet6
• i915
• ahci
• eth1
• eth0
• xhci_hcd
• snd_hda_intel

Ist es möglich, mindestens eth0 hier auf mehr als einen Kern zu verteilen? Ich sehe hier bei einer eingehenden Attacke, dass die CPU-Last auf 100% steigt und dann der Packetloss kommt. Vor dem Erreichen der 100%-Marke ist der Packetloss noch sehr akzeptabel (0.8% nur ab einer Last von 100% sehe ich hier nurnoch 20 von 100 Paketen ankommen).

PS: irqbalance ist bereits installiert. System ist CentOS mit OpenVZ-Kernel (aus'm Repo installiert, ich möchte so gut als wenig oder garnicht kompilieren, um Abhängigkeiten automatisch zu verwalten) als SolusVM Slave.

 

[d4f]

Zuerst den Interrupt-Handler mal von CPU#0 weg kriegen.
Dazu in /proc/interrupts die für die Netzwerkkarte zuständige Interrupt-ID suchen und die entsprechende CPU-ID dann in /proc/irq/<ID>/smp_affinity schreiben.
Für Teil 2 gibt es etwas Lesestoff: http://moblog.wiredwings.com/archiv...eive-Packet-Steering-RPS-on-Linux-2.6.35.html

Beachte dass on-board Karten wie sie bspw. in Commodity-Server wie von Hetzner eingebaut sind mindestens 1 Interrupt je einkommendes Paket verursachen, oft sogar noch mehr. Als Resultat bist du je nach CPU und Kernelversion auf etwa 30k-50k p/s beschränkt.

Die schon etwas ältere aber super-stabile Intel Pro1000 Serie (e1000 driver) kann Pakete puffern und in gewünschten Zeitintervallen in nur einem Interrupt an die CPU übergeben. Zusammen mit weiteren Kernel- und Netzwerktweaks konnte ich schon über 130k p/s mit nur kleinen Einschränkungen überstehen.

Beachte aber dass so oder so entweder das Netzwerk des Rechenzentrum oder dein System irgendwann nicht mehr nachkommt, du also die Latte leicht erhöhst.

 

[Deleted member 11691]

Zuerst den Interrupt-Handler mal von CPU#0 weg kriegen.
Dazu in /proc/interrupts die für die Netzwerkkarte zuständige Interrupt-ID suchen und die entsprechende CPU-ID dann in /proc/irq/<ID>/smp_affinity schreiben.

Hier einfach "1" bzw. eine Ziffer zwischen 0 und 7 hineinschreiben?

[root@bedrock ~]# cat /proc/irq/35/smp_affinity
ff

 

[d4f]

ff bedeutet dass er alle CPU's nimmt - oder nehmen sollte. Generell sind die Sachen singlethreaded und bleiben auf Core #0 hängen wo sich dann viele Interrupt-Prozesse die Klinke in die Hand geben.
Ob dies bei dir auch der Fall ist (Hard- und softwareabhängig) kannst du ja durch einen cat auf /proc/interrupts sehen; die Zahlen bedeuten wie oft ein Interrupt-Handler von welchem Core bearbeitet wurde. Generell werden nur Software-Interrupts verteilt.