6 ms·

> As an example, the Go runtime does not honor container resource limits That’s no longer true for Go 1.19+

by demi56 2y ago

lenkite 2y ago
AFAIK, the basic issue is still open at https://github.com/golang/go/issues/33803 https://github.com/golang/go/issues/33803 and https://github.com/golang/go/issues/59715 https://github.com/golang/go/issues/59715. You still need to use a helper library like https://github.com/KimMachineGun/automemlimit https://github.com/KimMachineGun/automemlimit or https://github.com/uber-go/automaxprocs https://github.com/uber-go/automaxprocs. Go 1.19 only had this in its notes for memory changes "...includes support for a soft memory limit. This memory limit includes the Go heap and all other memory managed by the runtime, and excludes external memory sources such as mappings of the binary itself, memory managed in other languages, and memory held by the operating system on behalf of the Go program" Forgot to add: The JVM does this for you since JDK 17 https://developers.redhat.com/articles/2022/04/19/java-17-whats-new-openjdks-container-awareness https://developers.redhat.com/articles/2022/04/19/java-17-wh...
- btreecat 2y ago
  Most Jvm shops/devs I know are still on 11
  - lenkite 2y ago
    That's the problem isn't it ? The Java of 8+ years ago is always compared to the Rust/Go/Python of today. (I am also guilty of this)
  - gf000 2y ago
    Upgrading from 11 is trivial though and we are at almost 24. The hardest was 8->9, or 9->11.
  - pjmlp 2y ago
    And many folks still code in C89, C99, C++98, Python 2, .NET Framework.... Language is not to blame for unwillingness to move forward.
- demi56 2y ago
  > ...includes support for a soft memory limit. This memory limit includes the Go heap and all other memory managed by the runtime, and excludes external memory sources such as mappings of the binary itself, memory managed in other languages, and memory held by the operating system on behalf of the Go program" Of course it’s a runtime setting, it won’t affect other factors but you can’t say it didn’t solved anything “because there’s a GitHub issue open” Then Go runtime was unpredictable because of its ideology “CPU is unlimited but not Memory” and containers are kinda of a dynamic resource allocated but it did solve vast amount of problem dealing with kernel OOM and unpredictable GC cycles > You still need to use a helper library like https://github.com/KimMachineGun/automemlimit https://github.com/KimMachineGun/automemlimit or https://github.com/uber-go/automaxprocs https://github.com/uber-go/automaxprocs. I would be surprised if the Go team implemented it into the runtime, because some devs would love to have there own way of handling such settings so I don’t see it as an issue > Forgot to add: The JVM does this for you since JDK 17 https://developers.redhat.com/articles/2022/04/19/java-17-wh https://developers.redhat.com/articles/2022/04/19/java-17-wh... We can’t just compare added features if don’t compare how backwards compatible the language is at that time I don’t know much about Java, but I wouldn’t say the same from upgrading from Go 1.9 to Go 1.19
  - lenkite 2y ago
    Sorry, but no - putting the burden on the developer to detect whether they are running in a container or not and then determine and adjust to cgroup settings is far too high an encumbrance on the service developer. This is a demonstrative example of a fundamental responsibility that should always be delegated to the runtime as the default behavior. Neither Go 1.19 nor any subsequent version has "solved" this issue.
    - demi56 2y ago
      > Sorry, but no - putting the burden on the developer to detect whether they are running in a container or not and then determine and adjust to cgroup settings is far too high an encumbrance on the service developer. Because there’s no one way solution to this problem, the problem isn’t unique to only Go, but every GC language because you’re starving the program if there isn’t sufficient CPU Quota it will all eventually lead to CPU throttling, this isn’t really the problem of Go or any other GC language but at the OS layer, the inherent nature of containers Secondly am pretty sure the Linux CFS does not strictly follow the CPU Quota, tho there could be something like a panic or warning, or switching to entirely different memory management just for what ? people who want 10ms ?

> As an example, the Go runtime does not honor container resource limits That’s no longer true for Go 1.19+

by demi56 2y ago

> As an example, the Go runtime does not honor container resource limits That’s no longer true for Go 1.19+

AFAIK, the basic issue is still open at https://github.com/golang/go/issues/33803 https://github.com/golang/go/issues/33803 and https://github.com/golang/go/issues/59715 https://github.com/golang/go/issues/59715. You still need to use a helper library like https://github.com/KimMachineGun/automemlimit https://github.com/KimMachineGun/automemlimit or https://github.com/uber-go/automaxprocs https://github.com/uber-go/automaxprocs. Go 1.19 only had this in its notes for memory changes "...includes support for a soft memory limit. This memory limit includes the Go heap and all other memory managed by the runtime, and excludes external memory sources such as mappings of the binary itself, memory managed in other languages, and memory held by the operating system on behalf of the Go program" Forgot to add: The JVM does this for you since JDK 17 https://developers.redhat.com/articles/2022/04/19/java-17-whats-new-openjdks-container-awareness https://developers.redhat.com/articles/2022/04/19/java-17-wh...

btreecat 2y ago
Most Jvm shops/devs I know are still on 11
- lenkite 2y ago
  That's the problem isn't it ? The Java of 8+ years ago is always compared to the Rust/Go/Python of today. (I am also guilty of this)
- gf000 2y ago
  Upgrading from 11 is trivial though and we are at almost 24. The hardest was 8->9, or 9->11.
- pjmlp 2y ago
  And many folks still code in C89, C99, C++98, Python 2, .NET Framework.... Language is not to blame for unwillingness to move forward.
demi56 2y ago
> ...includes support for a soft memory limit. This memory limit includes the Go heap and all other memory managed by the runtime, and excludes external memory sources such as mappings of the binary itself, memory managed in other languages, and memory held by the operating system on behalf of the Go program" Of course it’s a runtime setting, it won’t affect other factors but you can’t say it didn’t solved anything “because there’s a GitHub issue open” Then Go runtime was unpredictable because of its ideology “CPU is unlimited but not Memory” and containers are kinda of a dynamic resource allocated but it did solve vast amount of problem dealing with kernel OOM and unpredictable GC cycles > You still need to use a helper library like https://github.com/KimMachineGun/automemlimit https://github.com/KimMachineGun/automemlimit or https://github.com/uber-go/automaxprocs https://github.com/uber-go/automaxprocs. I would be surprised if the Go team implemented it into the runtime, because some devs would love to have there own way of handling such settings so I don’t see it as an issue > Forgot to add: The JVM does this for you since JDK 17 https://developers.redhat.com/articles/2022/04/19/java-17-wh https://developers.redhat.com/articles/2022/04/19/java-17-wh... We can’t just compare added features if don’t compare how backwards compatible the language is at that time I don’t know much about Java, but I wouldn’t say the same from upgrading from Go 1.9 to Go 1.19
- lenkite 2y ago
  Sorry, but no - putting the burden on the developer to detect whether they are running in a container or not and then determine and adjust to cgroup settings is far too high an encumbrance on the service developer. This is a demonstrative example of a fundamental responsibility that should always be delegated to the runtime as the default behavior. Neither Go 1.19 nor any subsequent version has "solved" this issue.
  - demi56 2y ago
    > Sorry, but no - putting the burden on the developer to detect whether they are running in a container or not and then determine and adjust to cgroup settings is far too high an encumbrance on the service developer. Because there’s no one way solution to this problem, the problem isn’t unique to only Go, but every GC language because you’re starving the program if there isn’t sufficient CPU Quota it will all eventually lead to CPU throttling, this isn’t really the problem of Go or any other GC language but at the OS layer, the inherent nature of containers Secondly am pretty sure the Linux CFS does not strictly follow the CPU Quota, tho there could be something like a panic or warning, or switching to entirely different memory management just for what ? people who want 10ms ?