Mongodb сколько занимает памяти

Обновлено: 06.07.2024

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

Для меня самым большим уроком, не имеющим, впрочем, ничего общего с MongoDB, стало то, что не обязательно полагаться на единственное решение для работы с данными. Естественно, единственное решение имеет очевидные преимущества, и для многих - если не для большинства - проектов таковое является разумным подходом. Смысл не в том, что вы должны, а скорее в том, что вы можете использовать различные технологии. Только вы знаете, перевешивают ли преимущества от внедрения нового решения возможные издержки.

С учетом сказанного, я надеюсь, что виденное вами ранее позволило вам расценивать MongoDB в качестве общего решения. Пару раз упоминалось, что документ-ориентированные базы данных имеют много общего с реляционными. Таким образом, чтобы не ходить вокруг да около, позвольте просто заявить, что MongoDB может рассматриваться как прямая альтернатива реляционным базам данных. В то время, как Lucene можно рассматривать, как расширение реляционных баз полнотекстовым индексом, а Redis - как персистентное хранилище ключ-значение, MongoDB - это центральный репозиторий для ваших данных.

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

Бесстуктурность

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

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

Подумайте об этом с точки зрения разработчика драйверов. Вам надо сохранить объект ? Сериализируйте его в JSON (на самом деле в BSON, но это почти одно и то же) и отправьте в MongoDB. Нет никакого маппинга свойств или типов. Эта простота определённо должна подходить вам, как конечному разработчику.

Запись

Кроме указанных факторов производительности, при логгировании как раз может оказаться полезной гибкая структура данных . Наконец, в MongoDB есть такое понятие, как ограниченная коллекция (capped collection). До сих пор мы создавали обыкновенные коллекции. Мы можем создать ограниченную коллекцию с помощью команды db.createCollection , включив флаг capped :

Когда наша ограниченная коллекция достигнет размера в 1 мегабайт , старые документы начнут автоматически удаляться. Можно также задать не размер коллекции, а максимальное количество документов, с помощью опции max . У ограниченных коллекций есть ряд интересных свойств. Например, можно изменить документ, но он не может вырасти в размере. Также сохраняется порядок вставки, так что не нужно добавлять дополнительное поле для хронологической сортировки.

Также стоит заметить, что если нужно выяснить, вызвала ли ваша запись какие-либо ошибки (как, например, в уже упомянутом случае, когда мы не дожидаемся её завершения), можно просто выполнить следующую команду: db.getLastError() . Большинство драйверов инкапсулируют эту функцию, как безопасную запись , например, можно указать вторым параметром метода insert .

Устойчивость

MongoDB до версии 1.8 не обеспечивала устойчивости данных на одном сервере. Так, отказ сервера мог привести к потере данных. Решение всегда состояло в работе MongoDB на нескольких серверах (MongoDB поддерживает репликацию). Одной из самых важных функций, добавленных в MongoDB 1.8, стало журналирование . Чтобы включить его, добавьте journal=true в файл mongodb.config , созданный нами при первой настройке MongoDB (и перезапустите сервер , чтобы изменения вступили в силу). Скорее всего, журналирование вам понадобится (в следующих релизах по умолчанию оно будет включено). Несмотря на некоторое увеличение производительности , которое может быть достигнуто при отключении журналирования, возможен определенный риск. (С другой стороны, бывают приложения, которые допускают потерю некоторых данных).

Устойчивость данных упоминается здесь потому, что много сил было затрачено для того, чтобы добиться её в пределах одного сервера. Вы рано или поздно найдёте в Google упоминания о ненадёжности Mongo как хранилища. Однако эта информация уже устарела.

Полнотекстовый поиск

В будущих релизах, надеюсь, полнотекстовый поиск придёт в MongoDB. С поддержкой для массивов базовый полнотекстовый поиск будет довольно просто применять. Для мощных приложений скорее всего понадобится использовать нечто вроде Lucene или Solr. Конечно также это справедливо и для реляционных баз данных.

Транзакции

MongoDB не поддерживает транзакций. Есть две альтернативы: одна - замечательная, но ограниченная в использовании, а другая - громоздкая, но гибкая.

