Виртуальная память без отображения и общее количество соединений

У нас есть два узла данных MongoDB (набор реплик) - основной и дополнительный. Я заметил, что non-mapped virtual memory относительно высока и задается вопросом, не влияют ли они на нашу производительность MongoDB (сервер обычно работает со скоростью около 6-7K запросов в секунду).

В MMS сообщалось: "Наиболее распространенный случай использования большого объема памяти для не отображенных карт - это очень большое количество подключений к базе данных".

Таким образом, мы проверили использование памяти с db.serverStatus().mem в нашей средней школе:

{
    "bits" : 64,
    "resident" : 6846,
    "virtual" : 416797,
    "supported" : true,
    "mapped" : 205549,
    "mappedWithJournal" : 411098,
    "note" : "virtual minus mapped is large. could indicate a memory leak"
}

Примечание. Мы используем 2.0.4, и теперь размер стека по умолчанию должен составлять 1 МБ на соединение.

Текущее количество подключений составляет около 1,1 КБ, но не отображенная виртуальная память (virtual-mappedWithJournal) составляет около 5699 МБ. Тенденция довольно стабильна, поэтому я не могу сказать, что здесь есть утечка, но куда уходит память?

Любая идея?

Источник

1 ответ

Решение

Во-первых, позвольте мне сказать, что если он относительно стабилен, у вас нет утечки памяти, и эта заметка в serverStatus() была удалена в 2.2 из-за частоты ложных срабатываний.

Не отображаемая виртуальная память - это внутренние структуры данных MongoDB и стеки потоков, по сути, все, что не поддерживается файлами на диске. Как правило, это обусловлено тем, что стек подключений составляет 1 МБ на соединение. В вашем случае кажется, что это должно быть около отметки 1,1-1,2 ГБ (если у вас не было скачка соединения и память еще не была восстановлена).

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

Этот тип анализа использования часто проще, чем использование pmap (или аналогичного), чтобы попытаться связать память с конкретными частями внутри процесса

Наконец, если не нанесенное на карту использование выходит из-под контроля, это может иногда вызываться проблемами с libc malloc в 2.0 - это, среди прочих причин, было причиной того, что версия 2.2 поставлялась вместо TCMalloc. Таким образом, 2.2 вполне может стоить проверить, если он остается высоким без очевидной причины.

Источник
Другие вопросы по тегам