由于某IP大频率提交评论导致服务器宕机
早上突然收到dnspod的宕机通知(好久没收到了,有点手足无措)。
服务器在上午10:40时达到85%。uptime显示cpu利用率达到35。不宕才怪。
按照之前的经验,应该是触发一个特别耗CPU的处理,把php-cgi重启就能立马恢复,之后再查看日志。
重启后立刻ok.
查看日志,调出那一时刻的日志一条一条的过,重点放在反应时间上。正常的处理时间应该在1秒内,发现很多在几十秒以上的日志,慢慢回溯,发现了最开始异常的记录,是多个提交comment的日志。
发现一连串的来自同一IP的高频率的浏览文章并发日志的行为(偶尔还会有同一IP段的其它IP, 查了一下来自美国)。因为我们的评论审核是使用的第三服务,所以特别耗时间。
问题找到了,如何解决呢?
是停止使用审核功能呢,还是简单的将IP加入黑名单呢?
考虑的这一段时间apec还有一些国家会议在举行,对于审核还得慎重,采取的方法是先将这这一个IP段都加入黑名单。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 阿里最新开源QwQ-32B,效果媲美deepseek-r1满血版,部署成本又又又降低了!
· 单线程的Redis速度为什么快?
· SQL Server 2025 AI相关能力初探
· 展开说说关于C#中ORM框架的用法!
· AI编程工具终极对决:字节Trae VS Cursor,谁才是开发者新宠?