Первая альтернатива - это множество атомарных операций. Они прекрасны до тех пор, пока решают вашу проблему. Мы уже видели некоторые из них, например, $inc и $ set . Также существуют команды вроде findAndModify которые могут обновлять или удалять документ и автоматически его возвращать.

Вторая альтернатива - когда атомарных операций не хватает - это двухфазный коммит. Двухфазный коммит по сравнению с транзакциями - это примерно то же самое, что ручное разруливание запросов по сравнению с JOIN-ами. Это независимое от хранилища решение, которое вы осуществляете в коде. Также двухфазный коммит достаточно распространён в реляционном мире, когда нужно обеспечить транзакции в пределах нескольких баз данных. На сайте MongoDB есть пример иллюстрирующий наиболее распространённый сценарий (перевод денежных средств). Общая идея состоит в том, что вы храните состояние транзакции внутри обновляющегося документа и проходите шаги init-pending-commit/rollback вручную.

Поддержка вложенных документов и бесструктурная архитектура MongoDB делают двухфазные коммиты не такими уж страшными, но всё равно это сложный процесс, особенно для тех, кто впервые с этим сталкивается.

Обработка данных

Для большинства задач обработки данных MongoDB использует MapReduce. Есть, конечно, некоторые базовые агрегирующие функции, но для чего-либо серьёзного вам понадобится MapReduce. В следующей главе мы рассмотрим MapReduce более детально. Сейчас можете считать его очень мощным и альтернативным вариантом group by (что, впрочем, будет преуменьшением его возможностей). Одно из преимуществ MapReduce в том, что для работы с большими объёмами данных он может выполняться параллельно. Однако реализация MongoDB основана на JavaScript, который сам по себе однопоточен. Что из этого следует? Для обработки больших данных вам, скорее всего, придётся полагаться на что-то другое, например, на Hadoop. К счастью, эти две системы настолько дополняют друг друга, что существует MongoDB адаптер для Hadoop.

Конечно, распараллеливание обработки данных не является однозначным предметом превосходства реляционных баз данных. В будущих релизах MongoDB планируется улучшить обработку огромных объёмов данных.

Геопространственные данные

Особенно мощной функцией MongoDB является её поддержка геопространственных индексов. Это позволяет сохранять x- и y- координаты у документов и затем находить документы вблизи ($near) определённых координат, или внутри ($within) прямоугольника либо окружности. Это легче понять визуально, поэтому я советую посмотреть пятиминутный практикум по геопространственным функциям MongoDB, если хотите углубить свои знания.

Инструментарий и зрелость

Вы уже, наверное, знаете - MongoDB значительно младше большинства реляционных баз данных. Это обязательно нужно учитывать. Насколько большую роль это играет - зависит от ваших задач и их реализации. Нельзя игнорировать тот факт, что MongoDB - молодая технология, и доступный инструментарий еще не очень разнообразен (впрочем, инструментарий зрелых реляционных баз данных бывает подчас просто ужасен). Например, отсутствие поддержки десятичных чисел с плавающей запятой, очевидно, будет проблемой (хотя и не обязательно непреодолимой) для систем, имеющих дело с деньгами.

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

В этой главе

Идея этой главы в том, что MongoDB в большинстве случаев способна стать заменой реляционной базе данных. Она намного проще и понятнее; быстрее работает и имеет меньше ограничений для разработчиков приложений. Отсутствие транзакций может вызывать серьёзную и правомочную озабоченность. Однако, когда спрашивают какое место занимает MongoDB в экосистеме современных механизмов хранения?, ответ прост: строго посередине.

Будет ли MongoDB правильным выбором для вашего приложения?

Выбор базы данных — важный этап разработки приложения. Неправильный выбор может негативно сказаться как на процессах разработки и сопровождения вашего продукта, так и привести к снижению производительности.

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

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

В этой статье мы обсудим несколько возможностей MongoDB, которые стоит знать прежде чем вы решитесь выбрать и развернуть ее.

MongoDB работает с JSON-документами и разработчикам это нравится

Базовым компонентом MongoDB является документ, очень похожий на JSON. Технически это BSON, который содержит некоторые дополнительные данные (например, datetime), которые недопустимы в JSON.

Мы можем рассматривать документ как запись в реляционной базе данных. Документы помещаются в коллекции, которые соответствует концепции таблиц в реляционной базе данных.

