如何检查 rx ring、max_backlog 和 max_syn_backlog 大小

Question

在故障排除和调整过程中，我经常发现自己在考虑以下 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，当您为高并发性调整一个盒子时，它们似乎是要弄乱的重要旋钮。

我的问题：如何检查每个队列中有多少项目？通常人们只是将它们设置得非常高，但我想记录这些队列大小以帮助预测未来的故障并在问题以用户明显的方式表现出来之前捕获它们。

Answer 1

我也想知道这一点，并被你的问题所激励！

我已经收集了我与您列出的每个队列的接近程度，并提供了一些与每个队列相关的信息。我欢迎评论/反馈，对监控的任何改进都会使事情更容易管理！

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

这个（只读）文件给出了当前打开的文件数。它包含三个数字：分配的文件句柄数、空闲文件句柄数和最大文件句柄数。

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

收集有关此树中看到的所有状态的统计信息也可能很有趣（已建立/time_wait/fin_wait/etc）：

TCP-MIB::tcpConnState.*

net.core.rmem_max

net.core.wmem_max

您必须对您的系统进行 dtrace/strace 以获取 setsockopt 请求。我认为不会以其他方式跟踪这些请求的统计信息。这并不是一个真正改变我的理解的价值。您部署的应用程序可能会要求标准金额。我认为您可以使用 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