Performance problemen 10k IRQ/s

[eddie4nl]

MedeTweakers ik heb een probleem. Ik heb een server staan deze ontvangt enorm veel kleinen packets die afgehandeld moeten worden en daarna teruggestuurd, volgens de switch 160.000packets/s. Dit heeft als resultaat (als ik het goed interpreteer) dat het service proces 20% cpu gebruikt en de rest verloren lijkt te gaan aan systeem proces en IRQ. Voordat ik zoveel traffic gegenereerd waren de grafieken mooi egaal maar nu wanneer het traffic te hoog stijgt vliegt de server in de stress en begint die zijn aanvragen niet meer netjes af te handelen.

De server heeft de volgende netwerk kaart.
Intel Corporation 82574L Gigabit Network

Ik hoop dat jullie wat van jullie wijsheid kunnen laten schijnen over mijn probleem.

En nu voor wat grafiekjes:


Real cores


HyperThreading cores

code:

root:~# sudo cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
  0:         47          0          0          0   IO-APIC-edge      timer
  1:          1          1          1          0   IO-APIC-edge      i8042
  7:          0          0          0          0   IO-APIC-edge      parport0
  8:          0          0          1          0   IO-APIC-edge      rtc0
  9:          0          0          0          0   IO-APIC-fasteoi   acpi
 12:          1          3          1          0   IO-APIC-edge      i8042
 16:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:us                                                                                                        b5
 18:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:us                                                                                                        b4
 19:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:us                                                                                                        b3
 23:          8          4          8          7   IO-APIC-fasteoi   ehci_hcd:us                                                                                                        b1, uhci_hcd:usb2
 41:       6600 2160545632       6649      33509   PCI-MSI-edge      eth0-rx-0
 42:  655056893      11034     109374      60275   PCI-MSI-edge      eth0-tx-0
 43:          0          0          2    1209071   PCI-MSI-edge      eth0
 44:        933        877     916236        878   PCI-MSI-edge      ahci
 45:          0          0          0          0   PCI-MSI-edge      gma500
NMI:     366222     350617      20337      12562   Non-maskable interrupts
LOC:  161538787  141640369   50611925   56901193   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:     366222     350617      20337      12562   Performance monitoring interr                                                                                                        upts
IWI:    9268963    9823685   22472578   13994814   IRQ work interrupts
RTR:          0          0          0          0   APIC ICR read retries
RES:   29339956   21397034   73737557   70235149   Rescheduling interrupts
CAL:      49665      51794        448        485   Function call interrupts
TLB:      17790      28939      41425      48946   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:       2265       2265       2265       2265   Machine check polls
ERR:          0
MIS:          0

code:

root:~# ethtool -k eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: on
        tx-checksum-ipv4: off [fixed]
        tx-checksum-ip-generic: on
        tx-checksum-ipv6: off [fixed]
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: on
        tx-scatter-gather: on
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
        tx-tcp-segmentation: off [requested on]
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp6-segmentation: off [requested on]
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: on
loopback: off [fixed]
rx-fcs: off
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]

[ Voor 19% gewijzigd door eddie4nl op 11-01-2014 20:27 ]

[Ploink]

De intel NICs hebben verschillende functies om CPU load te beperken, bijvoorbeel "interrupt coalescing"
Zie "man ethtool" voor hoe je het activeert.

Edit: overigens denk ik toch dat je server software verantwoordelijk is voor de meeste CPU load. Dat is ook logisch, want die verwerkt de data, je hardware en de kernel verplaatsen het allen maar.
Kijk eens met "top" naar de proces lijst.

Als ik mijn GigE netwerk camera aan mijn intel NIC hang en ik trek de lijn helemaal vol met full-HD raw image data, dan hou ik nog zat cpu over.
Voor gigabit camera's wordt vaak geadviseert jumbo frames te gebruiken, maar mijn conclusie was dat dit geen donder uitmaakt op een moderne pc. Ook de speciale windows driver om de TCP stack te omzeilen was niet nodig. De cpu kan het makkelijk aan.

Toch is jouw IRQ rate wel heel hoog, misschien kan coalescing net dat beetje extra performance geven dat je nodig hebt...

[ Voor 75% gewijzigd door Ploink op 11-01-2014 20:52 ]

[eddie4nl]

Wat ik zie in top verschilt: Stress mode is geen process en dan in een keer 300% daarna weer weg. Niet in stress process 90-110%

interrupt coalescing klinkt naar wat ik opzoek ben. Echter zegt ethtool -c Badcommand dus het lijkt alsof ik een ethtool heb zonder de beschikking over coalescing.

[Ploink]

[root@xxx ~]# ethtool -c
ethtool: bad command line argument(s)
For more information run ethtool -h

[root@xxx ~]# ethtool -c eth0
Coalesce parameters for eth0:
Cannot get device coalesce settings: Operation not supported
[root@xxx ~]#

