MongoDB не использует всю доступную оперативную память

У меня есть что-то около 200 ГБ данных, хранящихся в кластере Монго. Физическая память на одном из экземпляров, на которых работает монго, составляет 8 ГБ. Ничто другое не имеет значения в этом случае. Насколько я понимаю, основываясь на документах Монго (например, http://www.mongodb.org/display/DOCS/Checking+Server+Memory+Usage ), это означает, что процесс mongod должен использовать около 100% доступная физическая память. Но если вы посмотрите на следующий вывод topкоманды, вы увидите, что экземпляр mongod использует только 2 ГБ резидентной памяти и есть 2 ГБ свободной физической памяти, которая вообще не используется.

Может кто-нибудь объяснить мне это поведение? Почему там 2 ГБ свободной памяти?

top вывод:

top - 23:19:43 up 89 days, 20:05,  2 users,  load average: 0.41, 0.55, 0.59
Tasks: 101 total,   1 running, 100 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.0%us,  1.3%sy,  0.0%ni, 93.9%id,  2.6%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   8163664k total,  6131764k used,  2031900k free,    54976k buffers
Swap: 16771848k total,    10604k used, 16761244k free,  5367700k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                             
 1401 mongodb   20   0  174g 2.0g 1.9g S   23 26.2  18070:55 mongod
 ...

Системная информация:

$ uname -a
Linux aluminum 2.6.32-31-server #61-Ubuntu SMP Fri Apr 8 19:44:42 UTC 2011 x86_64 GNU/Linux

Ноты:

В этом кластере есть еще один экземпляр, где mongod ведет себя так, как я ожидаю, и использует всю доступную память.
Глядя на mongostat, похоже, что у него постоянно возникали сбои страниц, поэтому объем используемой памяти должен расти:
(Я задал этот же вопрос в группе Google mongodb-user, но не получил ответа.)

mongodb memory

— Крис У.
источник

Какой Linux дистрибутив? Это 32 или 64 бит? (Отредактируйте свой вопрос с выходными lsb-release -auname -a

— данными

Спасибо. Добавлено, unameно я не lsb-releaseустановил.

— Крис В.

Вы случайно скачали 32-битную версию MongoDB? Максимальный размер 32-битного экземпляра Mongo составляет 2 ГБ.

— Аарон

@ BryceAtNetwork23 нет; у нас определенно есть больше чем 2 ГБ в нашем общем количестве mongodb (несколько сотен гигов фактически).

— Крис В.

@ChrisW он означает максимальный объем памяти, а не размер базы данных. И кажется, что это хорошо объясняет 2ГБ.

— rfusca

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

Чтобы определить, так ли это, вы должны запустить free -m, вывод должен выглядеть примерно так:

free -m
             total       used       free     shared    buffers     cached
Mem:          3709       3484        224          0         84       2412
-/+ buffers/cache:        987       2721
Swap:         3836        156       3680

В моем примере кеширование не близко к общему, что означает, что mongod не только недостаточно коснулся страниц, кеш файловой системы еще даже не был заполнен страницами, считываемыми с диска в целом.

Быстрое решение этой проблемы - сенсорная команда (добавлена в 2.2) - ее следует использовать с осторожностью при работе с большими наборами данных, поскольку она будет пытаться загрузить все в ОЗУ, даже если данные слишком велики, чтобы уместиться (вызывая много дисковый ввод-вывод и ошибки страницы). Это, конечно, будет эффективно заполнять память, хотя :)

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

— Адам С
источник