JSON-документы очень популярны среди программистов и используются при разработке веб-сервисов, приложений и для обмена данными. Работать с базой данных со встроенной поддержкой таких данных может быть действительно эффективно.

Разработчики часто выбирают MongoDB, потому что ее можно начать использовать без специальных знаний об администрировании и проектировании баз данных, а также без изучения сложного языка запросов. Язык запросов MongoDB также представлен в формате JSON документов.

Разработчики могут легко создавать, сохранять, запрашивать и изменять JSON-документы. Здорово! Обычно это значительно ускоряет разработку.

В MongoDB нет схемы

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

Реляционная схема требует предопределенной и фиксированной структуры таблиц. Каждый раз, когда вы добавляете или изменяете столбец, вам необходимо выполнить DDL-запрос, и приложить дополнительные усилия, чтобы изменить код вашего приложения для работы с новой структурой. В случае значительных изменений, требующих изменения нескольких столбцов и/или создания новых таблиц, изменения в приложении могут быть весьма значительными. Отсутствие схемы в MongoDB означает, что ничего из этого не требуется. Вы просто добавляете документ в коллекцию и все. Например, у вас есть коллекция с данными пользователя. Если в какой-то момент вам нужно добавить новое поле "date_of_birth", вы просто начинаете работать с новыми JSON-документами с дополнительным полем. И все. Нет необходимости менять что-либо в схеме.

Вы также можете вставлять в одну и ту же коллекцию совершенно разные JSON-документы, представляющие разные сущности. Технически это осуществимо, но все же так делать не рекомендуется.

MongoDB также значительно сокращает цикл разработки приложения по нетехнической причине — устраняется необходимость координации миграции изменений схемы базы данных с DBA. Нет необходимости ждать, пока команда DBA еще раз все проверит и выпустит релиз в продакшн (с планами отката), что, как правило, потребует еще и некоторого простоя.

В MongoDB нет внешних ключей, хранимых процедур и триггеров. JOIN поддерживается, но не приветствуется

Проектирование реляционной базы данных должно осуществляться с учетом того, чтобы SQL-запросы могли выполнять различные JOIN для нескольких таблиц по определенным колонкам. Также необходимо предусматривать внешние ключи (foreign key) для контроля целостности данных и автоматических изменений в связанных полях.

Что насчет хранимых процедур? Хранимые процедуры могут быть полезны для встраивания в базу данных некоторой логики приложения для упрощения ряда задач или повышения безопасности.

А триггеры? Триггеры нужны для автоматического инициирования изменений данных при определенных событиях, таких как добавление / изменение / удаление строк. Они помогают управлять согласованностью данных и, в некоторых случаях, упростить код приложения. Но они отсутствуют в MongoDB. Так что имейте это в виду.

Примечание: честно говоря, есть агрегирование, которое может реализовать то же самое, что и LEFT JOIN, но это единственный случай.

Как жить без JOIN?

Соединение (JOIN) должно выполняться в коде вашего приложения. Если требуется выполнить JOIN двух коллекций, то сначала нужно прочитать первую, выбрать поле для JOIN и использовать его для запроса второй коллекции и т.д. Это кажется весьма дорогим с точки зрения разработки приложения и может привести к увеличению количества запросов. И это действительно так. Хорошая новость заключается в том, что в большинстве случаев вам не придется использовать JOIN.

Помните, что MongoDB — это база данных без схемы, не требующая нормализации. Если вы правильно спроектируете коллекции, то сможете встраивать (embed) и дублировать данные в одной коллекции без необходимости создания дополнительных коллекций. Таким образом, вам не придется выполнять соединение, потому что все данные, которые вам нужны, уже будут в одной коллекции.

Внешние ключи не поддерживаются. Но так как можно встраивать в одну коллекцию несколько документов, они вам просто не нужны.

Хранимые процедуры могут быть легко реализованы в виде внешних скриптов, написанных на любом языке программирования. Триггеры также реализуются снаружи с помощью Change Stream API.

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

Очень просто развернуть репликацию и шардирование

MongoDB изначально разрабатывалась для работы в распределенных окружениях. Она была задумана как часть большого пазла. Для реализации репликации и шардирования сервер mongod может работать совместно с другими экземплярами mongod без использования каких-либо сторонних инструментов.