Je moet dus wel even de nic vermelden
Mijn onboard nic ondersteunt het niet.

[eddie4nl]

Twee seconden geleden zag ik ook dat je de interface moet mee geven.

Die van mij ondersteund het wel dus dat is goed nieuws.

EDIT:

rx-usecs van 3 naar 40 gezet.

tx-usecs en Adaptive RX: off TX: off wil niet veranderen dus dat zal niet ondersteund worden we zullen zien of het terug komt in de grafiekjes.

Ill keep you posted.

Coalesce parameters for eth0:
Adaptive RX: off  TX: off
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 40
rx-frames: 0
rx-usecs-irq: 0
rx-frames-irq: 0

tx-usecs: 0
tx-frames: 0
tx-usecs-irq: 0
tx-frames-irq: 0

rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0

rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0

[ Voor 140% gewijzigd door eddie4nl op 11-01-2014 21:14 ]

[Ploink]

Ik heb even zitten googelen, maar kan bar weinig documentatie vinden.
Misschien heb je hier nog het meest aan:
http://serverfault.com/qu...g-ethtool-coalesce-output
Misschien moet je ook de rx-frames en -irq parameters zetten?

[eddie4nl]

Ik zal er morgen even naar kijken.

Al het positieven effect dat het heeft gehad is nu ingenomen door de IRQ's van het verzenden... (zie paarse lijn tussen 18 :00 0:00en )

[ Voor 10% gewijzigd door eddie4nl op 12-01-2014 11:59 ]

[gekkie]

Welke kernel draait het op ?

[eddie4nl]

Ik draai Ubuntu saucy salamander 13.10 met kernel 3.11.0-12-generic Oct 9 16:20:46


@ploink
Inderdaad ik had die pagina ook gevonden. Ik vermoed dat het volgende wordt bedoeld:
rx-usecs: 18 (Aantal micro seconde dat IRQ's worden verzameld )
rx-frames: 12 (Aantal IRQ's verzameld tot IRQ )
rx-usecs-irq: 18 (?)
rx-frames-irq: 2 (?)'

Ik heb het volgende gevonden op een intel pagina maar ik wordt er niet veel wijzer uit.

code:

    ethtool -C eth2 rx-usecs-irq 128 - set static interrupt moderation

    ethtool -C eth2 adaptive-rx on  - enable dynamic interrupt moderation
    ethtool -C eth2 adaptive-rx off - disable dynamic interrupt moderation
    ethtool -C eth2 rx-frames-low 16 - low watermark of rx queue for dynamic
                                       interrupt moderation
    ethtool -C eth2 rx-frames-high 256 - high watermark of rx queue for
                                         dynamic interrupt moderation
    ethtool -C eth2 rx-usecs-low 40 - smallest interrupt moderation timer
                                      for dynamic interrupt moderation
    ethtool -C eth2 rx-usecs-high 1000 - largest interrupt moderation timer
                                         for dynamic interrupt moderation

na de wijziging is de IRQ van het ontvangen juist omhoog gegaan. Mogelijk waren dat packets die eerst gedropt werden. Ik heb de rx-usecs verhoogd van 40 naar 120


Edit:
Leuk stukje geschreven over linux nic's en interrupts (Voor degene die interesse hebben.)
http://www.chinanetcloud....s-overloading-single-cpus

[ Voor 137% gewijzigd door eddie4nl op 12-01-2014 12:20 ]

[Ploink]

http://docs.oracle.com/cd...arams.html#50507802_91890

rx-usecs and rx-frames control the RX interrupt rate per RX DMA channel. RX interrupt will be generated after rx-frames have been received or after rx-usecs time interval if fewer than rx-frames have been received within the interval. For low latency applications, set rx-usecs to a smaller value. For bulk traffic, use larger values of rx-usecs and control the rate with rx-frames.

rx-frames-irq controls the maximum number of RX packets processed with a single RX interrupt.

[igmar]

Je bent er denk ik al uit, maar er zijn wat distro's die de IRQ's beperken tot 1 cpu.
In /proc/irq/<num>/smp_affinity zou normaliter iets van f moeten staan. Als er iets van 1 oid staat betekend dat je irq's door een beperkt aantal cores worden afgehandeld.
Ik heb standaard irqbalance aanstaan, over het algemeen werkt dat best OK.
De laatste is idd Coalesce, en die had je al gevonden

[eddie4nl]

Ja het heeft geholpen. De IRQ's zijn nu 1000/s aantal verbonden gebruikers is met 20% gestegen maar ik vermoed dat ik toch echt tegen de grenzen van de hardware ben aangelopen dus ik heb ook een nieuwe server besteld.

2 miljoen gebruikers op een atom n2800 is gewoon niet haalbaar. Dus ik heb besloten wat dieper in de beudel tetasten en een fatsoenlijke server te huren.

In iedergeval bedankt