GODEBUG = madvdontneed = 1 does not seem to take effect #39295
Comments
|
The
|
davecheney
added
the
WaitingForInfo
|
1.I mainly control the start, stop and restart specific service file contents of the program through systemctl as follows: [Service] [Install] |
I see a typo in your systemd config. What happens if you fix this? |
When I use go1.12 + or higher for stress testing, the golang heap does not return to the system. Repeated stress testing will lead to OOM. I have consulted that by setting GODEBUG = madvdontneed = 1, the GC can be adjusted to return the memory To the operating system, so this environment variable is set |
|
When I use go1.10 / go1.11, the golang heap will be returned to the operating system, and will not be killed by the Linux system because of OOM |
|
I'm not sure you understand my point: "Envirment" is a misspelling of "Environment" in your systemd unit. You should fix the typo in the unit, reload the configuration, and then report back if the issue persists. |
|
Change https://golang.org/cl/267100 mentions this issue: |
In Go 1.12, we changed the runtime to use MADV_FREE when available on Linux (falling back to MADV_DONTNEED) in CL 135395 to address issue #23687. While MADV_FREE is somewhat faster than MADV_DONTNEED, it doesn't affect many of the statistics that MADV_DONTNEED does until the memory is actually reclaimed under OS memory pressure. This generally leads to poor user experience, like confusing stats in top and other monitoring tools; and bad integration with management systems that respond to memory usage. We've seen numerous issues about this user experience, including #41818, #39295, #37585, #33376, and #30904, many questions on Go mailing lists, and requests for mechanisms to change this behavior at run-time, such as #40870. There are also issues that may be a result of this, but root-causing it can be difficult, such as #41444 and #39174. And there's some evidence it may even be incompatible with Android's process management in #37569. This CL changes the default to prefer MADV_DONTNEED over MADV_FREE, to favor user-friendliness and minimal surprise over performance. I think it's become clear that Linux's implementation of MADV_FREE ultimately doesn't meet our needs. We've also made many improvements to the scavenger since Go 1.12. In particular, it is now far more prompt and it is self-paced, so it will simply trickle memory back to the system a little more slowly with this change. This can still be overridden by setting GODEBUG=madvdontneed=0. Fixes #42330 (meta-issue). Fixes #41818, #39295, #37585, #33376, #30904 (many of which were already closed as "working as intended"). Change-Id: Ib6aa7f2dc8419b32516cc5a5fc402faf576c92e4 Reviewed-on: https://go-review.googlesource.com/c/go/+/267100 Trust: Austin Clements <austin@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
Hi, every one! pls tell me why, and how to use madvdontneed, thx! go version is 1.14.2 |
|
Please see https://github.com/golang/go/wiki/Questions. |
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
yes，it still exists
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
What did you expect to see?
The same copy of golang code is compiled with go1.10 / go1.11, and the running memory is relatively stable. After the flow pressure is stabilized, the memory drops slightly, and after compiling with go1.12 / go1.13 / go1.14, the process memory is after the sudden burst of traffic pressure, it has been going up. If you do this repeatedly, it will lead to the process because of OOM is killed, compared with the golang version, it is found that MADV_FREE was introduced after go1.12, so use GODEBUG = madvdontneed = 1 ./bin way to start the program, multiple tests still did not alleviate this problem.
What did you see instead?
The text was updated successfully, but these errors were encountered: