MongoDB 鏈接數高產生緣由及解決

  MongoDB Sharding架構下鏈接數很容易達到很高,這裏鏈接數分爲幾個概念: tcp 鏈接數 netstat能夠統計的,通常這個是最高.若是mongod/mongos在同一臺服務器,更明顯。 參考命令:java

netstat -ant|awk ‘{print $5}’ |awk -F: ‘{print $1}’|sort |uniq -c|sort -rn mongos/mongodgit

鏈接數 mongostat/db.serverStatus()/connPoolStatsgithub

可統計。sql

鏈接數多高算高呢?mongodb

這要看鏈接到mongodb集羣應用服務器實例數、qps(增刪改查)等判斷。 應用服務器單臺,若是qps<100, ,mongos鏈接數超過2000,確定是高了。這通常是因爲鏈接池配置不合理致使。 mongod/mongos 默認最大鏈接數maxConns=20000,2.4版本及之前版本最大不能超過這個數值,2.6版本(開發版2.5版本)取消這個限制。 相關連接http://nosqldb.org/topic/50ca8a50ee680fee790001f2shell

什麼緣由致使鏈接數太高緩存

  • 鏈接池配置不合理 分片狀況下,現象是tcp 鏈接數太高(如達到20000),mongos鏈接數太高(如超過10000) java爲例,connectionsPerHost 不宜配置過大,官方默認值由原來10改爲100了,並且有默認5倍的乘數(threadsAllowedToBlockForConnectionMultiplier),通常20~50就能夠了。安全

  • 應用服務器實例過多服務器

咱們遇到的場景,當鏈接到mongos的應用服務器(如Tomcat實例數量)過百,甚至達到近200臺時,tcp鏈接數超高,達到15000以 上,查看mongod對應端口鏈接數高達8000多,mongos 2000多。此時ops(query,insert,update,delete)低於200每秒,。按期重啓(如一週一次)mongos可適當緩解該問 題。架構

  • mongodb自己的緣由 表現爲mongos鏈接數不高(如1000+),mongod鏈接數比較高(如8000+)。

如何解決 總結一下,鏈接數高分爲幾個場景: 應用服務器實例過多,可統計每一個實例創建的鏈接數,適當調低鏈接池參數。 mongos鏈接數高,這種就是配置的問題,更改鏈接池參數。 mongos鏈接數不高,mongod鏈接數比較高,如超過5000,若是鏈接池配置合理還比較高的話,嘗試啓用releaseConnectionsAfterResponse參數(2.2.4版本以上),該參數爲 隱藏參數releaseConnectionsAfterResponse

mongos> use admin switched to db admin mongos> db.runCommand({ setParameter : 1, releaseConnectionsAfterResponse : true }) { "was" : false, "ok" : 1 }

或者

shell> mongos --setParameter "releaseConnectionsAfterResponse=true" --configdb ...

該參數注意事項: 寫操做須要當即調用getLastError (w=1,即安全寫模式),w=2(等待從庫寫確認)的時候可能會有些錯誤。 升級事後,或者重啓mongos進程後,須要從新設置該參數,該參數只對單個mongos生效。 啓用releaseConnectionsAfterResponse 參數,tcp 鏈接數明顯下降到比較穩定數目。幾個小時,tcp鏈接數從8000多降到4000多,效果不錯。

  • releaseConnectionsAfterResponse 參數原理

一般,對於每一個mongos->mongod鏈接是單獨緩存的,而且該鏈接不能重複使用,即便該鏈接是空閒時也是如此,一直到鏈接關閉鏈接回 到鏈接池中才能再使用;releaseConnectionsAfterResponse 參數啓用後,mongos->mongod之間的鏈接在完成一個讀操做或者安全寫操做後可以重複使用(把鏈接放到鏈接池中而不是緩存,即更早的迴歸 到鏈接池中),releaseConnectionsAfterResponse參數簡單講就是mongos->mongod的鏈接更早的回到鏈接 池中,這樣就不會開太多的鏈接了,從而減小鏈接數。 Create a new serverParameter for mongos, 「releaseConnectionsAfterResponse,」 which enables returning ShardConnections from the per-socket pool to the global pool after each read operation. This should reduce the total number of outgoing mongos connections to each shard. the option allows better use of the connection pool, it doesn’t invalidate the connections in the pool. Normally, mongos->mongod connections for insert/update/delete/query are cached individually for each incoming connection, and can’t be re-used until the incoming connection is closed, even if they are idle and there are other active incoming connections. What the releaseConnectionsAfterResponse option does is allow the mongos->mongod connection to be re-used (returned to the pool) after any read op (including getLastError(), so after safe writes as well). It shouldn’t have a significant performance impact - the connection isn’t destroyed, it’s just returned from the incoming connection cache to the shared pool early.

代碼: https://github.com/mongodb/mongo/commit/706459a8af0b278609d70e7122595243df6aeee8 https://github.com/mongodb/mongo/commit/74323d671a216c8c87fcb295ed743f830d5212ee https://github.com/mongodb/mongo/commit/5d5fe49dfb5f452832b9d44fddbfb2a4e8b42f2a

=============== - connPoolTimeout設置

(該參數不在官方沒有) 效果

mongos> db.runCommand({ setParameter : 1, connPoolTimeout : 900 })
{ "was" : 1800, "ok" : 1 }

初步測試,效果不明顯。

  • releaseConnections

計劃添加個命令releaseConnections,從mongod運行,減小複製集鏈接數

相關文章
相關標籤/搜索