Назад | Перейти на главную страницу

Почему mongod не использует всю доступную оперативную память?

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

В частности, если я htop mongod, Я вижу:

У виртуальной машины ~ 60 ГБ памяти, в настоящее время «используется» ~ 4,6 ГБ, а остальная часть находится в буферах или кеше.

Насколько я понимаю, mongod mmaps файлы базы данных. (Вот почему VIRT огромен.) Однако нам не ясно, почему RES число не ближе к 60 ГБ: т.к. mongod нужны данные с диска, эти данные нужно занести в процессы RSS, не так ли? Mongo сообщает, что это ошибка страниц, поэтому можно предположить, что RSS со временем будет расти; наш держится стабильно.

На этой машине больше ничего значительного не работает. (Это сервер базы данных.) Что потребляет остальные буферы и кеш, и в частности, почему RES размер mongod не расширяется, чтобы заполнить доступную оперативную память?

Это может быть долгий и сложный процесс, но позвольте мне сначала сказать это в качестве отправной точки. Мне (и многим другим, с кем я работал) удалось приблизиться к максимальному использованию резидентной памяти. То, что это за максимум, будет варьироваться от системы к системе и имеет много переменных, которые вступают в игру, но я бы обычно ставил 60-80%, все, что выше, является бонусом.

Следующее, что нужно сделать, это немного почитать. Об этой теме было написано много, часто с другой точки зрения (повышение эффективности памяти, увеличение объема оперативной памяти при ее заполнении и т. Д.). Например:

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

Это подробно рассматривается в рамках длительного выпуска MongoDB Jira - СЕРВЕР-9415. При исследовании этой проблемы мы обнаружили, что поведение журнала при выполнении сочетания операций чтения и записи может (не всегда, но воспроизводимо) резко уменьшить резидентную память, о которой сообщается, для процесса MongoDB. Механика этого была подробно описана Кристина Ходоров здесь и более подробную информацию также можно найти в выпуске Jira.

Итак, что все это значит?

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

  • Читать в (прикоснуться или ручной предварительный нагрев с большим запросом / объяснением) большой известный объем данных, который должен уместиться в памяти
  • Выполните несколько запросов, агрегатов и т. Д. Для этого набора данных и убедитесь, что сбои страниц минимальны.
  • Если ошибок страниц мало, значит, данные умещаются в памяти, у вас проблема с отчетом. Вы можете повторять тесты с большими наборами данных, пока не найдете фактический предел.
  • Если количество ошибок страниц велико, значит, данные были вытеснены, не были полностью загружены и т. Д., И вам нужно что-то исследовать (опережающее чтение, нехватка памяти, убедитесь, что NUMA отключен и т. Д.)

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