Ehcache spricht über On-Heap- und Off-Heap-Speicher. Was ist der Unterschied? Welche JVM-Argumente werden verwendet, um sie zu konfigurieren?
Antworten:
Der On-Heap-Speicher bezieht sich auf Objekte, die im Java-Heap vorhanden sind (und auch der GC unterliegen). Andererseits bezieht sich der Off-Heap-Speicher auf (serialisierte) Objekte, die von EHCache verwaltet werden, aber außerhalb des Heaps gespeichert sind (und auch nicht der GC unterliegen). Da der Off-Heap-Speicher weiterhin im Speicher verwaltet wird, ist er etwas langsamer als der On-Heap-Speicher, aber immer noch schneller als der Festplattenspeicher.
Die internen Details, die mit der Verwaltung und Verwendung des Off-Heap-Speichers verbunden sind, sind in dem in der Frage angegebenen Link nicht sehr offensichtlich. Es ist daher ratsam , die Details von Terracotta BigMemory zu überprüfen, das zum Verwalten des Off-Disk verwendet wird Geschäft. BigMemory (der Off-Heap-Speicher) soll verwendet werden, um den Overhead von GC auf einem Heap zu vermeiden, der mehrere Megabyte oder Gigabyte groß ist. BigMemory verwendet den Speicheradressraum des JVM-Prozesses über direkte ByteBuffer , die im Gegensatz zu anderen nativen Java-Objekten nicht der GC unterliegen.
von http://code.google.com/p/fast-serialization/wiki/QuickStartHeapOff
Was ist Heap-Offloading?
Normalerweise werden alle nicht temporären Objekte, die Sie zuweisen, vom Java-Garbage Collector verwaltet. Obwohl die VM bei der Speicherbereinigung gute Arbeit leistet, muss die VM zu einem bestimmten Zeitpunkt einen sogenannten "Full GC" durchführen. Ein vollständiger GC umfasst das Scannen des vollständig zugewiesenen Heaps. Dies bedeutet, dass GC-Pausen / Verlangsamungen proportional zur Größe eines Anwendungsheaps sind. Vertraue also keiner Person, die dir sagt: "Gedächtnis ist billig". Im Java-Speicher beeinträchtigt der Verbrauch die Leistung. Außerdem können bei Heap-Größen> 1 GB bemerkenswerte Pausen auftreten. Dies kann unangenehm sein, wenn in Echtzeit Cluster ausgeführt werden. In einem Cluster oder Grid reagiert ein Java-Prozess möglicherweise nicht mehr und wird aus dem Cluster entfernt.
Heutige Serveranwendungen (die häufig auf aufgeblähten Frameworks basieren ;-)) erfordern jedoch leicht Heaps, die weit über 4 GB hinausgehen.
Eine Lösung für diese Speicheranforderungen besteht darin, Teile der Objekte auf den Nicht-Java-Heap (direkt vom Betriebssystem zugewiesen) zu verlagern. Glücklicherweise bietet java.nio Klassen zum direkten Zuweisen / Lesen und Schreiben von nicht verwalteten Speicherblöcken (sogar Dateien mit Speicherzuordnung).
Man kann also große Mengen an 'nicht verwaltetem' Speicher zuweisen und damit Objekte dort speichern. Um beliebige Objekte im nicht verwalteten Speicher zu speichern, ist die Verwendung der Serialisierung die sinnvollste Lösung. Dies bedeutet, dass die Anwendung Objekte in den Offheap-Speicher serialisiert. Später kann das Objekt mithilfe der Deserialisierung gelesen werden.
Die von der Java-VM verwaltete Heap-Größe kann klein gehalten werden, sodass die GC-Pausen im Millis liegen. Alle sind glücklich und haben ihre Arbeit erledigt.
Es ist klar, dass die Leistung eines solchen Off-Heap-Puffers hauptsächlich von der Leistung der Serialisierungsimplementierung abhängt. Gute Nachricht: Aus irgendeinem Grund ist die FST-Serialisierung ziemlich schnell :-).
Beispiel für Verwendungsszenarien:
Bearbeiten: In einigen Szenarien kann man komplexere Garbage Collection-Algorithmen wie ConcurrentMarkAndSweep oder G1 wählen, um größere Heaps zu unterstützen (dies hat jedoch auch seine Grenzen über 16 GB-Heaps hinaus). Es gibt auch eine kommerzielle JVM mit verbesserter "pausenloser" GC (Azul).
Der Heap ist der Ort im Speicher, an dem Ihre dynamisch zugewiesenen Objekte leben. Wenn Sie verwendet haben, newdann ist es auf dem Haufen. Dies steht im Gegensatz zum Stapelspeicher, in dem sich der Funktionsstapel befindet. Wenn Sie eine lokale Variable haben, befindet sich diese Referenz auf dem Stapel. Der Heap von Java unterliegt der Speicherbereinigung und die Objekte können direkt verwendet werden.
Der Off-Heap-Speicher von EHCache entfernt Ihr reguläres Objekt vom Heap, serialisiert es und speichert es als Bytes in einem von EHCache verwalteten Speicherblock. Es ist wie das Speichern auf der Festplatte, aber es befindet sich immer noch im RAM. Die Objekte sind in diesem Zustand nicht direkt verwendbar, sie müssen zuerst deserialisiert werden. Auch nicht der Müllabfuhr unterworfen.
Nicht 100%; Es hört sich jedoch so an, als wäre der Heap ein Objekt oder eine Menge zugewiesenen Speicherplatzes (im RAM), der in die Funktionalität des Codes integriert ist, entweder Java selbst oder wahrscheinlicher die Funktionalität von ehcache selbst, und der Off-Heap-Ram ist ein eigenes System als Gut; Es hört sich jedoch so an, als ob dies eine Größenordnung langsamer ist, da es nicht so organisiert ist, was bedeutet, dass möglicherweise kein Heap verwendet wird (was bedeutet, dass ein langer Satz RAM-Speicherplatz vorhanden ist) und stattdessen unterschiedliche Adressräume verwendet werden, was die Effizienz wahrscheinlich etwas verringert.
Die nächst niedrigere Stufe ist natürlich der Festplattenspeicher selbst.
Ich benutze keinen ehcache, deshalb möchten Sie mir vielleicht nicht vertrauen, aber das habe ich aus ihrer Dokumentation entnommen.
