最近一段时间以来网站经常性提示无法访问，实际来看确实是io堵塞，有时候甚至需要重启实例，这两天邮件隔几分钟一个，不得不处理下这个问题。

首先怀疑的是Wordpress插件和主题开销过大，毕竟一来Google服务器繁忙的原因，总能看到建议来删除不必要的主题，以及减少插件使用。于是第一步便是删除主题，系统自带的主题从来没用过，删除并没有影响，包括几个不常用到的插件，重新启动服务，然而并没有反应，甚至这期间还因为CPU IO阻塞导致插件更新和禁用都失败了，不得不在非常卡顿的情况下重新启动了几次服务。

折腾了好一会并没有改善，apache仍然是一开始便占用大量资源，于是开始执行方案2:削减进程数。

修改httpd.conf中服务器进程/线程数量的设置，然后重启服务，仍然没有任何效果。瞬间进程就占满了，这个时候虽然意识到有点快，我还是以为这是正常现象。

来到第二天，起来就收到一长串的服务器失联-恢复的邮件，又来重新折腾。

既然原因是IO阻塞，就开始执行方案三：增加虚拟内存。

最早之前配置的时候并没有配置swap空间，大概是并没有必要，但是现在内存明显不足甚至IO阻塞，就不得不开始试下了，按照找到的教程配置了1GB的swap空间先做测试。

终于，在启动swap并重启服务后，io阻塞的问题缓解了，虽然内存余量很快的降下去，当时有swap空间可用，%wa没有再出现满载的情况了，新的问题出现了:CPU 不足，%id为0，而%st几乎为满，打开网站的速度肉眼可见的缓慢，虽然之前习惯了这个速度，怀疑可能是出口网络带宽的限制，现在看来实际可能是服务器自身的问题。

会不会是访问量过大的问题？Wordpress并没有实时链接状态的分析，于是用stat指令检查了服务器的链接数，wait和established的数量和总在100左右，这个数量我并没有什么直观的经验来判断它正不正常，但是，解决方案是有的。

因为DNS部署在Cloudflare，自然可以使用CF的服务，开始执行方案四：开启访问限制。

先将DNS设置改为网页代理模式，流量通过Cloudflare中转，然后开启所有能开启的防攻击功能。然后，重启服务（事后看这样可以刷掉现在的链接，强制重连）。

终于，apache重启后，并没有直接一堆服务占满，而是按正常无人访问的小站仅启动了一个空闲进程，几分钟过去了CPU保持在了完全空闲的状态，可以算是问题解决。

再回过来看Cloudflare，因为它有完整的访问日志，从Security-Analytics里面可以看到，Cloudflare帮我拦截了几乎99%以上的访问，而这些被拦截的访问全部来自154.213.179.28这个IP，可以查到是日本的一家网络服务商。

并不知道是出于什么原因，因为从一开始它没有直接像DDOS一样直接将服务器拉爆炸，因为我设置了流量过大直接关闭实例，它也并没有形成太大的流量，或许它只是几个月如一日的来攻击所有网络上的wordpress服务器来试图转换另一台肉鸡，没想到我这个服务器太弱禁不起这么点小小的折腾。

不过，问题终于得到解决，还是不错。

08/25/2025

后记，实际在以上的一番操作后，还是出现了服务器挂起的问题，原因是把httpd.conf的进程数量改回去变大了，偶尔瞬间的访问量激增后直接挂起，所以还是根据CPU和RAM值改成了一个适当的值。

持续发起大量链接的日本IP也在几小时后主动停止了链接，想起来最近的各种挂起可能并不完全是它的访问，可能是AI以后的各种BOT。

然后今天再将Cloudflare的强制验证关掉，持续观察一段时间。