it-swarm.com.de

MongoDB wird beendet, wenn nicht genügend Speicher vorhanden ist

Ich habe die folgende Konfiguration:

  • ein Host-Computer, auf dem drei Docker-Container ausgeführt werden:
    • MongoDB
    • Redis
    • Ein Programm, das die beiden vorherigen Container zum Speichern von Daten verwendet

Sowohl Redis als auch MongoDB werden zum Speichern großer Datenmengen verwendet. Ich weiß, dass Redis alle seine Daten in RAM und ich bin damit einverstanden) aufbewahren muss. Leider nimmt Mongo eine Menge RAM) auf und sobald der Host RAM voll ist (wir sprechen hier von 32 GB)), stürzt entweder Mongo oder Redis ab.

Ich habe die folgenden vorherigen Fragen dazu gelesen:

  1. Limit MongoDB RAM Usage : anscheinend die meisten RAM wird vom WiredTiger-Cache verbraucht
  2. MongoDB Limit Memory : Hier war anscheinend das Problem Protokolldaten
  3. Begrenzen Sie die RAM Speicherauslastung in MongoDB : Hier wird vorgeschlagen, den Speicher von Mongo so zu begrenzen, dass weniger Speicher für Cache/Protokolle/Daten verwendet wird
  4. MongoDB verwendet zu viel Speicher : Hier heißt es, dass es sich um ein WiredTiger-Caching-System handelt, das tendenziell so viel RAM wie möglich) verwendet, um einen schnelleren Zugriff zu ermöglichen. Außerdem wird it's completely okay to limit the WiredTiger cache size, since it handles I/O operations pretty efficiently
  5. Gibt es eine Option, um die Speicherbelegung von Mongodb einzuschränken? : Beim erneuten Zwischenspeichern wird auch MongoDB uses the LRU (Least Recently Used) cache algorithm to determine which "pages" to release, you will find some more information in these two questions hinzugefügt
  6. MongoDB-Index/RAM-Beziehung : quote: MongoDB keeps what it can of the indexes in RAM. They'll be swaped out on an LRU basis. You'll often see documentation that suggests you should keep your "working set" in memory: if the portions of index you're actually accessing fit in memory, you'll be fine.
  7. wie wird das von MongoDB verwendete Caching freigegeben? : gleiche Antwort wie in 5.

Was ich aus all diesen Antworten zu verstehen scheine, ist Folgendes:

  1. Für einen schnelleren Zugriff ist es für Mongo besser, alle Indizes in den RAM zu passen. In meinem Fall kann ich jedoch Indizes verwenden, die sich teilweise auf der Festplatte befinden, da ich eine recht schnelle SSD habe.
  2. RAM wird hauptsächlich zum Zwischenspeichern durch Mongo verwendet.

In Anbetracht dessen hatte ich erwartet, dass Mongo versuchen würde, so viel RAM Speicherplatz wie möglich) zu verwenden, aber auch mit wenigen RAM Speicherplatz) funktionieren zu können und die meisten Dinge abzurufen Festplatte. Ich habe jedoch den Speicher des Mongo Docker-Containers (zum Beispiel auf 8 GB) begrenzt, indem ich --memory und --memory-swap verwendet habe. Statt jedoch Daten von der Festplatte abzurufen, stürzte Mongo einfach ab, sobald sie leer war der Erinnerung.

Wie kann ich Mongo zwingen, nur den verfügbaren Speicher zu verwenden und alles von der Festplatte abzurufen, was nicht in den Speicher passt?

11
Simone Bronzini

Gemäß MongoDB BOL Here In Version 3.4 geändert: Die Werte können von 256MB Bis 10TB und kann ein float sein. Außerdem hat sich der Standardwert geändert.

Ab 3.4 Verwendet der interne Cache WiredTiger standardmäßig den größeren von beiden:

50% of RAM minus 1 GB, or
256 MB.

Mit WiredTiger verwendet MongoDB sowohl den WiredTiger internal cache Als auch den filesystem cache.

Über den filesystem cache Verwendet MongoDB automatisch den gesamten freien Speicher, der nicht vom WiredTiger cache Oder von anderen Prozessen verwendet wird.

Der storage.wiredTiger.engineConfig.cacheSizeGB begrenzt die Größe des internen Caches WiredTiger. Das Betriebssystem verwendet den verfügbaren freien Speicher für den Dateisystem-Cache, sodass die komprimierten MongoDB-Datendateien im Speicher bleiben können. Darüber hinaus verwendet operating system Jedes freie RAM, um Dateisystemblöcke und Dateisystem-Cache zu puffern.

Um die zusätzlichen Konsumenten von [~ # ~] ram [~ # ~] aufzunehmen, müssen Sie möglicherweise die interne Cache-Größe WiredTiger verringern .

Weitere Informationen finden Sie unter WiredTiger Storage Engine und Konfigurationsdateioptionen

9

Wenn Sie genau hinschauen, ist es nicht Mongod, der für "Out-of-Memory" stirbt, sondern der Kernel-OOM-Manager (Out of Memory), der Mongod tötet, weil er die größte Speichernutzung hat.

Ja, Sie können versuchen, das Problem mit dem Monngodb-Konfigurationsparameter cacheSizeGB zu lösen. In der Containerumgebung ist es jedoch besser, cgroups zu verwenden, um die Ressourcen einer Ihrer drei zu begrenzen Container bekommen.

4
JJussi