我刚刚对我的后端代码进行了一次大的修改,我注意到自从修改之后的几个小时内平均负载大幅增加。我查看了 Munin 以找出问题所在,我注意到,除了平均负载之外,防火墙吞吐量也大幅增加:
这伴随着 CPU 使用率、中断和平均负载的增加,为了完整性我在这里添加了这些内容:
有人知道这里发生了什么吗?我立即想到的是代码的更改给数据库(PostgreSQL)带来了更多负载,但我找不到防火墙吞吐量增加的原因。流量保持不变,唯一的区别是在 Gunicorn 下运行的 Python 代码。在htop
CPU 占用最高的进程中,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,则可能是由于更改中的某些错误导致查询被执行了两次。否则,您将不得不进一步研究这些额外的传入数据包来自何处。