Replica Set (набор реплик) — это группа процессов mongod, которые обслуживают один и тот же набор данных, обеспечивая избыточность и высокую доступность. С оговорками, касающимися потенциально устаревших данных, вы также бесплатно получаете масштабируемость чтения. Для продакшн-решения всегда следует применять такую конфигурацию.

Sharding Cluster развертывается как группа из нескольких Replica Set с возможностью разделения и равномерного распределения данных по ним. В дополнение к избыточности, высокой доступности и масштабируемости чтения Sharding Cluster обеспечивает масштабируемость записи. Топология шардинга подходит для развертывания очень больших наборов данных. Количество шардов, которые вы можете добавить, теоретически не ограничено.

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

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

Дополнительные материалы:

В MongoDB есть индексы, и они очень важны

В MongoDB можно создавать индексы для полей JSON-документа. Индексы используются так же, как и в реляционных базах данных для ускорения выполнения запросов и уменьшения использования ресурсов компьютера: памяти, времени процессора и операций ввода-вывода в секунду (IOPS).

Для всех регулярно выполняемых запросов, операций изменения и удаления данных необходимо создавать необходимые индексы, которые помогут ускорить их выполнение.

MongoDB обладает очень мощными возможностями индексирования. Есть TLL-индексы, GEO Spatial — индексы для пространственных данных, индексы для элементов массива, частичные (partial) и разреженные (sparse) индексы. Если вы хотите подробнее изучить доступные типы индексов, вы можете обратиться к следующим статьям:

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

MongoDB требует много памяти

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

MongoDB использует оперативную память для кэширования наиболее часто и недавно используемых данных и индексов. Чем больше этот кэш, тем лучше будет общая производительность, потому что MongoDB сможет быстрее извлекать большой объем данных. Кроме того, изменения данных происходят в памяти. Запись на диск выполняется асинхронно: сначала в файл журнала (обычно в пределах 50 мс), а затем в обычные файлы данных (один раз в минуту).

WiredTiger — наиболее популярный движок хранения данных, используемый в MongoDB. Раньше это был MMAPv1, но в последних версиях он больше не доступен. Движок хранения WiredTiger использует кэш памяти (WiredTiger Cache) для кэширования данных и индексов.

Помимо WTCache, для доступа к диску MongoDB использует кэш файловой системы. Это еще одна важная оптимизация, для которой также может потребоваться значительный объем памяти.

Кроме того, MongoDB использует память для управления клиентскими соединениями, выполнения сортировки в памяти, временных данных при выполнении пайплайнов агрегации и другого.

Будьте готовы обеспечить MongoDB достаточным объемом памяти.

Но сколько нужно памяти? Эмпирическим правилом является оценка размера "рабочего набора".

"Рабочий набор" — это данные, которые чаще всего запрашиваются вашим приложением. Типичное приложение работает с ограниченным объемом данных. При обычной работе ему не нужны все данные. Например, в случае с временными рядами (time-series data), скорее всего, вам нужно будет получить только последние несколько часов или дней. Только в редких случаях вам понадобится читать более старые данные. В таком случае в вашем рабочем наборе может будут храниться данные только за несколько дней.

Предположим, что ваш набор данных составляет 100 ГБ, и вы оценили ваш рабочий набор в 20%, тогда вам потребуется как минимум 20 ГБ для WTCache.

Так как по умолчанию для WTCache используется 50% памяти (обычно мы рекомендуем не увеличивать ее значительно), то на сервере должно быть 40 ГБ памяти.

Каждый случай индивидуален, и иногда бывает трудно правильно оценить размер рабочего набора. В любом случае, основная рекомендация заключается в том, что вы должны предоставить максимальное количество памяти, которое можете себе позволить. Это будет полезно для MongoDB.

В каких случаях использовать MongoDB?

На самом деле таких ситуаций очень много. Я видел использование MongoDB в самых разных приложениях.

Мы используем MongoDB уже несколько недель, общая тенденция, которую мы видели, заключается в том, что mongodb использует слишком много памяти (намного больше, чем весь размер его набора данных + индексы).

Я уже прочитал этот вопрос и этот вопрос , но, похоже, никто не решает проблему, с которой я столкнулся, они фактически объясняют то, что уже объяснено в документации.

