Настоящая причина, по которой вы не можете делать, как просите (ограничить память), заключается в том, что MongoDB не управляет памятью, которую использует напрямую, - это позволяет ОС делать это. MongoDB просто память отображает все свои данные, а затем выдает страницу ОС в память и из памяти по мере необходимости. В результате прямого управления используемым количеством невозможно, пока MongoDB не реализует это совершенно по-другому, или ОС не позволяет это (в Linux это невозможно через 2,4 дня).
Единственный способ по-настоящему разделить ресурсы в настоящее время - это использовать решение для виртуализации и изолировать MongoDB в своей собственной виртуальной машине. Да, это связано с накладными расходами (хотя гипервизоры стали намного лучше), но на данный момент это цена, которую нужно заплатить за этот уровень контроля ресурсов.
С точки зрения OOM Killer, даже при отсутствии других процессов на хосте, если ваш набор данных и индексы в целом превышают доступную память, MongoDB может столкнуться с проблемами OOM Killer. Это происходит из-за того, что данные выгружаются из памяти - если нет никакого давления памяти (больше ничего не требуется резидентной памяти), и вы продолжаете добавлять / касаться новых данных и индексов, то в конечном итоге они будут расти, чтобы использовать всю доступную оперативную память. Отсюда рекомендация всегда настраивать некоторый своп при запуске MongoDB:
https://docs.mongodb.com/manual/administration/production-notes/#swap
Конечно, данные LRU будут сначала выгружены, другие процессы также могут занимать res mem, но концепция все еще применима, если вы не загрузите свой набор данных в память, а затем он останется статичным. Лучшее, что вы можете сделать, если вы беспокоитесь, это вставить его в MMS и отслеживать его использование с течением времени:
http://mms.mongodb.com
Обновление: август 2015
С тех пор, как я написал этот ответ, ситуация несколько изменилась, и информация немного устарела. Например, в Linux теперь есть cgroups и связанные с ними технологии ( например, контейнеры Docker ), которые достигли такой степени зрелости, что позволяют вам лучше изолировать и ограничивать ресурсы ( включая память ), потребляемые любым процессом в производственной среде, даже той, которая использует отображение памяти как MongoDB.
Кроме того, с появлением новых механизмов хранения помимо MMAP, таких как WiredTiger, в MongoDB 3.0+ вы можете использовать встроенные функции для ограничения размера кэша для MongoDB. Следовательно, требования к ОЗУ теперь действительно зависят от того, как вы решите сконфигурировать MongoDB, в какой среде вы ее запускаете и какой механизм хранения вы выбираете.
MongoDB будет использовать доступную свободную память для кэширования и при необходимости подкачки на диск, чтобы выделить память для других приложений на том же сервере. Для достижения наилучшей производительности вам понадобится достаточно оперативной памяти для хранения ваших индексов и часто используемых данных («рабочего набора») в памяти.
Полезное чтение:
источник
Что-то изменилось за последние годы о MongoDB.
TL; DR
Если механизм хранения MMAPv1 используется на MongoDB,
working setразмер должен соответствовать ОЗУ . https://docs.mongodb.com/manual/faq/diagnostics/#must-my-working-set-size-fit-ramЕсли в MongoDB используется механизм хранения WiredTiger, не нужно беспокоиться о том, подходит ли ОЗУ
working setили нет . https://docs.mongodb.com/manual/faq/diagnostics/#memory-diagnostics-for-the-wiredtiger-storage-engineисточник