Speicherverbrauch von ArangoDB

Question

Ich versuche zu verstehen, was die Grenzen von Arangodb sind und was das ideale Setup ist. Von dem, was ich verstanden habe, speichert arango alle Sammlungsdaten im virtuellen Speicher und im Idealfall soll dies in den RAM passen. Wenn die Sammlung wächst und nicht in den Arbeitsspeicher passen kann, wird sie auf die Festplatte ausgelagert.

Also meine erste Frage. Wenn meine Datenbank wächst, muss ich die Swap-Partition/Datei anpassen, um die db anzupassen?

Da arango auch die Daten auf Festplatte synchronisiert, bedeutet dies, dass die Daten immer im RAM und auf der Festplatte gespeichert werden? Also, wenn ich eine db habe, die 1,5 GB ist und mein RAM 1 GB ist, muss ich mindestens 0,5 GB Swap-Disk und 1,5 GB normalen Speicherplatz haben?

Ich bin ein wenig verwirrt, wie Arango den virtuellen Speicher verwendet. Im Moment habe ich 7 Sammlungen, die praktisch leer sind. Ich habe 1 GB RAM und 1 GB Swap-Disk. Der Administrator meldet, dass Arango 4,5 GB virtuellen Speicher verwendet. Wie ist das möglich, wenn die Auslagerungsdisk 1 GB ist? Es verwendet derzeit 80 MB RAM. Sollte dies nicht 224 MB sein, wenn die Journalgröße 32 MB für jede Sammlung beträgt?

Was ist die Empfehlung für die Journalgröße vs Sammlungsgröße? Kann dies dynamisch angepasst werden, wenn die Sammlung wächst?

Welche Leistung wird erwartet, wenn die Auslagerungsdiskette häufig verwendet wird, wenn die Festplatte eine SSD ist? Wenn die Swap-Disk viel verwendet wird, wäre die Performance vergleichbar mit der Verwendung einer traditionelleren db wie mysql?

Answer 1

ArangoDB speichert alle Daten in Speicherabbilddateien. Jede Sammlung kann 0 bis n Datendateien haben, mit einer Standarddateigröße von jeweils 32 MB (beachten Sie, dass diese Dateigröße global oder auf einer Sammlungsebene angepasst werden kann). Eine leere Sammlung (die nie Daten hatte) wird keine Datendatei haben. Beim ersten Schreiben in eine Sammlung wird die Datendatei erstellt. Wenn eine Datendatei voll ist, wird automatisch eine neue Datei erstellt.

Sammlungen weisen Datendateien standardmäßig in Blöcken von 32 MB zu. Wenn Sie viele, aber kleine Sammlungen haben, kann dies zu einer gewissen Speicherverschwendung führen. Wenn Sie viele wenige, aber große Sammlungen, die mögliche Verschwendung (freier Speicherplatz am Ende einer Datendatei) ist wahrscheinlich nicht so wichtig.

Wenn ein ArangoDB-Vorgang Daten aus einer Speicherabbilddatei liest oder Daten in eine Speicherabbilddatei schreibt, übersetzt das Betriebssystem zuerst den Offset in die Datei in eine Seitennummer. Dies liegt daran, dass jede Datendatei implizit in Seiten einer bestimmten Größe aufgeteilt ist. Wie groß eine Seite ist, hängt von der Plattform ab, aber nehmen wir an, dass die Seiten 4 KB groß sind. Eine Datei mit einer Standard-Dateigröße wird also 8192 Seiten haben.

Nachdem das Betriebssystem den Offset in die Datei in eine Seitennummer übersetzt hat, wird sichergestellt, dass die Daten der angeforderten Seite im physischen RAM vorhanden sind. Wenn sich die Seite noch nicht im physischen RAM befindet, gibt das Betriebssystem einen Seitenfehler aus, um das Laden der angeforderten Seite von der Festplatte auszulösen oder in den physischen Arbeitsspeicher zu wechseln. Dadurch wird schließlich die gesamte Seite im RAM verfügbar gemacht, und alle Lese- oder Schreibvorgänge auf den Daten der Seite können danach auftreten.

All dies wird vom virtuellen Speichermanager des Betriebssystems erledigt. Das Betriebssystem ist frei, so viele Seiten aus einer Datei in den RAM zu mappen, wie es für gut hält. Wenn beispielsweise auf eine Speicherabbilddatei sequenziell zugegriffen wird, ist das Betriebssystem wahrscheinlich clever und liest viele Seiten vor, so dass sie sich beim tatsächlichen Zugriff bereits im physischen RAM befinden.

Das Betriebssystem ist auch frei, einige oder alle Seiten einer Datendatei auszutauschen. Es wird wahrscheinlich Seiten austauschen, wenn nicht genügend physischer RAM verfügbar ist, um alle Seiten gleichzeitig aus allen Datendateien im RAM zu behalten.Es kann auch Seiten austauschen, die eine Weile nicht benutzt wurden, um RAM für andere Operationen verfügbar zu machen. Es wird wahrscheinlich einen LRU-Algorithmus dafür verwenden.

Wie sich der virtuelle Speichermanager eines Betriebssystems genau verhält, ist bei Plattformen und Implementierungen sehr unterschiedlich. Die meisten Systeme erlauben auch die Konfiguration des VM-Subsystems. Zum Beispiel here are some parameters for Linux's VM subsystem.

Es ist daher schwer zu sagen, wie viel physischer Speicher ArangoDB tatsächlich für eine bestimmte Anzahl von Sammlungen und deren Datendateien verwenden wird. Wenn auf die Sammlungen überhaupt nicht zugegriffen wird, benötigt die Speicherabbildung der Datendateien möglicherweise fast keinen RAM, da das Betriebssystem die Sammlungen wahrscheinlich vollständig oder zumindest teilweise ausgetauscht hat. Wenn die Sammlungen häufig verwendet werden, werden die Datendateien des Betriebssystems wahrscheinlich vollständig in den Arbeitsspeicher migriert. Aber in beiden Fällen zählt der Speicher als memory-mapped. Dies bedeutet, dass Sie eine viel höhere virtuelle Speicherbelegung als Ihr physisches RAM haben können.

Wie bereits erwähnt, muss das Betriebssystem beim Zugriff auf Seiten, die sich nicht im RAM befinden, viel arbeiten, und Sie möchten dies nach Möglichkeit vermeiden. Wenn die Gesamtgröße Ihrer häufig verwendeten Sammlungen die Größe des physischen Arbeitsspeichers überschreitet, hat das Betriebssystem keine andere Wahl, als die Seiten beim Zugriff auf diese Sammlungen zu wechseln. Die Verwendung einer SSD für den Austausch ist wahrscheinlich besser als die Verwendung einer rotierenden Festplatte, ist aber immer noch viel langsamer als der RAM-Zugriff. Lange Rede, kurzer Sinn: Die Daten Ihrer aktiven Sammlungen (Datendateien plus Indizes) sollten möglichst in den physischen Arbeitsspeicher passen oder Sie werden viel Festplattenaktivität sehen.

Abgesehen davon reserviert ArangoDB nicht nur virtuellen Speicher für die Sammlungsdatendateien, sondern startet auch ein paar V8-Threads (V8 ist die JavaScript-Engine in ArangoDB), die auch virtuellen Speicher verwenden. Dieser virtuelle Speicher ist nicht dateiunterstützt.

In einem leeren ArangoDB berücksichtigt V8 den größten Teil der virtuellen Speicherauslastung. Auf meinem 64-Bit-Computer beispielsweise verbrauchen die V8-Threads etwa 5 GB virtuellen Arbeitsspeicher (ArangoDB verwendet insgesamt jedoch nur 140 MB RAM), während die V8-Threads auf meinem 32-Bit-Computer mit weniger Arbeitsspeicher etwa 600 - 700 MB benötigen virtueller Speicher. In Ihrem Fall, mit der Verwendung von 4,5 GB VM, vermute ich, dass V8 der Grund ist.

Die virtuelle Speicherauslastung für die V8-Threads korreliert offensichtlich mit der Anzahl der gestarteten V8-Threads. Wenn Sie beispielsweise den Wert des Startparameters --server.threads erhöhen, werden mehr Threads gestartet und mehr virtueller Speicher für V8 verwendet. Durch das Verringern des Werts werden weniger Threads gestartet und weniger virtueller Speicher verwendet.