首页 » 故障处理总结 » 正文

官网故障总结

2015-01-30官网出现打开慢,有时打不开,监控系统出现官网访问出现频繁的闪段,以下是排查过程:

1、首先要保证官网的正常访问,所以一旦监控系统报警,就立即手动重启nginx。

2、由于官网是静态文件,没有需要php程序处理的功能,所以初步判断不是因为php的原因导致的此次故障。

3、 查看nginx的访问日志,发现大量的消息系统请求,一分钟20万次的访问。立即与开发及相关人员确定,请求是正常的,都是由客户端的隐藏窗 口发出来的请求。所以决定暂时将消息请求屏蔽掉,但是由于客户端不重启,无法请求新的ordertips.js,所以改了文件,但是当天不能生效,不能及 时的缓解请求压力。

4、接到CDN的客服和技术通知,由于回原量特别大,CDN的节点和上层压力特别大,已经影响到了其他客户,要求尽快处理(因为请求都是404,所以节点和上层需要回原取文件,但是原站又没有文件,给节点返回404,所以会这样一直循环下去)。

5、我临时做出决策,让CDN做了处理,屏蔽消息请求。这样极大的缓解了压力,官网访问正常(已经测试)。

6、因为原站没有消息文件,所以才导致的循环请求,导致原站压力特别大,所以我进入到消息的生成目录,发现的确没有消息文件,所以我初步判断一定是php处理上出现了问题。

7、我登录到代码发布服务器,使用curl的方式请求原站的消息生成接口,发现请求超时,所以初步判断一定是原站的php处理出现了问题。

8、我登录到原站服务器时上,使用top命令查看消耗资源的进程,发现生成缓存文件的计划任务已执行多个进程,所以我确定肯定是生成缓存文件出现了问题。

9、我使用kill结束掉了所有的生成缓存文件的进程,并且取消了计划任务(计划任务是每分钟生成一次消息缓存),同时在代码发布服务器上使用curl的方式请求原站的消息生成接口,接口正常。

10、我使用手动的方式执行生成缓存,并且使用nmon命令时时监控系统性能,结果发现php程序执行特别慢,写入操作已经将CPU和生成缓存的磁盘分区跑满了。

11、我临时决定暂停缓存生成计划任务及httpsqs服务。官网恢复正常。

12、我开始查询为什么生成缓存程序会这么消耗系统资源,所以我进入了生成缓存的消息目录,执行ls命令查询内容的时候,执行了2分钟左右才显示内容。而我们使用的又是机械硬盘而不是SSD,所以确定肯定是单个文件夹下面文件太多,导致写入和读取特别慢。

13、我开始查询生成缓存目录的大小,使用du -sh 命令发现执行了20分钟还没有结果,后来使用df -h的命令查看分区使用的大小,也不大,还不到70g。

14、缓存是我们业务的核心,不能停,所以我写了一个脚本,通过curl的方式访问官网,如果http的响应码不是200,就立刻重启nginx,通过crontab每分钟执行一次。并同时启用缓存生成计划任务,由原来的每分钟生成一次恢复成最开始的每两分钟生成一次。

15、官网访问一切正常。

16、下周准备定期清理缓存文件,删除半年以前的文件。

 

总结:
1、针对这次故障做了几个操作:通知CDN及咱们公司的开发屏蔽消息请求。通过计划任务及脚本定时重启nginx。修改生成缓存的时间。调优nginx的配置。

2、故障原因是因为缓存文件过多,导致php生成缓存写入及读取过慢占用了大量的系统资源、nginx资源和php资源,导致订单消息文件无法生成、缓存文件读取缓慢,cdn回原量特别大,nginx请求量爆满,最终导致官网出现打开慢及无法访问。

3、由于请求量的日志有4G,由于家里电脑及网速原因,目前无法下载及分析,不过根据原站的日志抽样查看,请求是正常的。不是攻击导致的。

4、 目前的方案虽然能保证了官网的正常访问,但是有几个缺点:定时重启nginx不是最终的方案,只是作为临时的方案,并且是按照分钟去检查的,真的出现问题 并不能立刻重启,有一分钟到两分钟的延迟,修改生成缓存的时间,但是却一定程度上的影响到了用户的体验。CDN屏蔽了消息系统的请求,那么最终会导致用户 无法在电脑的右下角看到订单消息提示。

5、目前的消息在系统架构上也存在缺陷,没有考虑到这种情况是我的问题。

 

个人建议如下:

消息系统:
方案一:将目前线上的消息方案迁移到融云上,需要开发的配合(与v3.9的处理逻辑一样)。

方案二:将消息系统生成功能迁移回核心,然后通过rsync的方式同步到原站上,再由CDN上层及节点来取,最终返回给用户,这种方案比目前使用的方案延迟会大一些。

方案三:存储到第三方的云服务器或者云数据库上面。比如阿里云,这种方案需要资金上的成本,可操作性有待调查。

 

缓存系统:
方案一:定期删除消息文件,由于商品信息有过期时间,所以个人建议将缓存文件保留90天,90天以前的缓存通过计划任务做清理(时间是拍脑袋想出来的,没有任何的根据,时间上可以讨论)。

方案二:将机械硬盘更换成SSD,这种方案需要增加资金的成本,可操作性有待调查。

方案三:存储到第三方的云服务器或者云数据库上面。比如阿里云,这种方案需要资金上的成本,可操作性有待调查。

方案四:更改缓存系统的目录结构,增加多级目录,据测试,京东的图片存储采用了7级目录。个人猜测京东可能使用了磁盘阵列和SSD。京东图片的地址如下:
http://img11.360buyimg.com/n4/jfs/t187/64/1316618299/76033/681bddcc/53a8eba4N7940b554.jpg