iprouteパッケージの「ss」コマンド、スラブテーブルのタイムウェイトソケットを照会するのはなぜですか?

iprouteパッケージの「ss」コマンド、スラブテーブルのタイムウェイトソケットを照会するのはなぜですか?

この質問に関する最高のフォーラムでない場合は、許してください。しかし、プログラミング自体よりもカーネルに関連しているようです。

グラフを表示して統計を監視できるように、システムに開いているポートを照会するスクリプトを作成しています。これを行うには、iprouteパッケージの「ss」コマンドを使用します。実行すると、ss -s|grep estab次のような出力が表示されます。

TCP:   296 (estab 6, closed 238, orphaned 0, synrecv 0, timewait 238/0), ports 0

私の問題は、ソケットがTIME_WAIT状態として計算されたことを示すtimewait変数に関連しています。スラッシュの後にどの番号が参照されているかを調べようとしたときに、ソースコードを検索するための旋回風の冒険に変わり、最終的に次のコードを見ました。

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
       );

私は "slabstat"の意味を検索し、最終的に/proc/slabinfoにあるslabキャッシュとその報告インターフェースを知っていることを認めなければなりません。

質問:slabtableはTIME_WAITソケット計算とどのように関連していますか?試行しているすべてのサーバーでコマンドを実行するたびに、数値が常にゼロであるため、この番号が報告される理由はわかりません。

ベストアンサー1

tcp_tw_buckets結局、ポーリングされたのはLinux 2.6.12から削除された構造だったようです。

したがって、7年後のカーネル以外の最後の数字は常にゼロになります。

スラブクエリについては、私が知っている限り、他の方法よりはるかに高速です。

おすすめ記事