why use memory usage to calucate gc percent?

[Dingshujie]

1. Based on scavenging policy, go will not return released memory to os immediately, but nextgc use heapMarked, it diff with memory usage

2. memory usage from /proc/ may be delay, when trigger gc, and may lead gc percent incorrectly.

[cch123]

• Based on scavenging policy, go will not return released memory to os immediately, but nextgc use heapMarked, it diff with memory usage
• memory usage from /proc/ may be delay, when trigger gc, and may lead gc percent incorrectly.

reading from memstats heap is more accurate，but reading from memstats will cause stw，which is harmful

reading from proc is also not good，because some app has lots of goroutines，if goroutine stacks cost more memory than heap，we cannot get a proper new valve

if you have any good suggestion，im happy to accept

[Dingshujie]

• Based on scavenging policy, go will not return released memory to os immediately, but nextgc use heapMarked, it diff with memory usage
• memory usage from /proc/ may be delay, when trigger gc, and may lead gc percent incorrectly.

reading from memstats heap is more accurate，but reading from memstats will cause stw，which is harmful

reading from proc is also not good，because some app has lots of goroutines，if goroutine stacks cost more memory than heap，we cannot get a proper new valve

if you have any good suggestion，im happy to accept

how about runtime/metrics? metrics like /gc/heap/goal:bytes ?

[cch123]

• Based on scavenging policy, go will not return released memory to os immediately, but nextgc use heapMarked, it diff with memory usage
• memory usage from /proc/ may be delay, when trigger gc, and may lead gc percent incorrectly.

reading from memstats heap is more accurate，but reading from memstats will cause stw，which is harmful
reading from proc is also not good，because some app has lots of goroutines，if goroutine stacks cost more memory than heap，we cannot get a proper new valve
if you have any good suggestion，im happy to accept

how about runtime/metrics? metrics like /gc/heap/goal:bytes ?

runtime/metrics is imported in Go 1.16, I'll consider about it

[Dingshujie]

now, 1.19.beta provide Soft memory limit

[cch123]

now, 1.19.beta provide Soft memory limit

Yes, https://github.com/golang/proposal/blob/master/design/48409-soft-memory-limit.md, memory ballast and gc tuner will be useless when 1.19 finally released...

So I'll keep this lib as it is🤔

[Dingshujie]

now, 1.19.beta provide Soft memory limit

Yes, https://github.com/golang/proposal/blob/master/design/48409-soft-memory-limit.md, memory ballast and gc tuner will be useless when 1.19 finally released...

So I'll keep this lib as it is🤔

heap goal is min val among Limit and \gamma is equal to 1+\frac{GOGC}{100}

may be in same case，we can use gc tuner to reduce gc cycle time ?

[cch123]

now, 1.19.beta provide Soft memory limit

Yes, https://github.com/golang/proposal/blob/master/design/48409-soft-memory-limit.md, memory ballast and gc tuner will be useless when 1.19 finally released...
So I'll keep this lib as it is🤔

heap goal is min val among Limit and \gamma is equal to 1+\frac{GOGC}{100}

may be in same case，we can use gc tuner to reduce gc cycle time ?

I've read the proposal again, GOGC and GOMEMLIMIT will both affect the gc cycle and memory consumption, we need some experiment to know the exact effects... "useless" is a hasty conclusion.

[cch123]

now, 1.19.beta provide Soft memory limit

Yes, https://github.com/golang/proposal/blob/master/design/48409-soft-memory-limit.md, memory ballast and gc tuner will be useless when 1.19 finally released...
So I'll keep this lib as it is🤔

heap goal is min val among Limit and \gamma is equal to 1+\frac{GOGC}{100}

may be in same case，we can use gc tuner to reduce gc cycle time ?

But I think setting GOGC to off will have a same effect as gc tuner?

[Dingshujie]

now, 1.19.beta provide Soft memory limit

Yes, https://github.com/golang/proposal/blob/master/design/48409-soft-memory-limit.md, memory ballast and gc tuner will be useless when 1.19 finally released...
So I'll keep this lib as it is🤔

heap goal is min val among Limit and \gamma is equal to 1+\frac{GOGC}{100}
may be in same case，we can use gc tuner to reduce gc cycle time ?

But I think setting GOGC to off will have a same effect as gc tuner?

proposal says deal with Death spirals is to place a limit on the amount of total CPU utilization of the garbage collector. If the garbage collector were to execute and exceed that limit at any point, it will instead let the application proceed, even if that means missing its goal and breaching the memory limit. and proposal says they simply pick a reasonable default based on GOGC.

may be need to check implement of Soft memory limit to known real behave.