Hi,
ich habe testweise mal vom AdoptOpenJDK einen Integrationstest von meinem Open Source Projekt, einem temporalen DBMS für semi-strukturierte Daten (JSON und XML in einem binären Format gespeichert)[1] laufen lassen. Komisch, finde ich, dass die Pause Times von G1 teilweise deutlich überschritten werden:
[255,650s][info][gc] GC(42) Pause Final Update Refs 0,284ms
[255,650s][info][gc] GC(42) Concurrent cleanup 3447M->2365M(8002M) 0,432ms
[260,901s][info][gc] Trigger: Average GC time (2540,12 ms) is above the time for allocation rate (597 MB/s) to deplete free headroom (1515M)
[260,903s][info][gc] GC(43) Concurrent reset 5684M->5684M(8002M) 1,627ms
[260,904s][info][gc] GC(43) Pause Init Mark (unload classes) 0,314ms
[262,151s][info][gc] GC(43) Concurrent marking (unload classes) 5686M->6300M(8002M) 1247,740ms
[262,153s][info][gc] GC(43) Pause Final Mark (unload classes) 1,449ms
[262,156s][info][gc] GC(43) Concurrent roots processing 6300M->6302M(8002M) 2,272ms
[262,156s][info][gc] GC(43) Concurrent cleanup 6302M->6302M(8002M) 0,368ms
[262,390s][info][gc] GC(43) Concurrent evacuation 6302M->6722M(8002M) 233,978ms
[262,390s][info][gc] GC(43) Pause Init Update Refs 0,057ms
[263,547s][info][gc] GC(43) Concurrent update references 6722M->7092M(8002M) 1156,964ms
[263,548s][info][gc] GC(43) Pause Final Update Refs 0,346ms
[263,548s][info][gc] GC(43) Concurrent cleanup 7092M->6016M(8002M) 0,446ms
[263,798s][info][gc] Trigger: Average GC time (2665,50 ms) is above the time for allocation rate (406 MB/s) to deplete free headroom (1079M)
[263,802s][info][gc] GC(44) Concurrent reset 6120M->6120M(8002M) 3,885ms
[263,803s][info][gc] GC(44) Pause Init Mark (unload classes) 0,305ms
Anbei auch ein Screenshot, wenn ich mich mit dem Profiler auf den Prozess connecte. Mit G1 ist die Pause Time oft beim Default von 200ms, was allerdings bei großem Heap und nem Datenbanksystem viel zu viel ist, wie ich finde.
Ich habe jetzt aber auch noch nicht so sonderlich viel über Shenandoah gelesen, nur dass er ein low pause Time GC sei und eben für größere Heaps. Leider hab ich noch kein Memory Mapped File, würde aber sehr gerne die Foreign Memory API verwenden, um den Storage ansich schneller zu machen. Insbesonder auch in Hinsicht auf Byte-Addressable NVM (wie Intel Opthane NVM) für extrem schnelles paralleles lesen.
Eventuell kann mir aber jemand das Verhalten erklären.
Contributions zwecks SirixDB sind natürlich mehr als willkommen. Für vieles braucht man auch kein Datenbankwissen ;-)
Beste Grüße
Johannes
[1] https://github.com/sirixdb/sirix
ich habe testweise mal vom AdoptOpenJDK einen Integrationstest von meinem Open Source Projekt, einem temporalen DBMS für semi-strukturierte Daten (JSON und XML in einem binären Format gespeichert)[1] laufen lassen. Komisch, finde ich, dass die Pause Times von G1 teilweise deutlich überschritten werden:
[255,650s][info][gc] GC(42) Pause Final Update Refs 0,284ms
[255,650s][info][gc] GC(42) Concurrent cleanup 3447M->2365M(8002M) 0,432ms
[260,901s][info][gc] Trigger: Average GC time (2540,12 ms) is above the time for allocation rate (597 MB/s) to deplete free headroom (1515M)
[260,903s][info][gc] GC(43) Concurrent reset 5684M->5684M(8002M) 1,627ms
[260,904s][info][gc] GC(43) Pause Init Mark (unload classes) 0,314ms
[262,151s][info][gc] GC(43) Concurrent marking (unload classes) 5686M->6300M(8002M) 1247,740ms
[262,153s][info][gc] GC(43) Pause Final Mark (unload classes) 1,449ms
[262,156s][info][gc] GC(43) Concurrent roots processing 6300M->6302M(8002M) 2,272ms
[262,156s][info][gc] GC(43) Concurrent cleanup 6302M->6302M(8002M) 0,368ms
[262,390s][info][gc] GC(43) Concurrent evacuation 6302M->6722M(8002M) 233,978ms
[262,390s][info][gc] GC(43) Pause Init Update Refs 0,057ms
[263,547s][info][gc] GC(43) Concurrent update references 6722M->7092M(8002M) 1156,964ms
[263,548s][info][gc] GC(43) Pause Final Update Refs 0,346ms
[263,548s][info][gc] GC(43) Concurrent cleanup 7092M->6016M(8002M) 0,446ms
[263,798s][info][gc] Trigger: Average GC time (2665,50 ms) is above the time for allocation rate (406 MB/s) to deplete free headroom (1079M)
[263,802s][info][gc] GC(44) Concurrent reset 6120M->6120M(8002M) 3,885ms
[263,803s][info][gc] GC(44) Pause Init Mark (unload classes) 0,305ms
Anbei auch ein Screenshot, wenn ich mich mit dem Profiler auf den Prozess connecte. Mit G1 ist die Pause Time oft beim Default von 200ms, was allerdings bei großem Heap und nem Datenbanksystem viel zu viel ist, wie ich finde.
Ich habe jetzt aber auch noch nicht so sonderlich viel über Shenandoah gelesen, nur dass er ein low pause Time GC sei und eben für größere Heaps. Leider hab ich noch kein Memory Mapped File, würde aber sehr gerne die Foreign Memory API verwenden, um den Storage ansich schneller zu machen. Insbesonder auch in Hinsicht auf Byte-Addressable NVM (wie Intel Opthane NVM) für extrem schnelles paralleles lesen.
Eventuell kann mir aber jemand das Verhalten erklären.
Contributions zwecks SirixDB sind natürlich mehr als willkommen. Für vieles braucht man auch kein Datenbankwissen ;-)
Beste Grüße
Johannes
[1] https://github.com/sirixdb/sirix
Anhänge
Zuletzt bearbeitet:
