受け入れキューの長さを監視するにはどうすればよいですか？

私の仮説があります。TCP接続が、サーバーが到達できるよりも速く到達することがありaccept()ます。キューがオーバーフローし、問題が発生するまでキューに入れられます。

これが起こっていることをどのように確認できますか？

受け入れキューの長さまたはオーバーフローの数を監視できますか？どこかに露出しているカウンターはありますか？

linux networking monitoring

— フィル・フロスト
ソース

あなたが探していnetstatます。

— 桂佐藤

私の知るnetstat限り、送信キューと受信キューの長さのみを表示していますが、これは受け入れキューとは異なります。

— Phil Frost

ええ、デフォルトでは表示されません。man netstat | less +/Flags

— 桂佐藤

これらのフラグがどのように受け入れキューの長さを教えてくれるのかわかりnetstatません-実際にはFlags、TCP接続ではまったく表示されないようです。接続は以下のように示されているように少しテストから、それが見えるESTABLISHED中netstat、私が行うプロセスへの接続を開いてみてください場合でも、listen()決してaccept()。

— Phil Frost

ソースを見ると、これらのフラグはUNIXソケット用であるようです。TCPの場合でも、数えるだけSYN_RECVです。それ以外のキューはありません。ハーフオープン接続が多すぎるため、ドロップされたパケットをログに記録するようにカーネルに何らかの方法で指示できると思いますが、Linuxとのネットワーキングを調べてから10年以上経過しているため、その方法がわかりません。余談ですがaccept()、あなたはその仕事をするのを待っているのではなくACK、接続しているホストからが到着して接続を完了するのを待っています。

— 佐藤桂2016

回答:

キューがオーバーフローしているかどうかを確認するには、netstatまたはnstatを使用します

[centos ~]$ nstat -az | grep -i listen
TcpExtListenOverflows           3518352            0.0
TcpExtListenDrops               3518388            0.0
TcpExtTCPFastOpenListenOverflow 0  0.0

[centos ~]$ netstat -s | grep -i LISTEN
    3518352 times the listen queue of a socket overflowed
    3518388 SYNs to LISTEN sockets dropped

リファレンス：https : //perfchron.com/2015/12/26/investigating-linux-network-issues-with-netstat-and-nstat/

キューサイズを監視するには、ssコマンドを使用してSYN-RECVソケットを探します。

$ ss -n state syn-recv sport = :80 | wc -l
119

リファレンス：https : //blog.cloudflare.com/syn-packet-handling-in-the-wild/

— lfmunoz
ソース

Sysdigは、この情報の一部を各acceptsyscall の最後にqueuelen引数として提供します。キューの長さもと表示されqueuemaxます。

7598971 21:05:30.322229280 1 gunicorn (6451) < accept fd=13(<4t>127.0.0.1:45882->127.0.0.1:8003) tuple=127.0.0.1:45882->127.0.0.1:8003 queuepct=0 queuelen=0 queuemax=10

私の知る限り、キューがオーバーフローした時期または回数を正確に知るメカニズムはありません。そしてこれを定期的なモニタリングcollectdなどと統合するのは面倒です。

— フィル・フロスト
ソース

あなたが探しているのは、sysctl -aコマンドの出力のエントリです:::

net.ipv4.tcp_max_sync_backlog = 4096

上記の例の場合、SYN状態の接続のバックログは最大4096です。サーバーのRAMの量に基づいて増やすことができます。負荷の高いWebサーバーのチューニングには、32Kバックログが適切な出発点と考えています。

また、以下が1に設定されていないことを確認してください。

net.ipv4.tcp_abort_on_overflow = 0

それ以外の場合は、バックログのオーバーフローが発生すると、必ずパケットがドロップされます。

簡単に確認できます

「sysctl -a | egrepバックログ」

「sysctl -a | egrepオーバーフロー」

さらに、「ドロップ」ラベルが

「ifconfig -a」

コマンドの出力。これは、他のデータやエラーなどとともに、各インターフェイスでドロップされたパケット数を示しています。

ドロップされたパケットのロギングについては、RHEL 7に有料の記事があります::

https://access.redhat.com/solutions/1191593

さらなる研究のためにあなたは読むかもしれません：

http://veithen.io/2014/01/01/how-tcp-backlog-works-in-linux.html

Steven's Book Illustrated TCP / IPによると、次のように述べられています。

「キュー制限は、[…]不完全な接続キューのエントリ数[…]と[…]完了した接続キューのエントリ数[…]の合計に適用されます。 "

したがって、次のようにも述べられています。

「完了した接続キューはほとんど常に空です。これは、エントリーがこのキューに置かれると、サーバーが受け入れるための呼び出しが戻り、サーバーが完了した接続をキューから削除するためです。」

したがって、受け入れキューは完全に空のように見える可能性があり、（この場合は）Web Apacheサーバーを調整して、「総計」キューに配置された接続をより速く受け入れる必要があります。

— mkzia
ソース

ここに役立つ情報があるようですが、それが質問に答えているかどうかはわかりません。「この講堂に一度に参加したことのある人の最大数は何人ですか？」と質問し、最大容量を提供する壁の看板を指していても、質問に答えていません。

— Scott

実際、私はキューの最大長ではなく、現在のキューの長さを探しています。

— Phil Frost

あなたの答えのようにtcp_max_SYNC_backlogではなく、tcp_max_syn_backlogである必要があります

— DevilaN

ええと...そしてStackOverflowはそれを変更しようとすると遅延したエラーメッセージを表示します：「編集は少なくとも6文字でなければなりません;この投稿で何か他に改善することはありますか？」

— Aaron C. de Bruyn