Wir betreiben ein kleines MongoDB-Replikatset auf drei Bare-Metal-Servern (keine Virtualisierung, kein Docker/Kubernetes) mit Debian 11 und MongoDB 5.0.6:
MaschineA: 128 GB RAM, 1 TB Festplatte, PRIMÄR MaschineB: 128 GB RAM, 1 TB Festplatte, SEKUNDÄR MaschineC: 8 GB RAM, 20 GB Festplatte, ARBITER
Ganz plötzlich kommt es zu Ausfällen mit Fehlern in unserem Anwendungsprotokoll wie „NotWritablePrimary“/„MongoNotPrimaryException“ – wir gingen davon aus, dass unsere Verbindungszeichenfolge sicherstellen würde, dass es nicht zu Ausfällen kommt:
mongodb://machineA:27017,machineB:27017/?replicaSet=MyRepl&waitQueueMultiple=10&readPreference=primaryPreferred
Es stellte sich heraus, dass die PRIMÄRE MongoDB-Instanz vom Linux-Kernel beendet wurde, da sie zu viel RAM verbrauchte. Der Replikatsatz lief nun 3 Monate lang ohne Probleme. Aber plötzlich sehe ich einen RAM-Verbrauch wie diesen:
Ganz plötzlich kam es zu einer massiven RAM-Nutzung durch MongoDB:
Unmittelbar nachdem der Kernel den Mongod-Prozess beendet hat, wurde er von SystemD neu gestartet, da er als Dienst ausgeführt wird. Doch unmittelbar nach dem Neustart verbraucht er erneut die maximale Menge an RAM, bis er erneut abstürzt.
Dieses Verhalten hörte heute Morgen plötzlich auf. Wir haben an unserer Anwendung nichts geändert, daher lautet die Frage nun: Was frisst im MongoDB-Prozess so viel RAM?
Soweit ich weiß, nutzt die WireTiger-Engine etwa 50 % des verfügbaren RAM, aber das würde nicht die maximale Nutzung des gesamten RAM der Maschine erklären. Ich habe auch einige Messwerte von Percona mongodb_exporter, die zeigen, dass der RAM von mongodb und keinem anderen Prozess auf dem System genutzt wird:
Interessanterweise änderte sich der Speicherverbrauch des SECONDARY zu diesem Zeitpunkt überhaupt nicht:
Hat jemand eine Idee oder einen Hinweis, was hier los ist?
Antwort1
Wir haben festgestellt, dass einer unserer App-Dienste unter bestimmten Umständen außer Kontrolle geriet und wir das nur schwer erkennen konnten.
Beim ständigen Beanspruchen von MongoDb scheint der Speicherverbrauch immer höher zu werden, anstatt dass, wie erwartet, mehr CPU-Ressourcen genutzt werden. An einem bestimmten Punkt wurde der MongoDb-Prozess vom Linux-Kernel beendet.
Nachdem wir das Problem in unserer Anwendung behoben hatten, war die Situation behoben.