Sono le dimensioni del working set più gli indici di MongoDB che dovrebbero idealmente risiedere nella RAM in ogni momento, cioè la quantità di RAM disponibile dovrebbe essere almeno la dimensione del working set più la dimensione degli indici più ciò che il resto del SO (Sistema operativo) e altri software in esecuzione sulle stesse esigenze della macchina. Se la RAM disponibile è inferiore, LRUing è ciò che accade e potremmo quindi ottenere un rallentamento significativo. Una cosa da tenere a mente è che in un indice btree vengono memorizzati i bucket, non le singole chiavi dell'indice, cioè se avessimo una distribuzione uniforme delle chiavi in un indice incluso per i dati storici, potremmo aver bisogno di più dell'indice nella RAM rispetto a quando abbiamo un indice composto in tempo più qualcos'altro. Con quest'ultimo, le chiavi nello stesso secchio sono di solito della stessa epoca, quindi questo avvertimento non accade. Inoltre, dovremmo tenere presente che i nostri nomi di campo in BSON sono memorizzati nei record (ma non nell'indice), quindi se siamo sotto pressione di memoria dovrebbero essere mantenuti a breve.
Coloro che sono interessati all'utilizzo attuale della memoria virtuale di MongoDB (che ovviamente riguarda anche la RAM), possono dare un'occhiata allo stato di mongod.
@see http://www.markus-gattol.name/ws/mongodb.html#sec7
Per calcolare con precisione 'set' di lavoro, diciamo che ho una singola raccolta. Quindi, esegui 'db.collection.stats()'. Il 'filesize' o' datasize' indica il mio "working set?" –