Everything I Ever Learned About JVM Performance Tuning at Twitter (Attila Szegedi, Hungary)

During my time at Twitter, I engaged in lots of JVM performance tuning at scale. The talk summarizes lessons that were learned in the process of doing this in the area of memory, CPU, lock contention, and threading tuning.

[@kvba4444]

Nice talk, a lot of interesting details about gc, thanks!

[@sergiisl9012]

Great english as for the non native and quite insightful info and use case described. Thanks)

[@ivanocj]

Moment of truth at 8:42

[@bigdlamz]

lolz

[@PuerinTheHunter]

That was right when he was saying "give it more memory!"

[@aseemsavio6696]

I felt it

[@somakkamos]

Hahahahahahahaha

[@j2klegend]

Term 'Overprovision' confusing me on 39:10, is that what I thought with following JVM settings, -Xms1024M -Xmx1920M -XX:NewRatio=2 -XX:MaxHeapFreeRatio=90 -XX:+UseParallelOldGC As per the settings, I assume that when 90% Old gen Heap get filled, a Full GC will be performed, remaining 10% will be available for the App to allocate while Full GC performs. Somebody please enlighten me...

[@berndeckenfels]

This talk did not mention allocation rates, but it features object fat shaming, if this is your thing.

[@juliandurchholz]

Slide at 12:40 is inaccurate. JVM object header is normally THREE machine words. One for class word, two for mark word. Zero length arrays are 16B, given that Object headers are 12B with 4B of padding, which the array length is then stored in.

[@StefanReich]

Depends on what you call machine words... Object header is 12 bytes with 64 bit/CompressedOOPS and should be 16 bytes with 64 bit without CompresedOOPS. I just did some testing though and even with -XX:-UseCompressedOops I am seeing 12 byte headers. Huh.

[@lartsevevgenii6640]

EPAM)

[@rydmerlin]

Anytime you talk about tuning garbage collection please indicate latency before and after.

[@peterbooth6753]

I spent four years consulting for an electronic trading shop that made a strategic decision to move from the Oracle JVM to the Azul JVM. The scope of this was about 20 applications, over dozen teams, deployed to over 1000 servers. 1. The most dramatic impact was with garbage collection. Applications that would have daily GC pauses that ranged from 100s of ms to seconds now have maximum GC pauses of between 30 micros to 300 micros - well under 1ms. That's because the GC used in Azul's Zing JVM has a continuously compacting collector algorithm that doesn't have any stop-the-world pauses. 2. Second impact, that we hadn't thought about until we saw it was that with such a collector we were better able to make full use of modern hardware. A current server, say an HP DL380 gen9 with dual Intel E5-2667v4 Broadwell CPUs and 512GB of RAM is blisteringly fast. Before this JVM we might have deployed eight identical applications on that host, each with 40GB heaps, to avoid the long GC pauses that would be inevitable with a larger heap. Instead, we can run a single JVM with a 400GB heap and still have GC pauses below a millisecond - but transaction latencies will be much lower because the apps arent contending with each other, there are fewer context switches, it's feasible to pin threads to specific cores and see latenciesof 600us drop to 120us, or less. 3. Third impact was no more wasted tuning GC parameters, and fewer app instances of manage makes for a simpler life. Most Java application pauses are not caused b garbage collection but fixing garbage collection gives you the time to focus on the other causes of OS and application stalls. After using Azul at two workplaces I am convinced that it is the single most underutilized, under-publicized product in high performance Java sites.

[@user-zq8bt6hv9k]

37:13

[@dogwoof5391]

java 10 with value types? awkward :)