Heim  >  Artikel  >  Datenbank  >  Mongodb---记一次事故故障

Mongodb---记一次事故故障

WBOY
WBOYOriginal
2016-06-07 15:57:381130Durchsuche

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号

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn