我也对此感到奇怪,并且受到您的提问的启发!
我已经收集了与列出的每个队列的距离以及与每个队列相关的一些信息,这距离我有多近。我欢迎提出意见/反馈,对监视的任何改进都会使事情更易于管理!
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