rxリング、max_backlog、max_syn_backlogサイズを確認する方法

41

トラブルシューティングとチューニングの過程で、次のLinuxカーネル設定について考えていることがよくあります。

net.core.netdev_max_backlog
net.ipv4.tcp_max_syn_backlog
net.core.somaxconn

以外にもfs.file-max、net.ipv4.ip_local_port_range、net.core.rmem_max、net.core.wmem_max、net.ipv4.tcp_rmem、そしてnet.ipv4.tcp_wmem、彼らはあなたが、並行性の高いレベルのボックスをチューニングしているときと混乱に重要ノブのようです。

私の質問：各キューにあるアイテムの数を確認するにはどうすればよいですか？通常、人々はそれらを非常に高く設定しますが、将来の障害を予測し、問題がユーザーに顕著に現れる前に問題をキャッチできるように、これらのキューサイズを記録したいと思います。

— コリン・ホスタート
ソース

これは素晴らしい質問です。インキャストの問題と高解像度のTCP再送信に興味があります。

— dhchdhd

29

私もこれを疑問に思っており、あなたの質問に動機付けられました！

リストした各キューにどれだけ近いかを、それぞれに関連する情報とともに収集しました。コメント/フィードバックを歓迎します。監視を改善すると、管理が容易になります。

net.core.somaxconn

net.ipv4.tcp_max_syn_backlog

net.core.netdev_max_backlog

$ netstat -an | grep -c SYN_RECV

キュー内の接続の現在のグローバルカウントを表示します。これをポートごとに分割し、監視アプリケーションからポーリングする場合は、これをsnmpd.confのexecステートメントに入れることができます。

から：

netstat -s

これらは、キューからのリクエストを見ている頻度を示します。

146533724 packets directly received from backlog
TCPBacklogDrop: 1029
3805 packets collapsed in receive queue due to low socket buffer

fs.file-max

から：

http://linux.die.net/man/5/proc

$ cat /proc/sys/fs/file-nr
2720    0       197774

この（読み取り専用）ファイルは、現在開いているファイルの数を示します。割り当てられたファイルハンドルの数、空きファイルハンドルの数、およびファイルハンドルの最大数の3つの数字が含まれています。

net.ipv4.ip_local_port_range

サービスの除外リストを作成できる場合（netstat -an | grep LISTEN）、一時的なアクティビティに使用されている接続の数を推測できます。

netstat -an | egrep -v "MYIP.(PORTS|IN|LISTEN)"  | wc -l

監視する必要があります（SNMPから）：

TCP-MIB::tcpCurrEstab.0

このツリーで見られるすべての状態に関する統計を収集することも興味深いかもしれません（established / time_wait / fin_wait / etc）：

TCP-MIB::tcpConnState.*

net.core.rmem_max

net.core.wmem_max

setsockoptリクエストのためにシステムをdtrace / straceする必要があります。そうでなければ、これらのリクエストの統計が追跡されるとは思いません。これは、私の理解から変わる値ではありません。デプロイしたアプリケーションは、おそらく標準量を要求します。アプリケーションをstraceで「プロファイル」し、それに応じてこの値を構成できると思います。（議論する？）

net.ipv4.tcp_rmem

net.ipv4.tcp_wmem

制限にどれだけ近づいているかを追跡するには、（定期的に）tx_queueフィールドとrx_queueフィールドの平均と最大を確認する必要があります。

# cat /proc/net/tcp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                                                     
   0: 00000000:0FB1 00000000:0000 0A 00000000:00000000 00:00000000 00000000   500        0 262030037 1 ffff810759630d80 3000 0 0 2 -1                
   1: 00000000:A133 00000000:0000 0A 00000000:00000000 00:00000000 00000000   500        0 262029925 1 ffff81076d1958c0 3000 0 0 2 -1

これに関連するエラーを追跡するには：

# netstat -s
    40 packets pruned from receive queue because of socket buffer overrun

グローバルな「バッファ」プールも監視する必要があります（SNMP経由）：

HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: Memory Buffers
HOST-RESOURCES-MIB::hrStorageSize.1 = INTEGER: 74172456
HOST-RESOURCES-MIB::hrStorageUsed.1 = INTEGER: 51629704

— 多項式
ソース

2

SystemTapでそのデータを取得できる可能性があると思います。こちらがRedhatリファレンスマニュアル^（pdf）です。あり、初心者ガイド^（PDF）は。

このツールは、そのデータを取得するのに十分な汎用性があり、特にprobe::netdev.rx着信エントリに関する情報を提供するもののように見えます。今では、バッファ内のキューのネットサイズ、または物事を数えるもののいずれかを見つける必要がありますキューを離れる…

— パウェウ・ブロダッキ
ソース