Производительность современной Java при работе с большим объёмом данных, часть 1

[UbuRus]

Микросервис в проде падал раз в неделю потому что G1 загонял себя в GC размером во всю кучу и GCP просто клал COS и поднимал взамен новый, попробовал заменить на Shenandoah — все работает отлично, тот же сервис не рестартует раз в неделю, все 8+ инстансов уже живут больше двух месяцов без неожиданных рестартов.

MacBook Pro 2018 с 6-ядерным Intel Core i7 и 16 Гб DDR4 RAM

Ну вот и деплойте macbook с macos в прод, вы именно это и померяли, потому что есть отличия в работе и поддержке GC от OS: https://wiki.openjdk.java.net/display/shenandoah/Main#Main-OSSupport

[UbuRus]

Кстати пробовал тюнить G1 — но он не начинал чаще вычищать old, даже пришлость отключать его эвристики чтобы зафорсить его это делать. В итоге не хватило терпения довести работу до конца, пошел пробовать альтернативы. Heap — 1024m. JDK 11.0.4+

[marko_hazelcast]

We confirmed all our published findings on Amazon EC2, and the Shenandoah team reproduced the reported latency. They already created an issue about it and fixed it: bugs.openjdk.java.net/browse/JDK-8247358.

[mdcool]

It was also tested on same Hazelcast Benchmark before/after:
cr.openjdk.java.net/~shade/8247358/before-after.pdf

[marko_hazelcast]

We tested Shenandoah after the fix: jet-start.sh/blog/2020/06/23/jdk-gc-benchmarks-rematch

TL;DR: it's a 3x improvement, but still outside the required 10 ms envelope.

[IvanGroza]

Классная статья, спасибо!