У нас есть два узла данных 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 МБ. Тенденция довольно устойчивая, поэтому не могу сказать, что здесь утечка, но куда девается память?
Любая идея?
Во-первых, позвольте мне сказать, что если он относительно стабилен, у вас нет утечки памяти, и это примечание в serverStatus () было удалено в 2.2 из-за частоты ложных срабатываний.
Не отображенная виртуальная память - это внутренние структуры данных и стеки потоков MongoDB, по сути, все, что не поддерживается файлами на диске. Как вы упомянули, это обычно обусловлено стеком соединений из расчета 1 МБ на соединение. В вашем случае похоже, что это должно быть около отметки 1,1–1,2 ГБ (если у вас не было скачка соединения и память еще не была освобождена).
Если вы делаете много встроенных карт / сокращений, сортировки в памяти и т. Д., Они также могут увеличить использование не отображаемой памяти. Если вы установите MMS (что является бесплатным), неотображенная память - это одна из статистических данных, отслеживаемых с течением времени, и вы можете легко сопоставить увеличение не сопоставленной статистики с активностью в вашей базе данных. Однако, если вы еще не запускали его, вам может потребоваться перезапустить процесс, чтобы снова отслеживать использование с нуля.
Этот тип анализа использования зачастую проще, чем использование pmap (или аналогичный), чтобы попытаться привязать память к определенным частям внутри процесса
Наконец, если использование без сопоставления выходит из-под контроля, иногда это может быть вызвано проблемами с libc malloc в 2.0 - среди прочего, именно поэтому версия 2.2 отправлен с участием TCMalloc вместо. Так что, возможно, стоит проверить версию 2.2, если она остается высокой без очевидной причины.