Wir machen viel Gebrauch vom Multicasting-Messaging über viele Linux-Server in einem LAN. Dabei kommt es immer wieder zu Verzögerungen. Wir senden im Grunde eine enorme Anzahl kleiner Pakete. Wir machen uns mehr Sorgen um die Latenz als um den Durchsatz. Bei den Maschinen handelt es sich durchweg um moderne Multi-Core-Maschinen (mindestens vier, in der Regel acht, 16, wenn man Hyperthreading mitzählt), immer mit einer Auslastung von 2,0 oder weniger, normalerweise mit einer Auslastung von weniger als 1,0. Auch die Netzwerkhardware ist zu weniger als 50 % ausgelastet.
Die Verzögerungen, die wir sehen, sehen aus wie Warteschlangen-Verzögerungen: die Pakete beginnen schnell an Latenz zuzunehmen, bis es so aussieht, als würden sie sich stauen, und kehren dann wieder zum Normalzustand zurück.
Die Nachrichtenstruktur ist im Wesentlichen wie folgt: Im "Sende-Thread" ziehen Sie Nachrichten aus einer Warteschlange, fügen einen Zeitstempel hinzu (mit gettimeofday() ), dann rufen Sie send() . Das empfangende Programm empfängt die Nachricht, stempelt den Empfangszeitpunkt und schiebt sie in eine Warteschlange. In einem separaten Thread wird die Warteschlange abgearbeitet und die Differenz zwischen Sende- und Empfangszeitstempel analysiert. (Beachten Sie, dass unsere internen Warteschlangen nicht Teil des Problems sind, da die Zeitstempel außerhalb unserer internen Warteschlangen hinzugefügt werden).
Wir wissen nicht wirklich, wo wir mit der Suche nach einer Antwort auf dieses Problem beginnen sollen. Wir sind mit den Interna von Linux nicht vertraut. Unser Verdacht ist, dass der Kernel die Pakete in eine Warteschlange stellt oder puffert, entweder auf der Sende- oder auf der Empfangsseite (oder beides). Aber wir wissen nicht, wie wir das herausfinden und verfolgen können.
Wir verwenden CentOS 4.x (RHEL-Kernel 2.6.9), um es kurz zu machen.
