web-dev-qa-db-ja.com

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

トラブルシューティングやチューニングの過程で、次の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以外は、いつ混乱するかという重要なつまみのようです高レベルの並行性のためにボックスを調整しています。

私の質問：各キューにアイテムがいくつあるかを確認するにはどうすればよいですか？通常、ユーザーはそれらを非常に高い値に設定しますが、これらのキューサイズをログに記録して、将来の失敗を予測し、ユーザーが気付く前に問題を見つけられるようにしたいと思います。

linuxkernelnetworkingtcp
41
Colin Hostert

私もこれを疑問に思い、あなたの質問に動機を与えられました！

あなたがリストした各キューにどれだけ近づくことができるかを収集し、それぞれに関連するいくつかの情報を示しました。私はコメント/フィードバックを歓迎します。監視の改善により、管理が容易になります！

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
29
polynomial

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

このツールは、そのデータ、特にprobe::netdev.rxは、着信エントリに関する情報を提供するもののように見えます。これで、バッファ内のキューの正味サイズ、またはキューから出ていくものをカウントするもののいずれかを「のみ」見つける必要があります…

2
Paweł Brodacki