MongoDB termina quando si esaurisce la memoria


11

Ho la seguente configurazione:

  • un computer host che esegue tre contenitori docker:
    • MongoDB
    • Redis
    • Un programma che utilizza i due contenitori precedenti per memorizzare i dati

Sia Redis che MongoDB vengono utilizzati per archiviare enormi quantità di dati. So che Redis ha bisogno di conservare tutti i suoi dati nella RAM e sto bene. Sfortunatamente, ciò che accade è che mongo inizia a occupare molta RAM e non appena la RAM host è piena (stiamo parlando di 32 GB qui), o mongo o Redis si arresta in modo anomalo.

Ho letto le seguenti domande precedenti su questo:

  1. Limita l'utilizzo della RAM MongoDB : apparentemente la maggior parte della RAM viene utilizzata dalla cache WiredTiger
  2. Memoria limite MongoDB : qui apparentemente il problema erano i dati di registro
  3. Limita l'utilizzo della memoria RAM in MongoDB : qui suggeriscono di limitare la memoria di mongo in modo che utilizzi una quantità minore di memoria per cache / log / dati
  4. MongoDB utilizza troppa memoria : qui dicono che è il sistema di memorizzazione nella cache WiredTiger che tende a utilizzare quanta più RAM possibile per fornire un accesso più veloce. Inoltre affermanoit's completely okay to limit the WiredTiger cache size, since it handles I/O operations pretty efficiently
  5. C'è qualche opzione per limitare l'utilizzo della memoria di mongodb? : cache di nuovo, aggiungono ancheMongoDB uses the LRU (Least Recently Used) cache algorithm to determine which "pages" to release, you will find some more information in these two questions
  6. Indice MongoDB / relazione RAM : citazione: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. come rilasciare la memorizzazione nella cache che viene utilizzata da MongoDB? : stessa risposta di 5.

Ora quello che sembra capire da tutte queste risposte è che:

  1. Per un accesso più veloce sarebbe meglio per mongo adattare tutti gli indici nella RAM. Tuttavia, nel mio caso, sto bene con gli indici parzialmente residenti su disco poiché ho un SSD abbastanza veloce.
  2. La RAM viene utilizzata principalmente per la memorizzazione nella cache da mongo.

Considerando questo, mi aspettavo che mongo provasse a utilizzare la maggior quantità di spazio RAM possibile, ma potendo funzionare anche con poco spazio RAM e recuperare la maggior parte delle cose dal disco. Tuttavia, ho limitato la memoria del contenitore di mongo Docker (ad esempio a 8 GB), usando --memorye --memory-swap, invece di recuperare roba dal disco, mongo si è semplicemente schiantato non appena ha esaurito la memoria.

Come posso forzare mongo a usare solo la memoria disponibile e a recuperare dal disco tutto ciò che non si adatta alla memoria?


Si chiama OOM Killer. MongoDB è progettato per funzionare su hardware di largo consumo. Non l'avrei mai eseguito su risorse artificialmente limitate. Se hai solo un piccolo database, MongoDB non è la scelta ideale. Se si dispone di un database di grandi dimensioni (da tre milioni a un miliardo di voci), limitare le risorse è una scelta sbagliata. Secondo il tuo problema: non puoi avere la torta e mangiarla. Scegliere.
Markus W Mahlberg,

Se configurato correttamente, MongoDB non dovrebbe arrestarsi in modo anomalo quando la memoria è esaurita. Puoi confermare la versione specifica del server MongoDB e O / S che stai utilizzando e anche descrivere il crash in modo più dettagliato? Ad esempio, ci sono messaggi nel registro MongoDB o dmesgcorrelati all'arresto imprevisto? La possibilità più probabile con Docker è che i processi nel contenitore rilevino la RAM complessiva disponibile anziché il limite del contenitore.
Stennie il

Come per le MongoDB Note di produzione : se si esegue mongodin un contenitore ( lxc, cgroups, Portuale, etc.) che si fa , non hanno accesso a tutta la RAM disponibile in un sistema, è necessario impostare storage.wiredTiger.engineConfig.cacheSizeGBun valore inferiore alla quantità di RAM disponibile Il container. L'importo esatto dipende dagli altri processi in esecuzione nel contenitore, ma in genere non dovrebbe essere superiore al valore predefinito del 50% della RAM meno 1 GB.
Stennie il

Risposte:


9

Come da MongoDB BOL qui modificato nella versione 3.4: I valori possono variare da 256MBa 10TBe possono essere a float. Inoltre, anche il valore predefinito è cambiato.

A partire da 3.4, la cache interna di WiredTiger , per impostazione predefinita, utilizzerà il più grande tra:

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

Con WiredTigerMongoDB utilizza sia WiredTiger internal cache che filesystem cache.

Tramite il filesystem cache, MongoDB utilizza automaticamente tutta la memoria libera che non viene utilizzata da WiredTiger cacheo da altri processi.

Lo storage.wiredTiger.engineConfig.cacheSizeGB limita la dimensione della WiredTigercache interna. Il sistema operativo utilizzerà la memoria disponibile disponibile per la cache del filesystem, che consente ai file di dati MongoDB compressi di rimanere in memoria. Inoltre, operating systemutilizzerà qualsiasi RAM libera per bufferizzare i blocchi del file system e la cache del file system.

Per soddisfare i consumatori aggiuntivi di RAM , potrebbe essere necessario ridurre WiredTigerla dimensione della cache interna.

Per ulteriori informazioni, fare riferimento al motore di archiviazione WiredTiger e alle opzioni del file di configurazione


4

In realtà, se guardi da vicino, non è mongod che muore per "memoria insufficiente", è il gestore OOM (memoria insufficiente) del kernel che uccide mongod, perché ha il più grande uso di memoria.

Sì, puoi provare a risolvere il problema con il parametro di configurazione monngodb cacheSizeGB , ma nell'ambiente container, è meglio usare cgroups per limitare le risorse ottenute da uno dei tuoi tre container.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.