蒙戈連接計數與氧化鎂司機攀升一個每10秒

Question

我們監控使用這是我們的MongoDB連接數：

http://godoc.org/labix.org/v2/mgo#GetStats

但是，我們一直面臨着一個奇怪的連接泄漏問題，即connectionCount一直向上蔓延每10秒多打開一次連接。 （不管是否有任何請求）。我可以在本地主機上啓動一個服務器，把它留在那裏，什麼也不做，conectionCount仍然會爬起來。連接數最終會蔓延到幾千，然後它殺死應用程序/數據庫然後我們必須重新啓動應用程序。

這可能沒有足夠的信息供您調試。有沒有人有任何想法，你曾經處理過的連接泄漏。你是如何調試它的？我可以調試的方式有哪些？

我們已經嘗試了一些東西，我們掃描我們的代碼庫，可以打開一個連接，並把計數器/調試語句那裏，到目前爲止，我們沒有發現泄漏的任何代碼。這幾乎就像某處圖書館有泄漏。

這是我們一直在努力的一個分支中的錯誤，也有過幾百個提交了進去。我們已經做了這個和主人之間的差異，並找不到爲什麼在這個分支有連接泄漏。

作爲一個例子，存在我引用數據集：

Clusters:  1 
MasterConns: 9936  <-- creeps up 1 per second 
SlaveConns: -7359  <-- why is this negative? 
SentOps:  42091780 
ReceivedOps: 38684525 
ReceivedDocs: 39466143 
SocketsAlive: 78  <-- what is the difference between the socket count and the master conns count? 
SocketsInUse: 1231 
SocketRefs: 1231 

MasterConns是蠕升每10第二個的數量。我不完全確定其他數字的含義。

Answer 1

MasterConns不能告訴你是否有泄漏或沒有，因爲它不會降低。該字段表示自上次統計信息重置以來進行的連接數，而不是當前正在使用的套接字數。後者由SocketsAlive字段指示。

爲了給您一些額外的解決方法，mgo套件中的每個測試都包含了邏輯，以確保統計數據在測試完成後顯示出理智的值，以便不會忽視潛在的泄漏。這就是引入這種統計收集系統的主要原因。

那麼，爲什麼你看到這個數字增加每10秒左右的原因是由於發生了學習集羣狀態的內部活動。也就是說，這種行爲最近發生了變化，因此它不會建立新的連接，而是從池中選擇現有的套接字，所以我相信你沒有使用最新版本。

有SlaveConns負看起來像一個bug。有一個關於統計信息收集的小例子，因爲我們無法分辨給定的服務器是主服務器還是從服務器，因此可能有一條未被發現的路徑。如果您升級後仍然看到該行爲，請報告問題，我很樂意查看它。

SocketsInUse是一個或多個會話仍在被引用的套接字的數量，無論它們是否處於活動狀態（連接已建立）。 SocketsAlive又是實時TCP連接的實際數量。兩者之間的增量表示多個會話未關閉。這可能沒有問題，如果它們仍然被應用程序保存在內存中並且最終會被關閉，或者如果應用程序錯過了操作，它可能是泄漏。