5 ms·

Setting a min and max heap size for a garbage collected language in 2020. Just figure it out for me?

by tbrock 6y ago

staticassertion 6y ago
But Go doesn't "figure it out" for you. It decides for you - there's no "figure it out" step. That's the power of having tunables.
- tbrock 6y ago
  Then they chose better defaults because I never have to think about it.
  - growse 6y ago
    Just because the defaults are better for you doesn't mean they're better for everyone.
nhoughto 6y ago
Sometimes having more control over GC is useful tho, could save a re-write. https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f https://blog.discord.com/why-discord-is-switching-from-go-to...
- tptacek 6y ago
  They rewrote to get away from garbage collection full-stop, so I don't think this is quite the argument for the JVM that you're making it out to be. Not to mention: they resolved their Go GC problem, and rewrote the service in Rust as part of a wave of moving services to Rust because they just liked Rust.
  - nhoughto 6y ago
    yep so not 100% the same, but my point with linking to it is tunables / levers / control is useful. In other scenarios maybe you could get by without having to do a rewrite in Rust, maybe you could keep it in golang and tune the GC a bit. Whilst I like the memory ballast as a clever solution, it does smell like a workaround to a solvable problem if a parameter existed to tune it directly.
    - tptacek 6y ago
      It's totally a workaround and I'm jumping on that last comment when I shouldn't be; it's just a reaction to the hyperbolic "you might have to rewrite" conclusion, because you won't have to rewrite, but indeed you might be annoyed by the lack of tunables.
  - jonathanoliver 6y ago
    I'm an active Go user and I've been working almost exclusively in Go since 2011. I have a feeling that over time, the number of knobs on Go will increase much like it has in Java. I'm trying to think back to my first experiences with Java in 1995. It was so simple compared to the overhead of getting things working in C/C++. So Java's got like 25+ years on Go and I would speculate that the number of knobs on Go in 25 years will be significantly higher. On the one hand, I don't like seeing all the crazy configurable stuff, e.g. CGO_....=1 until I actually need it.
    - koffiezet 6y ago
      Go is already 10yo, so I suppose this will be in 15 years?
      - jonathanoliver 6y ago
        Oops. Ya, 15. Off by 10 error!
vips7L 6y ago
There's nothing to figure out. If you want to use all your ram (like in go) just set -Xmx<all_your_ram>.
- simtel20 6y ago
  If you haven't done -Xmx=<all memory> before, you may not be aware that you're giving a bum steer here.
- thayne 6y ago
  That is a terrible idea. The JVM basically never returns RAM to the OS, and in my experience, if you run a java process long enough, the max heap size ends up being the used heap size.
  - vips7L 6y ago
    G1 the default allocator returns heap to the os only when you set -G1PeriodicGCInterval and both ZGC and Shenandoah do it automatically.
- bobbyi_settv 6y ago
  But to know whether you want that, you need to understand the application. Elasticsearch, for example, recommends using at most 50% of physical memory for heap: https://www.elastic.co/guide/en/elasticsearch/reference/current/heap-size.html https://www.elastic.co/guide/en/elasticsearch/reference/curr... You also often want to stay below 32 gb to get compressed OOPs
- tbrock 6y ago
  Why isn’t that the default? Unless I say otherwise, use it. Imagine launching every app and having to say ok you get 300mb but not more!
  - rahilb 6y ago
    It’s the default because Java has a history, and it was set when everyone was deploying war files to machines with 512mb total memory and the default worked for 95% of people for the past 25 years. In fact, it’s still good enough for the chocolate factory that has brainwashed you into drinking the static binary milkshake. Of course there are ways to use all the available ram when you deploy your kubernetes pods, you just have to consult the documentation. Honestly this criticism is ridiculous I can’t believe I even bothered to reply.
Twirrim 6y ago
There's a black box optimizer for databases, which is designed to take the user away from having to find and tweak all the hundreds of possible tunables in the database, https://github.com/cmu-db/ottertune https://github.com/cmu-db/ottertune / https://ottertune.cs.cmu.edu/ https://ottertune.cs.cmu.edu/ I keep wanting the same for JVM. It's probably nice that there are so many ways to adjust the JVM to best suit a very wide range of workloads, but from a practical perspective I rarely have spare time to go diving through the guts to experiment. Let me point something at a one-box, and it can tweak parameters to its hearts content, so I can export and apply to the rest of the fleet.
- pjmlp 6y ago
  Well, ART auto tunes and probably not everyone will agree it does it perfectly. There are also plenty JVMs to pick and some are better than others working with their defaults.
nine_k 6y ago
Normally you just run your one JVM app on your VM. The real balance is basically between the heap size and page cache size. You might want to tweak it, as much as the GC algorithm and other memory details. This applies if you understand them. If you don't, you just start the JVM with defaults, and it configures itself for optimal performance, using its idea of optimal.

