平均负载随防火墙吞吐量增加

平均负载随防火墙吞吐量增加

我刚刚对我的后端代码进行了一次大的修改,我注意到自从修改之后的几个小时内平均负载大幅增加。我查看了 Munin 以找出问题所在,我注意到,除了平均负载之外,防火墙吞吐量也大幅增加:

防火墙吞吐量

这伴随着 CPU 使用率、中断和平均负载的增加,为了完整性我在这里添加了这些内容:

中央处理器

中断

平均负载

有人知道这里发生了什么吗?我立即想到的是代码的更改给数据库(PostgreSQL)带来了更多负载,但我找不到防火墙吞吐量增加的原因。流量保持不变,唯一的区别是在 Gunicorn 下运行的 Python 代码。在htopCPU 占用最高的进程中,Gunicorn 和 Postgres 之间发生了变化,就像以前一样(表明 Postgres 并没有突然成为 CPU 占用大户)。

编辑:这是输出iptables -L -n -v

Chain INPUT (policy ACCEPT 298K packets, 357M bytes)
 pkts bytes target     prot opt in     out     source               destination
 7705  516K fail2ban-ssh  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 22

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 296K packets, 372M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain fail2ban-ssh (1 references)
 pkts bytes target     prot opt in     out     source               destination
   17  1720 REJECT     all  --  *      *       58.218.201.19        0.0.0.0/0            reject-with icmp-port-unreachable
   16  1228 REJECT     all  --  *      *       210.45.250.3         0.0.0.0/0            reject-with icmp-port-unreachable
 7583  505K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

更新:我重新启动了整个服务器,平均负载回升到 7 左右,所以我想这意味着我可以排除在数据库模式更改后缓存中有旧数据的问题。

答案1

munin 插件的名称有点不幸,因为它实际上并不测量与防火墙直接相关的任何内容;它显示系统在任何接口上接收了多少个数据包,以及通过系统转发了多少个数据包。因此,您有多少防火墙规则(如果有的话!)并不重要。它检查文件/proc/net/snmp并监视“Ip:”行的第 3 和第 6 个字段。

您是通过 tcp/ip 还是通过 unix 域套接字与 postgreSQL 服务器通信?如果是通过 tcp/ip,则可能是由于更改中的某些错误导致查询被执行了两次。否则,您将不得不进一步研究这些额外的传入数据包来自何处。

相关内容