首页 > 数据库技术 > 详细

Mongodb---记一次事故故障

时间:2014-06-22 20:34:33      阅读:575      评论:0      收藏:0      [点我收藏+]

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号

Mongodb---记一次事故故障,布布扣,bubuko.com

Mongodb---记一次事故故障

原文:http://blog.csdn.net/moonhmilyms/article/details/32697481

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!