b513bd808f
Currently the pacer is designed to pace against the edge. Specifically, it tries to find the sweet spot at which there are zero assists, but simultaneously finishes each GC perfectly on time. This pretty much works, despite the noisiness of the measurement of the cons/mark ratio, which is central to the pacer's function. (And this noise is basically a given; the cons/mark ratio is used as a prediction under a steady-state assumption.) Typically, this means that the GC might assist a little bit more because it started the GC late, or it might execute more GC cycles because it started early. In many cases the magnitude of this variation is small. However, we can't possibly control for all sources of noise, especially since some noise can come from the underlying system. Furthermore, there are inputs to the measurement that have effectively no restrictions on how they vary, and the pacer needs to assume that they're essentially static when they might not be in some applications (i.e. goroutine stacks). The result of high noise is that the variation in when a GC starts is much higher, leading to a significant amount of assists in some GC cycles. While the GC cycle frequency basically averages out in the steady-state in the face of this variation, starting a GC late has the significant drawback of reducing application latencies. This CL thus biases the pacer toward avoiding assists by picking a cons/mark smoothing function that takes the maximum measured cons/mark over 5 cycles total. I picked 5 cycles because empirically this was the best trade-off between window size and smoothness for a uniformly distributed jitter in the cons/mark signal. The cost here is that if there's a significant phase change in the application that makes it less active with the GC, then we'll be using a stale cons/mark measurement for 5 cycles. I suspect this is fine precisely because this only happens when the application becomes less active, i.e. when latency matters less. Another good reason for this particular bias is that even though the GC might start earlier and end earlier on average, resulting in more frequent GC cycles and potentially worse throughput, it also means that it uses less memory used on average. As a result, there's a reasonable workaround in just turning GOGC up slightly to reduce GC cycle frequency and bringing memory (and hopefully throughput) levels back to the same baseline. Meanwhile, there should still be fewer assists than before which is just a clear improvement to latency. Lastly, this CL updates the GC pacer tests to capture this bias against assists and toward GC cycles starting earlier in the face of noise. Sweet benchmarks didn't show any meaningful difference, but real production applications showed a reduction in tail latencies of up to 45%. Updates #56966. Change-Id: I8f03d793f9a1c6e7ef3524d18294dbc0d7de6122 Reviewed-on: https://go-review.googlesource.com/c/go/+/467875 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> |
||
---|---|---|
.github | ||
api | ||
doc | ||
lib/time | ||
misc | ||
src | ||
test | ||
.gitattributes | ||
.gitignore | ||
codereview.cfg | ||
CONTRIBUTING.md | ||
go.env | ||
LICENSE | ||
PATENTS | ||
README.md | ||
SECURITY.md |
The Go Programming Language
Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.
Gopher image by Renee French, licensed under Creative Commons 4.0 Attributions license.
Our canonical Git repository is located at https://go.googlesource.com/go. There is a mirror of the repository at https://github.com/golang/go.
Unless otherwise noted, the Go source files are distributed under the BSD-style license found in the LICENSE file.
Download and Install
Binary Distributions
Official binary distributions are available at https://go.dev/dl/.
After downloading a binary release, visit https://go.dev/doc/install for installation instructions.
Install From Source
If a binary distribution is not available for your combination of operating system and architecture, visit https://go.dev/doc/install/source for source installation instructions.
Contributing
Go is the work of thousands of contributors. We appreciate your help!
To contribute, please read the contribution guidelines at https://go.dev/doc/contribute.
Note that the Go project uses the issue tracker for bug reports and proposals only. See https://go.dev/wiki/Questions for a list of places to ask questions about the Go language.