5 ms·

Sub milli sec GC pause is very impressive. Though one thing to me is not clear is that if it is true only for very large heaps or it will be great also for typi

by geodel 6y ago

Sub milli sec GC pause is very impressive. Though one thing to me is not clear is that if it is true only for very large heaps or it will be great also for typical service/micro service heaps in range of 4-32 GB.

perliden 6y ago
ZGC pause times will be the same regardless of heap size. ZGC currently supports heaps from 8MB to 16TB. So if you have 4-32GB heaps and want low latency, then ZGC is definitely something to try.
- eklavya 6y ago
  Hey, is there any benchmark comparing throughput performance of ZGC vs G1 etc. How much hit (performance wise) would one take for getting this awesome pause time limit?
  - kaba0 6y ago
    Here is a quite elaborate one, though it is not totally up-to-date: https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1 https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1
- geodel 6y ago
  Ah, you are the author of article :). Thanks for replying! Does ZGC compromise on throughput compare to G1 to achieve low pause times?
  - perliden 6y ago
    ZGC in its current form trades a bit of throughput performance for better latency. This presentation provides some more details and some performance numbers (a link to the slides is also available there). https://malloc.se/blog/zgc-oracle-developer-live-2020 https://malloc.se/blog/zgc-oracle-developer-live-2020
chrisseaton 6y ago
I think the whole point is the pause time doesn't vary with the heap size.
pradeepchhetri 6y ago
It works great even for large heap sizes. I moved my ES cluster (running with around 92G heap size) from G1GC to ZGC and saw huge improvements in GC. Best part about ZGC is you don't need to touch any GC parameter and it autotunes everything.
- JD557 6y ago
  >running with around 92G heap size I'm curious about this choice. The elasticsearch documentation recommends a maximum heap slightly below 32GB [1]. Is this not a problem anymore with G1GC/ZGC, or are you simply "biting the bullet" and using 92G of heap because you can't afford to scale horizontally? 1: https://www.elastic.co/guide/en/elasticsearch/reference/7.11/advanced-configuration.html#setting-jvm-heap-size https://www.elastic.co/guide/en/elasticsearch/reference/7.11...
  - legerdemain 6y ago
    Heaps "slightly below 32GB" are usually because of the -XX:+UseCompressedOops option, which allows Java to address up to 32GB of memory with a smaller pointer. Between 32-35GB of heap, you're just paying off the savings you would have gotten with compressed object pointers, but if you keep cranking your heap further after that, you'll start getting benefits again.
    - JanecekPetr 6y ago
      This, exactly. One added issue is that ZGC does NOT support compressed oops at all.
  - capableweb 6y ago
    > because you can't afford to scale horizontally? Doesn't have to be because of affordance but rather it's more efficient and cheaper to scale vertically first, both in monetary costs and in time/maintenance costs.
    - vosper 6y ago

by geodel 6y ago

perliden 6y ago

ZGC pause times will be the same regardless of heap size. ZGC currently supports heaps from 8MB to 16TB. So if you have 4-32GB heaps and want low latency, then ZGC is definitely something to try.

eklavya 6y ago
Hey, is there any benchmark comparing throughput performance of ZGC vs G1 etc. How much hit (performance wise) would one take for getting this awesome pause time limit?
- kaba0 6y ago
  Here is a quite elaborate one, though it is not totally up-to-date: https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1 https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1
geodel 6y ago
Ah, you are the author of article :). Thanks for replying! Does ZGC compromise on throughput compare to G1 to achieve low pause times?
- perliden 6y ago
  ZGC in its current form trades a bit of throughput performance for better latency. This presentation provides some more details and some performance numbers (a link to the slides is also available there). https://malloc.se/blog/zgc-oracle-developer-live-2020 https://malloc.se/blog/zgc-oracle-developer-live-2020

chrisseaton 6y ago

I think the whole point is the pause time doesn't vary with the heap size.

pradeepchhetri 6y ago

It works great even for large heap sizes. I moved my ES cluster (running with around 92G heap size) from G1GC to ZGC and saw huge improvements in GC. Best part about ZGC is you don't need to touch any GC parameter and it autotunes everything.

JD557 6y ago
>running with around 92G heap size I'm curious about this choice. The elasticsearch documentation recommends a maximum heap slightly below 32GB [1]. Is this not a problem anymore with G1GC/ZGC, or are you simply "biting the bullet" and using 92G of heap because you can't afford to scale horizontally? 1: https://www.elastic.co/guide/en/elasticsearch/reference/7.11/advanced-configuration.html#setting-jvm-heap-size https://www.elastic.co/guide/en/elasticsearch/reference/7.11...
- legerdemain 6y ago
  Heaps "slightly below 32GB" are usually because of the -XX:+UseCompressedOops option, which allows Java to address up to 32GB of memory with a smaller pointer. Between 32-35GB of heap, you're just paying off the savings you would have gotten with compressed object pointers, but if you keep cranking your heap further after that, you'll start getting benefits again.
  - JanecekPetr 6y ago
    This, exactly. One added issue is that ZGC does NOT support compressed oops at all.
- capableweb 6y ago
  > because you can't afford to scale horizontally? Doesn't have to be because of affordance but rather it's more efficient and cheaper to scale vertically first, both in monetary costs and in time/maintenance costs.
  - vosper 6y ago