服务器故障排查三板斧:记一次IIS报503/502错误故障排查过程

背景

　　近期被抓壮丁解决一个几年前的系统故障，经过反复排查多次监控后终于成功解决，记录分享一下心得吧！

故障描述

　　具体表现为在高峰访问期间，IIS直接报服务器处理503。

系统部署

采用ARR实现的IIS Sever Farm进行负载均衡，将全省内部portal请求负载到两台web服务器。

三板斧之一：对症下药

　　既然已有错误信息：The serverRuntime@appConcurrentRequestLimit setting is being exceeded，那么根据这个信息进行检索，发现是实时实时连接数超过默认配置导致，因此根据指引，将两台web服务器的实时连接数设置为20000。

　　参考：http://www.jb51.net/os/windows/win2008/80751.html

　　结果：调整后当时，系统功能恢复，后续跟进发现在高峰期时系统仍旧无法提供服务，而且错误信息已经变化为502错误，如下图。这个时候，搜索已经无法确切的找到问题了，是时候祭出我们的第二招了。



三板斧之二：望闻观切

　　既然此坑广大同胞没有详细解决攻略，那就我们自己肝起来吧！

首先，既然是web服务器无法服务那我们先检查windows事件日志吧：排查结果日志无异常错误信息。

其次，检测IIS日志文件，检索是否存在502的日志情况（这个地方不是很确定IIS在拒绝服务后还会不会记录访问日志,姑且检查一下,后续可以重现一下，TODO：哈哈哈哈）：结果，无502的日志记录，简直吐血。http://www.cnblogs.com/mincyw/p/3425468.html

基于在web服务器本地host访问无任何异常，且之前503的异常跟实时连接数有关系，因此，检测负载均衡的实时情况，发现两台服务器一台实时连接数达到1W1+，另一台6000+。（其实这里已经是病症所在，实时连接数这么大，肯定是有请求堵住了，但是当时没有识别出来，功力还不够深啊！）排查结果：以为是均衡策略问题，调整均衡策略！结果隔天照样502！！！

非高峰期观察系统访问情况，发现某个页面响应特别慢，且偶尔有超时的风险！！排查结果：怀疑跟数据量有关系，备份后清理14年以前的数据。

　　在清理完数据后，神奇的事情发生了！！访问高峰期时，两台web服务器的实时连接数由1W1+和6000+，都断崖式地降到100！！！且几天下来的监控发现系统已经正常提供服务！！！

　　总结：由于某些sql查询慢，导致请求响应时间过长，导致IIS处理队列一直堵塞，最终触发503实时连接数超出及502无效响应！

三板斧之三：庖丁解牛

　　既然定位到数据库查询慢的问题，那想办法让他快起来吧！

治标：备份清理数据。（视系统重要性，如需要快速恢复服务，采用此办法先提供正常服务）

治本：sql优化。（索引优化、检测查询计划、索引碎片整理等，但是优化并不是一朝一夕，需要时间，所以一般先治标，再治本）

总结

　　遇到故障并不可怕，可怕的是不知道怎么下手解决故障！！

　　PS：下次遇到503/502时，优先排查数据库sql执行效率吧！嘿嘿嘿：http://www.cnblogs.com/jonhson/archive/2011/09/24/2188304.html