Ниже приведены результаты команд htop и show dbs .

Я знаю, что mongodb использует IO с отображением в памяти, поэтому в основном ОС обрабатывает кэширование в памяти, и mongodb должен теоретически освобождать свою кэшированную память, когда другой процесс запрашивает свободную память , но, как мы видели, это не так.

OOM начинает работу, убивая другие важные процессы, такие как postgres, redis и т. Д. (Как можно видеть, чтобы преодолеть эту проблему, мы увеличили объем ОЗУ до 183 ГБ, который сейчас работает, но довольно дорогой. Монго использует

87 ГБ ОЗУ, почти в 4 раза больше, чем весь его набор данных)

Итак, после следования подсказкам, данным loicmathieu и jstell, и немного покопав их, вот что я узнал о MongoDB, используя механизм хранения WiredTiger. Я ставлю это здесь, если кто-то сталкивался с такими же вопросами.

Потоки памяти, о которых я упоминал, все принадлежали 2012-2014 годам , все предшествующие WiredTiger и описывают поведение исходного механизма хранения MMAPV1, который не имеет отдельного кэша или поддержки сжатия.

Настройки кэша WiredTiger контролируют только объем памяти, непосредственно используемый механизмом хранения WiredTiger (но не общий объем памяти, используемый mongod). Многие другие вещи могут занимать память в конфигурации MongoDB / WiredTiger, например:

WiredTiger сжимает дисковое хранилище, но данные в памяти не сжимаются.

WiredTiger по умолчанию не синхронизирует данные при каждом коммите , поэтому файлы журнала также находятся в оперативной памяти, что сказывается на памяти. Также упоминается, что для эффективного использования операций ввода-вывода WiredTiger объединяет запросы ввода-вывода (ошибки кэширования), что также требует некоторой оперативной памяти (на самом деле грязные страницы (страницы, которые были изменены / обновлены) имеют список обновлений). на них хранятся в параллельном SkipList ).

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

WiredTiger Сохраняет контрольные суммы данных в кеше.

Сам MongoDB использует память для обработки открытых соединений, агрегатов, серверного кода и т . Д.

Учитывая эти факты, полагаться на show dbs; это не было технически правильно, так как он показывает только сжатый размер наборов данных.

Следующие команды могут использоваться для получения полного размера набора данных.

Эти результаты следующие:

Таким образом, кажется, что фактический размер набора данных + его индексы занимают около 68 ГБ этой памяти.

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

Также остается проблема OOM, чтобы преодолеть эту проблему, так как у нас не было достаточно ресурсов, чтобы убрать mongodb, мы понизили oom_score_adj, чтобы OOM не убивал важные процессы на данный момент (то есть мы сказали OOM не убивать наши желаемые процессы ).

Я использую Mongo-DBv1.8.1. Моя память сервера составляет 4 ГБ, но Mongo-DB использует более 3 ГБ. Есть ли опция ограничения памяти в Mongo-DB?.

ОТВЕТЫ

Ответ 1

Если вы используете MongoDB 3.2 или более позднюю версию, вы можете ограничить wiredTiger кеш, как упомянуто выше.

В /etc/mongod.conf добавьте часть wiredTiger

Это ограничит размер кэша до 1 ГБ, больше информации в Документе

Это решило проблему для меня, запустив ubuntu 16.04 и mongoDB 3.2

PS: после изменения конфигурации перезапустите демон mongo.

Ответ 2

Начиная с 3.2, MongoDB использует WiredTiger в качестве механизма хранения по умолчанию. В предыдущих версиях MMAPv1 использовался как механизм хранения по умолчанию.

С помощью WiredTiger MongoDB использует как внутренний кеш WiredTiger, так и кеш файловой системы.
В MongoDB 3.2 внутренний кеш WiredTiger по умолчанию будет использовать больше: 60% оперативной памяти минус 1 ГБ или 1 ГБ.
Для систем с ОЗУ до 10 ГБ новый параметр по умолчанию меньше или равен настройке по умолчанию 3.0 (для MongoDB 3.0 внутренний кеш WiredTiger использует либо 1 ГБ, либо половину установленной физической ОЗУ, в зависимости от того, какая из них больше). Для систем с объемом памяти более 10 ГБ новая настройка по умолчанию больше, чем настройка 3.0.

