2014.06.19.001---故障报告 事故发生时间 事故简述 事故责任方 是否解决 19：21-20：15 IIS服务器D盘即将溢出 是 一、事故描述 ： 在19：21收到警报，显示IIS/Router服务器的D盘空间即将负荷。 二、事故处理过程： 1. 登录服务器查看后，发现router的日志很
2014.06.19.001---故障报告
|
事故简述 | 事故责任方 | 是否解决 | ||||||||
| 19：21-20：15 | IIS服务器D盘即将溢出 | 是 |
一、事故描述：
在19：21收到警报，显示IIS/Router服务器的D盘空间即将负荷。
二、事故处理过程：
1. 登录服务器查看后，发现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端堆积大量的垃圾连接数据，导致主机资源耗尽。
windows服务器，timewaitdelay 最小值是30秒，而mongodb pool size 设为2000
也就是说，如果2000个连接里有一个因为网络关系断开了，就要重新建立新的2000个连接，之前的2000个因为timewaitdelay的原因，暂时还不能释放，如果在30秒内，因为网络原因，重复建立连，接导致将60000个端口都用尽了。就会报错
但是既然耗尽了，为什么日志中显示一直有100个连接保持着呢？
对此，老大给出了一条很重要的信息，C#中，关于连接池的代码中，设定最小值为100。对此我做出的猜想是，是否这100个链接用的是系统的1024个端口中的100个？导致timewaitdelay不会涉及到这100个链接呢？尚待考证。
四、改进措施
1. 调整
MaxUserPort = 65534
MaxHashTableSize = 65536
MaxFreeTcbs = 16000
TcpNumConnections = 16777214
2. 将minpoolsize设为200，进行观察。
2014年06月20号
