DevOps文化 & SRE实战分享平台

0%

Windows IIS会话TIME_WAIT问题分析与排障


文章声明:此文基于木子实操撰写。
生产环境:Windows Server 2008 R2 Datacenter IIS 7.5
论证耗时:30m
撰文耗时:30m
校文耗时:15m
问题关键字:IIS TIME_WAIT


最近木子在梳理个人笔记,整理出一篇关于Windows Server 2008 R2 Datacenter IIS7.5异常问题分析排障的文章,在这里分享给各位博友,希望对各位运维Windows服务器问题定位有所帮助。这是发生在2018年的事情,没有什么高深技术,但对于Windows运维的基础问题排查,应该说是有所帮助的。其实Windows大部份的问题都可能通过[性能监视器]与[事件查看器]进行跟踪、分析、定位与排查。当然如果想更加深入的排查一些Windows上更深层次的问题,比如:蓝屏等问题,就可能需要进行dump文件分析了。

问题说明

运维的同事说无法通过RDP远程连接至Windows,于是木子通过VNC控制台连接上去看了一下,发现会话被占满了,各种TIME_WAIT。

定位问题

解决这个问题最简单的方法就是重启服务器,但这治标不治本,于是开始排查。但因为这个服务器上挂了很多网站,所以请求是到哪个网站的我们也不清楚,必须要先了解清楚对应的请求域名,才能够进一步排查问题。
这时候我们可以通过Windows自带的[性能监视器]进行数据采集分析。在[性能监视器]里面添加[Web Service]的[current connections],然后选择所有域名,再看哪个域名的会话连接最多。当然通过netstat -an可以看到基本上都是别人请求它的,所以其实我们只需要获取get reuqests的信息就OK。

通过get reuqests确认域名,再查看对应域名的日志信息。

活动会话达到了158万。

然后查看对应日志文件,发现已经写了300多MB。

再查看日志信息都是网关发过来的。

1
2
2018-06-20 00:00:04 192.168.1.1 GET /123/test 80 - 192.168.5.5 test/0.16.2 - 200 0 0 0
2018-06-20 00:00:04 192.168.1.1 GET /123/test 80 - 192.168.5.5 test/0.16.2 - 200 0 0 0

问题找到了,上报给开发的同事,原来是开发同事写了一个bug(画风转变得有一点快@-@,但事实就是这样子。)。

写在最后

其实这只是一个简单的Windows服务器IIS问题定位与分析,由于已经过去很久,所以在整理笔记的时候,会存在一些无法还原的现场信息。输出只是为了给Windows运维同事更多一个了解Windows的机会。

坚持原创技术分享,您的支持与鼓励,是我持续创作的动力!