我们使用以下方法监控我们的mongoDB连接数：
http://godoc.org/labix.org/v2/mgo#GetStats
但是，我们一直面临着一个奇怪的连接泄漏问题，其中connectionCount每10秒一次更多地打开连接。 （无论是否有任何要求，都是如此）。我可以在localhost中启动服务器，将其保留在那里，什么也不做，conectionCount仍然会爬升。连接数最终会增加到几千，然后它会杀死app / db，我们必须重新启动应用程序。
这可能不足以让您调试。有没有人有任何想法，你过去处理过的连接泄漏。你是怎么调试的？有什么方法可以调试它。
我们已经尝试过一些东西，我们扫描了我们的代码库，找到了可以打开连接并在其中放置计数器/调试语句的任何代码，到目前为止我们没有发现泄漏。这几乎就像某个地方的图书馆有泄漏。
这是我们一直在处理的分支中的一个错误，并且已经有几百个提交。我们在这个和master之间做了一个差异，无法找到为什么这个分支中存在连接泄漏。
例如，我正在引用数据集：
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秒爬升一次的数字。我不完全确定其他数字的意思。
答案 0 :(得分：14)
MasterConns无法告诉您是否有泄漏，因为它没有减少。该字段指示自上次统计信息重置以来所做的连接数，而不是当前正在使用的套接字数。后者由SocketsAlive字段表示。
为了让您对这个主题有一些额外的解脱，mgo套件中的每一个测试都围绕着逻辑，确保统计数据在测试结束后显示出合理的值，这样潜在的泄漏就不会被忽视。这就是引入这种统计数据收集系统的主要原因。
然后，您看到此数字每10秒钟左右增加的原因是由于学习群集状态所发生的内部活动。也就是说，这种行为最近发生了变化，因此它没有建立新的连接，而是从池中选择现有的套接字，所以我相信你没有使用最新版本。
让SlaveConns为负面看起来像一个错误。关于连接的统计信息收集有一个小问题，因为在我们与之交谈之前，我们无法判断给定服务器是主服务器还是从服务器，因此可能存在未覆盖的路径。如果您在升级后仍然看到该行为，请报告问题，我将很乐意看到它。
SocketsInUse是一个或多个会话仍在引用的套接字数，无论它们是否处于活动状态（已建立连接）。 SocketsAlive再次是实时TCP连接的实际数量。两者之间的差异表示许多会话未关闭。这可能没问题，如果它们仍被应用程序保留在内存中并最终将被关闭，或者如果应用程序错过了session.Close操作，则可能是泄漏。