2014-06-24 34 views
15

Sto cercando di capire quali siano i limiti di Arangodb e quale sia l'impostazione ideale. Da quello che ho capito, Arango memorizza tutti i dati della collezione nella memoria virtuale e idealmente vuoi che questo si adatti alla RAM. Se la collezione cresce e non può essere inserita nella RAM, verrà sostituita su disco.Utilizzo della memoria di ArangoDB

Quindi la mia prima domanda. Se il mio db cresce dovrò regolare la partizione/file di swap per sistemare il db?

Poiché arango sincronizza anche i dati su disco, ciò significa che i dati saranno sempre collocati nella RAM e nel disco? Quindi, se ho un db di 1.5 GB e la mia RAM è di 1 GB, avrò almeno 0,5 GB di spazio su disco di scambio e 1,5 GB di spazio su disco normale?

Sono un po 'confuso su come arango utilizza la memoria virtuale. In questo momento ho 7 collezioni praticamente vuote. Ho 1 GB di RAM e 1 GB di disco di scambio. L'amministratore riporta che arango utilizza 4,5 GB di memoria virtuale. Com'è possibile se il disco di scambio è 1GB? Attualmente utilizza 80 MB di RAM. Non dovrebbe essere 224 MB se la dimensione del journal è di 32 MB per ciascuna raccolta?

Qual è la raccomandazione sulla dimensione del giornale rispetto alla dimensione della raccolta? Questo può essere regolato dinamicamente man mano che la collezione cresce?

Che tipo di prestazioni sono previste se il disco di swap viene utilizzato molto quando il disco è un SSD? Se il disco di swap viene utilizzato molto, le prestazioni saranno simili all'utilizzo di un db più tradizionale come mysql?

risposta

33

ArangoDB memorizza tutti i dati in file mappati in memoria. Ogni raccolta può avere da 0 a n file di dati, con un file di default di 32 MB ciascuno (si noti che questa dimensione può essere regolata globalmente o su un livello per collezione). Una raccolta vuota (che non ha mai avuto dati) non avrà un file di dati. La prima scrittura in una raccolta creerà il file di dati e ogni volta che un file di dati è pieno verrà creato automaticamente un nuovo file.

Le raccolte allocano i file di dati in blocchi di 32 MB per impostazione predefinita. Se hai molte ma piccole collezioni questo potrebbe sprecare un po 'di memoria. Se si dispone di molte poche ma grandi collezioni, il potenziale spreco (spazio libero alla fine di un file di dati) probabilmente non importa troppo.

Ogni volta che un'operazione ArangoDB legge dati o scrive dati in un file di dati mappato in memoria, il sistema operativo prima tradurrà l'offset nel file in un numero di pagina. Questo perché ogni file di dati è implicitamente suddiviso in pagine di una dimensione specifica. Quanto è grande una pagina dipende dalla piattaforma, ma supponiamo che le pagine abbiano una dimensione di 4 KB. Quindi un file di dati con un file di default avrà 8192 pagine.

Dopo che il sistema operativo ha tradotto l'offset nel file in un numero di pagina, si accerterà che i dati della pagina richiesta siano presenti nella RAM fisica. Se la pagina non è ancora nella RAM fisica, il sistema operativo genererà un errore di pagina per attivare il caricamento della pagina richiesta dal disco o lo scambio nella RAM fisica. Questo alla fine renderà la pagina completa disponibile nella RAM, e qualsiasi lettura o scrittura dei dati della pagina potrebbe verificarsi successivamente.

Tutto ciò viene eseguito dal gestore della memoria virtuale del sistema operativo. Il sistema operativo è libero di mappare tante pagine da un file di dati nella RAM in quanto ritiene sia buona. Ad esempio, quando si accede in sequenza a un file mappato in memoria, il sistema operativo sarà probabilmente intelligente e riletta molte pagine, quindi sono già nella RAM fisica quando effettivamente si accede.

Il sistema operativo è anche libero di scambiare alcune o tutte le pagine di un file di dati. Scambierà probabilmente le pagine se non c'è abbastanza RAM fisica disponibile per mantenere tutte le pagine da tutti i file di dati nella RAM allo stesso tempo.Può anche scambiare pagine che non sono state utilizzate per un po ', per rendere la RAM disponibile per altre operazioni. Probabilmente utilizzerà un algoritmo LRU per questo.

Il modo in cui il gestore della memoria virtuale di un sistema operativo si comporta esattamente è molto diverso tra piattaforme e implementazioni. La maggior parte dei sistemi consente anche la configurazione del sottosistema VM. Ad esempio, here are some parameters for Linux's VM subsystem.

È quindi difficile stabilire la quantità di memoria fisica utilizzata da ArangoDB per un dato numero di raccolte e i relativi file di dati. Se le collezioni non sono affatto accessibili, avere i file di dati mappati in memoria potrebbe non utilizzare quasi nessuna RAM in quanto il sistema operativo ha probabilmente invertito le collezioni completamente o almeno parzialmente. Se le raccolte sono pesantemente in uso, il sistema operativo probabilmente avrà i propri file di dati completamente mappati nella RAM. Ma in entrambi i casi la memoria conta come mappata in memoria. Questo è possibile avere un utilizzo della memoria virtuale molto più alto rispetto alla RAM fisica.

Come accennato in precedenza, il sistema operativo deve fare molto lavoro quando si accede a pagine che non sono in RAM, e si vuole evitare questo se possibile. Se la dimensione totale delle raccolte utilizzate di frequente supera la dimensione della RAM fisica, il sistema operativo non ha altra alternativa che scambiare pagine e molto quando si accede a queste raccolte. L'utilizzo di un SSD per lo scambio sarà probabilmente migliore rispetto all'utilizzo di un HDD in rotazione, ma è ancora molto più lento dell'accesso alla RAM. Per farla breve: i dati delle raccolte attive (file di dati e indici) devono essere inseriti nella RAM fisica, se possibile, o si vedrà una grande quantità di attività del disco.

Oltre a ciò, ArangoDB non assegna solo memoria virtuale per i file di raccolta dati, ma avvia anche alcuni thread V8 (V8 è il motore JavaScript in ArangoDB) che utilizza anche memoria virtuale. Questa memoria virtuale non è supportata da file.

In un account V8 ArangoDB vuoto per la maggior parte dell'utilizzo della memoria virtuale. Ad esempio, sul mio computer a 64 bit, i thread V8 consumano circa 5 GB di memoria virtuale (ma ArangoDB in totale utilizza solo 140 MB di RAM), mentre sul mio computer a 32 bit con meno RAM, i thread V8 utilizzano circa 600 - 700 MB memoria virtuale. Nel tuo caso, con l'utilizzo della VM da 4,5 GB, sospetto che anche la V8 sia la ragione.

L'utilizzo della memoria virtuale per i thread V8 è ovviamente correlato al numero di thread V8 avviati. Ad esempio, aumentando il valore del parametro di avvio --server.threads verranno avviati più thread e verrà utilizzata più memoria virtuale per V8, mentre l'abbassamento del valore inizierà meno thread e utilizzerà meno memoria virtuale.

+1

Bella spiegazione, grazie. – jarandaf

+1

Come può qualcuno vedere l'analisi dell'uso di ram di arango. Sarebbe saggio scaricare manualmente le raccolte dalla memoria per ridurre l'utilizzo di ram + swap? – GeorgeKaf