UDP-Paket fällt vom linux-kernel
Ich habe einen server schickt UDP-Pakete via multicast und eine Reihe von Kunden, die Auflistung auf diejenigen, die multicast-Pakete.
Jedes Paket hat eine Feste grösse von 1040 Bytes, die ganze Größe der Daten, die vom server gesendet wird 3GByte.
Meinem Umfeld ist es folgendermaßen:
1-Gbit-Ethernet-Netzwerk
40 Knoten, 1 Sender-Knoten und 39 Empfänger-Knoten.
Alle Knoten haben die gleiche hardware-Konfiguration: 2 AMD-CPUs, jede CPU hat 2 Kerne @2,6 GHz
Auf der client-Seite, einen thread liest die Steckdose und legen Sie die Daten in eine queue. Einen weiteren thread öffnet, die Daten aus der queue und hat etwas Licht-Gewicht-Verarbeitung.
Während der multicast-übermittlung erkenne ich eine packet-drop-rate von 30% auf die node-Seite. Durch die Beobachtung der netstat –su Statistiken kann ich sagen, dass die fehlenden Pakete von der client-Anwendung entspricht der RcvbufErrors Wert aus der netstat-Ausgabe.
Das bedeutet, dass alle fehlenden Pakete verworfen, die von der OS, da der socket-buffer voll war, aber ich verstehe nicht, warum die Erfassung thread nicht Lesen können, die Puffer in der Zeit.
Während der übertragung, 2 der 4 Kerne werden genutzt um 75%, der rest ist schlafen.
Ich bin die einzige, die sich mit diesen Knoten, und ich würde davon ausgehen, dass diese Art von Maschinen ist kein problem zu handhaben 1Gbit Bandbreite. Habe ich bereits getan, einige Optimierungen, durch hinzufügen von g++ compiler-flags für amd-cpus, diese verringern die packet-drop-rate um 10%, aber es ist immer noch zu hoch meiner Meinung nach.
Natürlich weiß ich, dass UDP nicht zuverlässig ist, habe ich meine eigene Korrektur-Protokoll.
Ich habe keine Verwaltung von Berechtigungen, so ist es für mich nicht möglich, Systemparameter zu ändern.
Irgendwelche Tipps, wie kann ich die Leistung erhöhen?
BEARBEITEN:
Ich löste dieses Problem durch die Verwendung von 2 threads, die das Lesen der Steckdose. Die recv socket-buffer noch voll manchmal. Aber der Durchschnittliche Rückgang ist unter 1%, so dass es nicht ein problem, damit umzugehen.
InformationsquelleAutor viktorgt | 2012-06-05
Du musst angemeldet sein, um einen Kommentar abzugeben.
Aufspüren von Netzwerk-Tropfen auf Linux kann ein bisschen schwierig, da es viele Komponenten, von denen Paketverlust passieren kann. Sie können auftreten, die auf hardware-Ebene in das Netz Gerät, Teilsystem, oder in die Protokoll-Schichten.
Schrieb ich eine sehr detaillierten blog-post zu erklären, wie Sie zu überwachen und Stimmen die einzelnen Komponenten. Es ist ein bisschen schwer zu fassen, als eine kurze Antwort hier, da gibt es so viele verschiedene Komponenten, die überwacht werden müssen, und dann abgestimmt wird.
InformationsquelleAutor Joe Damato
Abgesehen von offensichtlichen Beseitigung alles nicht essentielle aus dem socket Lesen loop:
setsockopt(2),recvmmsg(2), wenn Ihr kernel es unterstützt, reduzieren sich die Anzahl der Systemaufrufe und kernel-userland Kopien,epoll(7),/proc/sys/net/core/rmem_max, & (2) dieoptvalfürsetsockoptistSO_RCVBUFInformationsquelleAutor Nikolai Fetissov
"Auf der client-Seite, einen thread liest die Steckdose und legen Sie die Daten in eine queue. "
Ich denke das problem ist in diesem thread. Es ist nicht das empfangen von Nachrichten schnell genug. Zu viel Zeit wird damit verbracht, auf etwas anderes, zum Beispiel den Erwerb von mutex, wenn Daten in der Warteschlange. Versuche zur Optimierung der Operationen auf der Warteschlange, wie zum Beispiel die Verwendung eines lock-free queue.
InformationsquelleAutor Mars Zhao