
Мы запускаем небольшой набор реплик mongodb на трех физических серверах (без виртуализации, без docker/kubernetes) с Debian 11 и mongodb 5.0.6:
машинаA: 128 ГБ ОЗУ, диск 1 ТБ, ПЕРВИЧНАЯ машинаB: 128 ГБ ОЗУ, диск 1 ТБ, ВТОРИЧНАЯ машинаC: 8 ГБ ОЗУ, диск 20 ГБ, АРБИТР
Внезапно мы сталкиваемся с перебоями в работе и ошибками в журнале приложений, такими как «NotWritablePrimary»/«MongoNotPrimaryException» — мы предполагали, что наша строка подключения гарантирует отсутствие перебоев:
mongodb://machineA:27017,machineB:27017/?replicaSet=MyRepl&waitQueueMultiple=10&readPreference=primaryPreferred
Оказалось, что ПЕРВИЧНЫЙ экземпляр mongodb был убит ядром linux, так как он потреблял слишком много оперативной памяти. Набор реплик теперь работал 3 месяца без проблем в любое время. Но внезапно я вижу потребление оперативной памяти таким образом:
Внезапно mongodb обнаружил огромное потребление оперативной памяти:
Сразу после того, как ядро убило процесс mongod, он был перезапущен SystemD, поскольку он работает как служба. Но сразу после перезапуска он снова потребляет максимальный объем оперативной памяти, пока снова не умирает.
Внезапно это поведение прекратилось сегодня утром. Мы ничего не меняли в нашем приложении, поэтому теперь вопрос: что съедает так много оперативной памяти в процессе mongodb?
Насколько мне известно, движок WireTiger использует ~50% доступной оперативной памяти, но это не объясняет максимальное использование всей оперативной памяти машины. У меня также есть некоторые метрики из Percona mongodb_exporter, которые показывают, что оперативная память используется mongodb и никаким другим процессом в системе:
Интересно, что использование памяти ВТОРИЧНОЙ в то время вообще не менялось:
Есть ли у кого-нибудь идеи или намеки на то, что здесь происходит?
решение1
Мы обнаружили, что один из наших сервисов приложений при определенных обстоятельствах давал сбои, и нам было сложно это заметить.
При постоянном долблении MongoDb кажется, что использование памяти становится все больше и больше, вместо того, чтобы использовать больше ресурсов ЦП, как я ожидал. В определенный момент процесс mongod был убит ядром linux.
После того, как мы исправили проблему в нашем приложении, ситуация исчезла.