Uber Engineering Tricks of the Trade: Tuning JVM Memory for Large-Scale Services

Re:Uber Engineering Tricks of the Trade: Tuning JVM Memory f... by SilurianWenlock on Tuesday May 18, 2021 @04:03PM (#27200281)

I thought the concurrent GC algorithms (zing/azul, g1?) avoided these stop the world events by using concurrency?

[ Parent | on HN ]

Re:Uber Engineering Tricks of the Trade: Tuning JVM Memory f... by rchiang on Wednesday May 19, 2021 @12:03AM (#27204413)

This presentation from 2019 gives an idea about some of the GC avg/max runtimes using the NameNode: https://www.slideshare.net/xkrogen/hadoop-meetup-jan-2019-dy...

[ Parent | on HN ]

Re:Uber Engineering Tricks of the Trade: Tuning JVM Memory f... by dharmab on Tuesday May 18, 2021 @04:19PM (#27200473)

As discussed in the link, these algorithms reduce but do not entirely eliminate STW.

[ Parent | on HN ]

Re:Uber Engineering Tricks of the Trade: Tuning JVM Memory f... by _old_dude_ on Tuesday May 18, 2021 @05:25PM (#27201385)

Recent GC algorithms slow down the application, either by not scheduling coroutines that allocate too much memory or by forcing them to do the marking or the evacuation (helping the GC) when running (or both).

With that, STW pause time does not depend on the heap size or on the root set size (the stack size). In practice, it means pause < 1ms, at that point the OS becomes the bottleneck, not the GC.

So latency is good but throughput can be reduced by 30%.

[ Parent | on HN ]