Comments 6
Микросервис в проде падал раз в неделю потому что 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
Кстати пробовал тюнить G1 — но он не начинал чаще вычищать old, даже пришлость отключать его эвристики чтобы зафорсить его это делать. В итоге не хватило терпения довести работу до конца, пошел пробовать альтернативы. Heap — 1024m. JDK 11.0.4+
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.
It was also tested on same Hazelcast Benchmark before/after:
cr.openjdk.java.net/~shade/8247358/before-after.pdf
cr.openjdk.java.net/~shade/8247358/before-after.pdf
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.
TL;DR: it's a 3x improvement, but still outside the required 10 ms envelope.
Классная статья, спасибо!
Sign up to leave a comment.
Производительность современной Java при работе с большим объёмом данных, часть 1