Mongodb---記一次事故故障
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號
Mongodb---記一次事故故障