"Listen queue overflow" analysieren

SolarCatcher

Well-Known Member
Hallo,

ich werde nicht schlau daraus: Seit einigen Wochen sehe ich fast täglich in den /var/log/messages eines Servers Meldungen wie diese
Code:
Mar 29 00:12:44 meinserver kernel: [1582194] sonewconn: pcb 0xfffff804803f63a0: Listen queue overflow: 76 already in queue awaiting acceptance (3 occurrences)

Jetzt könnte ich natürlich einfach die Anzahl der erlaubten Verbindungen hochsetzen. Aber eigentlich will ich ja schon wissen, welcher Dienst in welcher Jail hier die Ursache ist. Ich bin daher nach dem in einem Blog-Post beschriebenen Weg vorgegangen und habe anhand der PCB ID versucht, den Verursacher mit "netstat -aAn" zu identifizieren. Leider stets ohne Erfolg.

Ich dachte zunächst, dass es daran läge, dass die verursachende Prozess möglicherweise schon wieder eine andere PCB ID hat (was ich mittlerweile für unwahrscheinlich halte, weil die ID in der o.g. Kernel message oft über Stunden oder sogar mehr als einen Tag konstant bleiben). Ich habe sogar einen Cron angelegt, der minütlich netstat nach der letzten in /var/log/messages genannten PCB ID durchsucht und in einem Logfile abspeichert (kann man vermutlich einfacher machen... aber viele Wege führen nach Rom):
Code:
netstat -aAn | grep `grep 'Listen queue overflow' /var/log/messages | tail -n1 | grep -o '0xffff[^\:]*' | grep -o 'ffff[^\:]*'` >> /var/log/listenQueueOverflow.log

Hat jemand eine andere Idee, wie ich herausfinde, wer/wo/was die Ursache für die Listen Queue Overflow ist?

Nur der Vollständigekeit halber: Das System ist ein HardenedBSD 11-STABLE - sollte sich also ansich wie ein 11er FreeBSD verhalten. Zumindest für den Weg der Fehleranalyse.
 
Nein, aber ich wüsste auch nicht, wie ich damit weiterkomme: Die PCB ID ist das einzige Merkmal, das ich von dem verursachenden Prozess kenne. Aber ich sehe nicht, dass ich die auch in sockstat auslesen könnte. Gibt es ein Tool, das PCB ID und Process ID listet? Darüber könnte man dann vielleicht die Kernel Message mit sockstat verbinden...?
 
@KobRheTilla Mit "netstat -aAn" hatte ich es ja schon versucht... wie im Eingangspost geschrieben, gabs damit nie Treffer. Auch nicht beim minütlichen Abfragen.

Daher schlug @das.chaos vor, es mal mit sockstat zu probieren. Aber dazu brächte ich die PID des Prozesses... die liefert mir Dein Vorschlag aber auch nicht.

Aber noch eine andere Frage: Das "l" in "netstat -Al" macht, dass die IP "lang" ausgeschrieben wird? Ich kann zu dem Parameter nämlich nix in der Manpage finden.
 
Das "l" in "netstat -Al" macht, dass die IP "lang" ausgeschrieben wird? Ich kann zu dem Parameter nämlich nix in der Manpage finden.
Weiß jetzt nicht ob das ein großes "i" oder ein kleines "L" ist, aber:

Großes " i "
Code:
-I interface
  Show information about the specified interface; used with a wait
  interval as described below.

  If the -f address_family option (with the -s option) is present,
  show per-interface statistics on the given interface for the
  specified address_family.


Kleines " L "
Code:
-l  With the default display, show only listening sockets.  With the
   -g option, display wider fields for the IPv6 multicast routing
    table "Origin" and "Group" columns.

Falls ich die Frage falsch verstehe, sorry :)
 
Das "l" in "netstat -Al" macht, dass die IP "lang" ausgeschrieben wird?
Das stand mal für listening sockets, ich merke gerade, dass es das nicht mehr tut. Warscheinlich ein Linuxism, den ich mir mal gemerkt habe.

Ein Tipp, der nun anders herum funktioniert:
Code:
# netstat -aL

zeigt die dir Sockets und deren Queue-Länge an.
Damit kannst du auf das Programm schließen, beim Erreichen des letzten Werts wird die Warnung erzeugt.

Rob
 
Aber dazu brächte ich die PID des Prozesses... die liefert mir Dein Vorschlag aber auch nicht.

Das Mapping PID<->PCB kannste mittels fstat prüfen:

Code:
# netstat -A | grep ssh
fffff80cec715408 tcp4       0     56 ?.?.?.?.ssh   ?.?.?.?.29863    ESTABLISHED

Code:
# fstat |grep fffff80cec715408
root     sshd       10036    3* internet stream tcp fffff80cec715408

Rob
 
Ich fing an mich durch den Quellcode zu graben [da interessantes Problem] und entdeckte gerade dieses Tool in
Code:
/usr/src/tools/regression
mitunter wird struct tcpstat{} benutzt, um "queue overflows" zu tracken, wobei ich mir noch nicht wirklich sicher bin, ob ich damit ins Klo gegriffen haette, da netstat(1). :)
 
Zuletzt bearbeitet von einem Moderator:
Der "Queue overflow" tritt [bei oberflaechlicher Betrachtung] im Zusammenhang mit sonewconn(9) auf, wenn von dieser Funktion aufgerufene ratecheck(9) mMn feststellt, dass das zeitliche Limit bzgl. dem Akzeptieren eingehender Verbindungen ueberschritten wurde bzw. nicht garantiert werden kann, das genuegend Ressourcen existieren, die fuer das Enqueueng von eingehenden Dienstelementen [per mbuf(9) gekapselter Pakte bzw. Segmente oder Datagramme] ueberschritten wurde, wobei ich mir noch nicht sicher bin, da zu wenig Erfahrung bzgl. dem Administrieren von Produktivsystemen [und noch am "interpretieren" des Quelltextes bin bzw. mich mit heiterem Ri-Ra-Ratespiel beschaeftige, weil die Funktion gerade grob ueberflog].

Kann sein, dass mehr eingehende Verbindungen existieren, als das System ueber Socket-Layer verarbeiten kann und sich [moeglicherweise deswegen] das System weigere, einen socket(9) zu allokieren?.

*ganz weit aus dem Fenster lehn, da kein IT Professional* :)
 
Die Meldung tritt auf, wenn ein - meist single-threaded - Prozess, die für ihn vorgesehenen connections nicht abrufen kann. Wir hatten das ganz massiv mit redis Prozessen, bevor wir sie in einzelnen Instanzen gestartet haben. Hast du was in der Richtung laufen?

Edit: oder du startest einen Prozess neu, während sehr viel traffic eintrifft, dann passiert sowas auch schon mal, weil der host versucht, alles eintreffenden zu queuen, was er allerdings nicht mehr schafft.
 
https://redis.io ist gemeint. Aber Sockets zu nutzen ist in unserer Konstellation nicht möglich ;).
Wie schon erwähnt ist meist der dahinter laufende Prozess der Flaschenhals und nicht das Betriebssystem, dass die Verbindungen nicht an den Prozess übergeben kann.
 
Thx, Redis kannte ich noch nicht und jetzt verstehe ich es, was das Problem ist bzw. jetzt habe ich was gelernt [und es noch nicht so gesehen, dass der Prozess ja auch seine "Constraints" bzw. zeitliche Limit bzgl. dem Verarbeiten von Messages haette, was ich nicht in einer "idealen" Welt, wo alles supi ist, bedachte]. :)
 
Zurück
Oben