Ich dachte, dass mit der Integration von Projekt Tunten, Funke automatisch Off-Heap-Speicher verwenden würde.Spark off Heap Speicherkonfiguration und Wolfram
Was für sind spark.memory.offheap.size und spark.memory.offheap.enabled? Muss ich die Menge des Off-Heap-Speichers für Tungsten manuell angeben?
Spark/Tungsten verwenden Encoder/Decoder, um JVM-Objekte als hoch spezialisierte Objekte von Spark SQL-Typen darzustellen, die dann serialisiert und hochperformant betrieben werden können. Die interne Formatdarstellung ist sehr effizient und benutzerfreundlich für die GC-Speichernutzung.
Selbst der Betrieb im standardmäßigen On-Heap-Modus Tungsten erleichtert den großen Overhead des Speicherlayouts der JVM-Objekte und der GC-Betriebszeit. Tungsten in diesem Modus teilt Objekte auf dem Heap für seine internen Zwecke zu und die Zuordnungsspeicherabschnitte können riesig sein, aber es passiert viel weniger häufig und überlebt GC Generation Übergänge reibungslos. Dadurch entfällt die Notwendigkeit, diese interne Struktur außerhalb des Heap zu verschieben.
In unseren Experimenten mit diesem Modus haben wir keine erheblichen Verbesserungen der Laufzeit gesehen. Was Sie jedoch mit dem Off-Heap-Modus erreichen, ist, dass Sie die Speicherzuweisung außerhalb Ihres JVM-Prozesses sorgfältig planen müssen. Dies kann bei Containermanagern wie YARN, Mesos usw. zu Schwierigkeiten führen, wenn Sie neben der JVM-Prozesskonfiguration zusätzliche Speicherabschnitte zulassen und planen müssen.
Auch im Off-Heap-Modus verwendet Tungsten sun.misc.Unsafe, was in Ihren Bereitstellungsszenarien nicht erwünscht oder sogar möglich ist (z. B. mit einer restriktiven Konfiguration des Java-Sicherheitsmanagers).
Ich teile auch eine Zeit markiert Videokonferenz talk von Josh Rosen, als er die ähnliche Frage gestellt wird.