Счетчик подключений Mongo увеличивается на один за 10 секунд с помощью драйвера mgo

Мы отслеживаем количество подключений к mongoDB, используя это:

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

Однако мы столкнулись со странной проблемой утечки соединения, когда connectionCount постоянно увеличивается на 1 открытое соединение за 10 секунд. (Это независимо от того, есть ли какие-либо запросы). Я могу раскрутить сервер в localhost, оставить его там, ничего не делать, conectionCount все равно будет ползти. Количество подключений в конечном итоге достигает нескольких тысяч, и тогда приложение / БД убивает, и нам приходится перезапускать приложение.

Этой информации может быть недостаточно для отладки. У кого-нибудь есть идеи, утечки связи, с которыми вы сталкивались в прошлом. Как вы его отладили? Каким образом я могу отладить это.

Мы попробовали несколько вещей, мы просканировали нашу кодовую базу на наличие любого кода, который мог бы открыть соединение и поместить туда счетчики/операторы отладки, и до сих пор мы не обнаружили утечки. Это похоже на утечку где-то в библиотеке.

Это ошибка в ветке, над которой мы работали, и в нее было внесено несколько сотен коммитов. Мы провели сравнение между this и 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 секунд. Я не совсем уверен, что могут означать другие цифры.


go mongodb mgo connection-leaks
person samol    schedule 18.10.2013    source источник

Ответы (1)


arrow_upward
14
arrow_downward

MasterConns не может сказать, есть утечка или нет, потому что она не уменьшается. Поле указывает количество подключений, выполненных с момента последнего сброса статистики, а не количество сокетов, которые используются в данный момент. Последнее обозначено полем SocketsAlive.

Чтобы дать вам некоторое дополнительное облегчение в этом вопросе, каждый отдельный тест в пакете mgo основан на логике, которая гарантирует, что статистика показывает разумные значения после завершения теста, так что потенциальные утечки не останутся незамеченными. Это главная причина, по которой была введена такая система сбора статистики.

Затем причина, по которой вы видите, что это число увеличивается каждые 10 секунд или около того, связана с внутренней активностью, которая происходит для изучения состояния кластера. Тем не менее, это поведение было недавно изменено, так что оно не устанавливает новые соединения, а вместо этого выбирает существующие сокеты из пула, поэтому я полагаю, что вы не используете последнюю версию.

Отрицательный результат SlaveConns выглядит как ошибка. Есть небольшой пограничный случай, связанный со сбором статистики для установленных подключений, потому что мы не можем сказать, является ли данный сервер главным или подчиненным, пока не поговорим с ним, поэтому может быть непокрытый путь. Если вы по-прежнему наблюдаете такое поведение после обновления, сообщите о проблеме, и я буду рад ее рассмотреть.

SocketsInUse — это количество сокетов, на которые все еще ссылается один или несколько сеансов, независимо от того, активны они (соединение установлено) или нет. SocketsAlive — это, опять же, реальное количество активных TCP-соединений. Дельта между ними указывает на то, что ряд сеансов не был закрыт. Это может быть нормально, если они все еще удерживаются приложением в памяти и в конечном итоге будут закрыты, или это может быть утечка, если приложение пропустило операцию session.Close.

person Gustavo Niemeyer    schedule 18.10.2013
comment
Спасибо Густаво! Не могли бы вы также пояснить разницу между socketsAlive, SocketsInUse и SocketRefs? Почему socketAlive меньше, чем SocketsInUse? - person samol; 18.10.2013
comment
Конечно, завершил ответ. - person Gustavo Niemeyer; 18.10.2013