☰

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

tag-icon • tag-icon linux kernel networking tcp
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_maxnet.core.wmem_maxnet.ipv4.tcp_rmemnet.ipv4.tcp_wmem

私の質問：各キューにいくつのエントリがあるかどうかをどうやって確認できますか？通常、人々はこの値を非常に高く設定しますが、私はこれらのキューサイズを記録して将来のエラーを予測し、ユーザーに明確な方法で表示される前に問題を特定するのに役立ちました。

答え1

私もこれが気になりましたが、様の質問に感動しました！

リストされている各キューについてどのような情報を取得できるか、および各キューに関連するいくつかの情報を収集しました。フィードバック/フィードバックを歓迎します。モニタリングが改善されると、管理が容易になります！

ネットワークコア.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.ファイルの最大値

から：

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

このツリー（build / time_wait / fin_wait / etc）に表示されているすべての状態の統計を収集することも興味深いかもしれません。

TCP-MIB::tcpConnState.*

ネットワークコア.rmem_max

ネットワークコア.wmem_max

setockopt 要求を受け取るには、システムを 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を使用してそのデータを取得できるようです。ここにいるRed Hat リファレンスマニュアル（PDF）まだ一つあります。初心者ガイド（PDF）

このツールは、そのデータを取得できるほど一般的に見えます。特に、probe::netdev.rx着信項目に関する情報を提供できるようです。バッファ内のキューの正味サイズを探すか、何かが残っているものを計算するだけです。キュー…

関連情報