我有非常繁忙的Web服务器,我想介绍一些分析,看看什么样的流量存在。即,所有连接的总数、等待时间、已建立的连接、udp和tcp连接。
首先,我制作了一个简单的图表--通过以下方式读取/proc/sys/net/netfilter/nf_conntrack_count
,只显示连接的总数:
$ cat /proc/sys/net/netfilter/nf_conntrack_count 1994
所有东西都很好地显示在图表中,所以我给它介绍了更多的细节。现在使用类似的命令处理/proc/net/nf_conntrack
并将其放置到适当的监视中:
$ grep -c tcp /proc/net/nf_conntrack 1273 $ grep -c udp /proc/net/nf_conntrack 49
对nf_conntrack进行分析,使其每分钟运行一次。最初,所有的东西都被正确地显示出来了,所以我把它放了一天。
第二天,我注意到连接总数(/proc/sys/net/netfilter/nf_conntrack_count
)出现了巨大的下降和重弹,这对于Web服务器来说是不正常的,每隔几分钟就会发生一次。经过多次测试和故障排除,我终于找到了神秘背后的原因。
我已经安装了终端watch -n0 "cat /proc/sys/net/netfilter/nf_conntrack_count"
(查看几乎实时的连接数),第二次我只做了cat /proc/net/nf_conntrack
,一旦按enter键,nf_conntrack_count
从1993年到1411年大幅下降,然后在2-3秒内恢复到“正常”值。尝试使用cp
、grep
、conntrack -L -p tcp
等,每次我运行命令时都会出现这样的情况。
基本上,每次阅读/proc/net/nf_conntrack
- -巨大的、暂时的、/proc/sys/net/netfilter/nf_conntrack_count
的下降--而监控有时会选择低值(S)并将其表示在图表中。
此外,我注意到cat nf_conntrack
和conntrack -L
的结果有很大的不同。此外,nf_conntrack中的行数与nf_conntrack_count不同。内核是v4.19.5。在这两个命令中,每件事情都是可见的,分别部署了3秒钟:
[07:30:14] root@web1(~)$ wc -l /proc/net/nf_conntrack; \
cat /proc/sys/net/netfilter/nf_conntrack_count
1236 /proc/net/nf_conntrack
1575
[07:30:18] root@web1(~)$ cat /proc/sys/net/netfilter/nf_conntrack_count;\
wc -l /proc/net/nf_conntrack
2009
1191 /proc/net/nf_conntrack
我的问题是,这里到底发生了什么,为什么会发生这种情况(下降),为什么列表中的文件之间存在差异,以及如何防止这种下降?
发布于 2018-12-11 17:28:37
我尝试在我们的生产服务器上使用grep -c tcp /proc/net/nf_conntrack
和watch -n0 "cat /proc/sys/net/netfilter/nf_conntrack_count"
进行同样的测试,生产服务器运行的是内核3.10.0-693.21.1.el7.x86_64的CentOS 7.4.1708,我无法确定您所面临的问题是相同的。
试着发送至少您的内核版本,也许使用相同版本运行服务器的人也可以对其进行测试。
一个可能发生的想法是,在使用grep时,您遇到了一些系统内存或CPU限制,这对nf_conntrack产生了影响。你可以试着跑。nice -n19 grep -c tcp /proc/net/nf_conntrack
,并使用ulimits或cgroup来控制RAM。另一个想法是尝试谷歌的内核版本或nf_conntrack版本结合您的问题定义。这可能是个错误,但不太可能。
发布于 2018-12-16 20:38:13
总的来说,我认为这取决于您的内核版本和您正在跟踪的连接的数量。IIRC,内核需要获得一些锁才能生成和/proc/net/nf_conntrack,这可能是您看到下降的原因。
更好的方法是使用conntrack
实用程序,它使用netlink
获取信息,并且不会遇到相同的问题。
https://serverfault.com/questions/943866
复制相似问题