Setting a min and max heap size for a garbage collected language in 2020. Just figure it out for me?

by tbrock 6y ago

Setting a min and max heap size for a garbage collected language in 2020. Just figure it out for me?

But Go doesn't "figure it out" for you. It decides for you - there's no "figure it out" step. That's the power of having tunables.

tbrock 6y ago
Then they chose better defaults because I never have to think about it.
- growse 6y ago
  Just because the defaults are better for you doesn't mean they're better for everyone.

nhoughto 6y ago

Sometimes having more control over GC is useful tho, could save a re-write. https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f https://blog.discord.com/why-discord-is-switching-from-go-to...

tptacek 6y ago
They rewrote to get away from garbage collection full-stop, so I don't think this is quite the argument for the JVM that you're making it out to be. Not to mention: they resolved their Go GC problem, and rewrote the service in Rust as part of a wave of moving services to Rust because they just liked Rust.
- nhoughto 6y ago
  yep so not 100% the same, but my point with linking to it is tunables / levers / control is useful. In other scenarios maybe you could get by without having to do a rewrite in Rust, maybe you could keep it in golang and tune the GC a bit. Whilst I like the memory ballast as a clever solution, it does smell like a workaround to a solvable problem if a parameter existed to tune it directly.
  - tptacek 6y ago
    It's totally a workaround and I'm jumping on that last comment when I shouldn't be; it's just a reaction to the hyperbolic "you might have to rewrite" conclusion, because you won't have to rewrite, but indeed you might be annoyed by the lack of tunables.
- jonathanoliver 6y ago
  I'm an active Go user and I've been working almost exclusively in Go since 2011. I have a feeling that over time, the number of knobs on Go will increase much like it has in Java. I'm trying to think back to my first experiences with Java in 1995. It was so simple compared to the overhead of getting things working in C/C++. So Java's got like 25+ years on Go and I would speculate that the number of knobs on Go in 25 years will be significantly higher. On the one hand, I don't like seeing all the crazy configurable stuff, e.g. CGO_....=1 until I actually need it.
  - koffiezet 6y ago
    Go is already 10yo, so I suppose this will be in 15 years?
    - jonathanoliver 6y ago
      Oops. Ya, 15. Off by 10 error!

vips7L 6y ago

There's nothing to figure out. If you want to use all your ram (like in go) just set -Xmx<all_your_ram>.

simtel20 6y ago
If you haven't done -Xmx=<all memory> before, you may not be aware that you're giving a bum steer here.
thayne 6y ago
That is a terrible idea. The JVM basically never returns RAM to the OS, and in my experience, if you run a java process long enough, the max heap size ends up being the used heap size.
- vips7L 6y ago
  G1 the default allocator returns heap to the os only when you set -G1PeriodicGCInterval and both ZGC and Shenandoah do it automatically.
bobbyi_settv 6y ago
But to know whether you want that, you need to understand the application. Elasticsearch, for example, recommends using at most 50% of physical memory for heap: https://www.elastic.co/guide/en/elasticsearch/reference/current/heap-size.html https://www.elastic.co/guide/en/elasticsearch/reference/curr... You also often want to stay below 32 gb to get compressed OOPs
tbrock 6y ago
Why isn’t that the default? Unless I say otherwise, use it. Imagine launching every app and having to say ok you get 300mb but not more!
- rahilb 6y ago
  It’s the default because Java has a history, and it was set when everyone was deploying war files to machines with 512mb total memory and the default worked for 95% of people for the past 25 years. In fact, it’s still good enough for the chocolate factory that has brainwashed you into drinking the static binary milkshake. Of course there are ways to use all the available ram when you deploy your kubernetes pods, you just have to consult the documentation. Honestly this criticism is ridiculous I can’t believe I even bothered to reply.

Twirrim 6y ago

There's a black box optimizer for databases, which is designed to take the user away from having to find and tweak all the hundreds of possible tunables in the database, https://github.com/cmu-db/ottertune https://github.com/cmu-db/ottertune / https://ottertune.cs.cmu.edu/ https://ottertune.cs.cmu.edu/ I keep wanting the same for JVM. It's probably nice that there are so many ways to adjust the JVM to best suit a very wide range of workloads, but from a practical perspective I rarely have spare time to go diving through the guts to experiment. Let me point something at a one-box, and it can tweak parameters to its hearts content, so I can export and apply to the rest of the fleet.

pjmlp 6y ago
Well, ART auto tunes and probably not everyone will agree it does it perfectly. There are also plenty JVMs to pick and some are better than others working with their defaults.

nine_k 6y ago

Normally you just run your one JVM app on your VM. The real balance is basically between the heap size and page cache size. You might want to tweak it, as much as the GC algorithm and other memory details. This applies if you understand them. If you don't, you just start the JVM with defaults, and it configures itself for optimal performance, using its idea of optimal.