чтобы ограничить проводной кэшированный кеш Добавьте следующую строку в файл .config:

wiredTigerCacheSizeGB = 1

Ответ 3

Этот вопрос был задан пару раз.

MongoDB будет (по крайней мере, кажется) использовать много доступной памяти, но на самом деле она оставляет за VMM ОС сказать ей освободить память (см. Кэширование в документации MongoDB.)

Вы должны иметь возможность освободить всю память, перезапустив MongoDB.

Однако в некоторой степени MongoDB на самом деле не "использует" память.

В зависимости от платформы вы можете видеть отображенные файлы как память в процессе, но это не совсем правильно. Unix top может показывать больше памяти для mongod, чем на самом деле уместно. Операционная система (в частности, диспетчер виртуальной памяти, в зависимости от ОС) управляет памятью, в которой находятся файлы с отображением в памяти. Этот номер обычно отображается в программе типа "free -lmt".

Это называется "кэшированная" память.

MongoDB использует алгоритм кэширования LRU (Least недавно Used), чтобы определить, какие "страницы" выпустить, вы найдете больше информации в этих двух вопросах.

MongoDB ограничить память
Соотношение индекса/оперативной памяти MongoDB
Mongod начать с ограничения памяти (вы не можете.)

Ответ 4

Вы можете ограничить использование процесса mongod, используя cgroups в Linux.

Используя cgroups, наша задача может быть выполнена в несколько простых шагов.

Создать контрольную группу:

(убедитесь, что двоичные файлы cgroups установлены в вашей системе, обратитесь к вашему любимому руководству по дистрибутиву Linux, чтобы узнать, как это сделать)

Укажите, сколько памяти будет доступно для этой группы:

Эта команда ограничивает память до 16G (хорошо, что она ограничивает память как для выделения памяти, так и для кэша ОС)

Теперь будет хорошей идеей удалить страницы, которые остались в кеше:

И, наконец, назначьте сервер для созданной контрольной группы:

Это назначит запущенный процесс mongod группе, ограниченной только 16 ГБ памяти.

Ответ 5

Я не думаю, что вы можете настроить, сколько памяти используется MongoDB, но это ОК (читайте ниже).

Цитировать из официального источника :

Размер виртуальной памяти и резидентный размер будут очень большими для процесса mongod. Это доброкачественное: пространство виртуальной памяти будет просто больше, чем размер файлов данных, открытых и отображенных; размер резидента будет варьироваться в зависимости от объема памяти, не используемого другими процессами на машине.

Другими словами, Mongo позволит другим программам использовать память, если они попросят об этом.

Ответ 6

Для Windows кажется возможным контролировать объем памяти, которую использует MongoDB, см. в этом уроке у капитана Кодемана:

Ответ 7

Не совсем, есть несколько приемов для ограничения памяти, например, в Windows вы можете использовать диспетчер системных ресурсов Windows (WSRM), но, как правило, Mongo лучше всего работает на выделенном сервере, когда он свободно использует память без особых конфликтов с другими системами.

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

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

Ответ 8

Ответ 9

Ответ 10

Одна вещь, которую вы можете ограничить - это объем памяти, который использует mongodb при построении индексов. Это устанавливается с помощью параметра maxIndexBuildMemoryUsageMegabytes . Пример того, как его набор ниже:

Ответ 11

Нет никаких причин ограничивать кэш MongoDB, так как по умолчанию процесс mongod будет занимать половину памяти на машине и не более. Механизм хранения по умолчанию - WiredTiger. "С WiredTiger MongoDB использует как внутренний кеш WiredTiger, так и кеш файловой системы".

Вы, вероятно, смотрите сверху и предполагаете, что Mongo использует всю память на вашем компьютере. Это виртуальная память. Используйте бесплатно -m:

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

Используйте эти две команды в консоли mongod, чтобы получить информацию о том, сколько виртуальной и физической памяти использует Mongodb:

Ответ 12

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

Ответ 13

Добавив ответ с наибольшим количеством голосов, если вы работаете на компьютере с нехваткой памяти и хотите сконфигурировать wiredTigerCache в МБ, а не в целых ГБ, используйте это -

Читайте также: