Verzeihen Sie mir, wenn dies nicht das beste Forum für diese Frage ist, aber es scheint für den Kernel relevanter zu sein als für die Programmierung selbst.
Ich schreibe ein Skript, das das System nach offenen Ports abfragt, damit wir die Statistiken grafisch darstellen und überwachen können. Dafür verwende ich den „ss“-Befehl aus dem iproute-Paket. Wenn Sie ss -s|grep estab
ausführen Sie erhalten eine Ausgabe ähnlich der folgenden:
TCP: 296 (estab 6, closed 238, orphaned 0, synrecv 0, timewait 238/0), ports 0
Meine Frage hat mit der Timewait-Variablen zu tun, die die berechneten Sockets im TIME_WAIT-Zustand anzeigt. Als ich versuchte herauszufinden, auf welche Zahl nach dem Schrägstrich verwiesen wurde, wurde die Suche nach dem Quellcode zu einem Wirbelwind-Abenteuer, das mich schließlich dazu brachte, das folgende Snippet zu finden:
printf("TCP: %d (estab %d, closed %d, orphaned %d, synrecv %d, timewait %d/%d), ports %d\n",
s.tcp_total + slabstat.tcp_syns + s.tcp_tws,
sn.tcp_estab,
s.tcp_total - (s.tcp4_hashed+s.tcp6_hashed-s.tcp_tws),
s.tcp_orphans,
slabstat.tcp_syns,
s.tcp_tws, slabstat.tcp_tws,
slabstat.tcp_ports
);
Ich muss zugeben, dass meine Suche danach, was „slabstat“ bedeuten sollte, letztendlich dazu führte, dass ich etwas über die Slab-Caches und ihre Berichtsschnittstelle unter /proc/slabinfo.
erfuhrDie Frage:Was hat der Slabtable mit TIME_WAIT Sockelberechnungen zu tun? Ich kann nicht herausfinden, warum diese Zahl gemeldet wird, da jedes Mal, wenn ich den Befehl auf allen Servern ausgeführt habe, auf denen ich ihn ausprobiert habe, die Zahl immer Null war.
Akzeptierte Antwort:
Es sieht aus wie tcp_tw_buckets
wird letztendlich abgefragt, eine Struktur, die seit Linux 2.6.12
Die letzte Zahl wäre also wahrscheinlich immer 0, es sei denn, es handelt sich um 7 Jahre alte Kernel.
Was das Abfragen von Slab betrifft, so ist es, soweit ich das beurteilen kann, lächerlich schneller als die anderen verfügbaren Methoden.