ich habe eine Software auf einem Linux-Server laufen, die auf einer Netzwerkkarte ankommende Multicast-Datagramme einliest, diese analysiert und bei bestimmtem Inhalt auf einer bestehenenden TCP-Verbindung eine Aktion ausführt. Die Software besteht aus 3 Komponenten (3 Prozesse), die untereinander per Unix-Domainsocket kommuniziert. Die ankommenden Datagramme und die Aktion per TCP-Verbindung haben ein geringes Volumen, es geht hierbei also um die "low latency", nicht um "high volume". Der Server hat 16 CPUs (4 x Xeon Nehalems QuadCores) und die Netzwerkkarten sind 10 Gigabit Karten von Chelsio. Es ist Debian Lenny mit 2.6.26 installiert.
Nun habe ich mir bereits ff. Kernel-Parameter angeschaut, mit denen man "herumexperimentieren" kann:
tcp_sack - BOOLEAN
tcp_low_latency - BOOLEAN
tcp_timestamps - BOOLEAN
ipv4.tcp_rmem
ipv4.tcp_wmem
Ferner könnte die Interrupt-Vergabe eine Rolle spielen, aktuell laufen alle Interrupts über CPU 0. "irqbalance" scheint hier Abhilfe zu schaffen, aber Chelsio selbst rät davon ab, weil:
Code: Alles auswählen
On a system with multiple CPUs, the interrupt (IRQ) for the network
controller may be bound to more than one CPU. This will cause TCP
retransmits if the packet data were to be split across different CPUs
and re-assembled in a different order than expected.Die nächsten interessanten Baustellen sind anscheinend die "Coalesce Parameters" der Netzwerkkarte bzw. des Treibers, hat Jemand Erfahrungswerte beim "rx-usecs" (ethtool -c <device>) ?
Bleibt evtl. noch die Frage, ob die 3 Prozesse (s.o.) an einzelnen CPUs "gebunden" werden sollten, so dass sie beim Wechsel vom State "S" zum "R" (Running) nicht jedes Mal auf einer anderen CPU landen (siehe dazu auch diesen Thread).
Für Ideen und Vorschläge wäre ich sehr dankbar,
Gruss, mistersixt.
