2014.06.19.001---故障报告
事故发生时间 |
事故简述 |
事故责任方 |
是否解决 |
19:21-20:15 |
IISserverD盘即将溢出 |
|
是 |
一、事故描写叙述:
在19:21收到警报。显示IIS/Routerserver的D盘空间即将负荷。
二、事故处理过程:
1. 登录server查看后。发现router的日志非常大,有超过100G,导致无法打开。 决定,先重新启动router服务,删除日志。
2. 重新启动完成router后。日志又出现了猛刷的情况。进入查看,显示
2014-06-19T20:08:25.170+0800[conn8956] end connection 10.4.1.101:7389(100 connections now open)
2014-06-19T20:08:25.170+0800[mongosMain] connection accepted from 10.4.1.101:7390#8957 (101 connections now open)
2014-06-19T20:08:25.170+0800[conn8957] authenticate db: minger { authenticate: 1, user: "client",nonce: "xxx", key: "xxx" }
2014-06-19T20:08:25.170+0800[conn8957] end connection 10.4.1.101:7390(100 connections now open)
2014-06-19T20:08:25.170+0800[mongosMain] connection accepted from 10.4.1.101:7391#8958 (101 connections now open)
2014-06-19T20:08:25.170+0800[conn8958] authenticate db: minger { authenticate: 1, user: "client",nonce: "xxx", key: "xxx" }
2014-06-19T20:08:25.170+0800[conn8958] end connection 10.4.1.101:7391(100 connections now open)
2014-06-19T20:08:25.170+0800[mongosMain] connection accepted from 10.4.1.101:7392#8959 (101 connections now open)
2014-06-19T20:08:25.170+0800[conn8959] authenticate db: minger { authenticate: 1, user: "client",nonce: "xxx", key: "xxx" }
2014-06-19T20:08:25.170+0800[conn8959] end connection 10.4.1.101:7392(100 connections now open)
2014-06-19T20:08:25.186+0800[mongosMain] connection accepted from 10.4.1.101:7393#8960 (101 connections now open)
2014-06-19T20:08:25.186+0800[conn8960] authenticate db: minger { authenticate: 1, user: "client",nonce: "xxx", key: "xxx" }
3. 这个问题在阿里也一度遇到过,是因为阿里云的物理机的设置导致tcp请求 上不去。而出现这样的情况。
4. 将IIS的tcp pool关闭,mongodb的pool关闭。随机日志不再狂刷。
三、分析原因:
Mongodb 驱动程序採用的连接池的方式连接到数据库,眼下从观察到的情况是应用一开启便依据变量的设置。建立所有连接。然后提供给程序使用,而且一旦当中某个连接到数据库的訪问失败,则会清空整个连接池到这台数据库的连接,并又一次建立连接。
而mongodb对中断连接的垃圾清理工作则是懒惰的被动清理方式,假设驱动程序端配 置的连接数过大。一旦发生重连,则会导致mongo端堆积大量的垃圾连接数据,导致主机资源耗尽。
windowsserver,timewaitdelay 最小值是30秒。而mongodb pool size 设为2000
也就是说。假设2000个连接里有一个由于网络关系断开了,就要又一次建立新的2000个连接,之前的2000个由于timewaitdelay的原因。临时还不能释放。假设在30秒内。由于网络原因,反复建立连,接导致将60000个port都用尽了。就会报错
可是既然耗尽了。为什么日志中显示一直有100个连接保持着呢?
对此,老大给出了一条非常重要的信息,C#中,关于连接池的代码中,设定最小值为100。对此我做出的猜想是。是否这100个链接用的是系统的1024个port中的100个?导致timewaitdelay不会涉及到这100个链接呢?尚待考证。
四、改进措施
1. 调整
MaxUserPort = 65534
MaxHashTableSize = 65536
MaxFreeTcbs = 16000
TcpNumConnections = 16777214
2. 将minpoolsize设为200,进行观察。
2014年06月20号