你正在使用哪个版本的Go( go version )?
$ go version go1.21.3 darwin/arm64这个问题在最新版本中是否重现？
是的，包括提示。
你正在使用什么操作系统和处理器架构( go env )?
go env 输出
$ go env
GO111MODULE='auto'
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/USER/Library/Caches/go-build'
GOENV='/Users/USER/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS='-count=1'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/USER/go/pkg/mod'
GONOPROXY='github.com/Org'
GONOSUMDB='github.com/Org,go.orgbuild.io'
GOOS='darwin'
GOPATH='/Users/USER/go'
GOPRIVATE='github.com/Org'
GOPROXY='binaries.orgbuild.io,proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.21.3/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.21.3/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.21.3'
GCCGO='gccgo'
AR='ar'
CC='clang'
CXX='c++'
CGO_ENABLED='1'
GOMOD=''
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/0t/nwrdnfnd2mjdgr0z_p_f6xww0000gq/T/go-build3503366670=/tmp/go-build -gno-record-gcc-switches -fno-common'你做了什么？
捕获运行 encoding/json 测试的跟踪记录，然后在go tool trace中查看：
$ go test -trace json.trace encoding/json
(我在为 CL 538515 实现堆指标时这样做的。起初我以为是我的代码有问题，但后来意识到旧跟踪器中也存在这个问题😅。)
你期望看到什么？
一个合理的NextGC指标值。
你看到了什么？
一个不合理的NextGC指标值。可能是由于 uint64 下溢引起的？
就我所知，问题似乎出在数据上，而不是跟踪查看器上。
$ go tool trace -d ./json.trace | grep HeapGoal
2023/11/01 09:10:58 Parsing trace...
2704 HeapGoal p=0 g=1 off=142 mem=4194304
3983536 HeapGoal p=3 g=36 off=133427 mem=5988680
7451664 HeapGoal p=0 g=35 off=4877 mem=10640088
12998705 HeapGoal p=8 g=19 off=144611 mem=18734952
22220882 HeapGoal p=5 g=19 off=141308 mem=32462632
41322629 HeapGoal p=2 g=36 off=117962 mem=49052584
73809753 HeapGoal p=1 g=36 off=95052 mem=38877592
100867596 HeapGoal p=0 g=34 off=49758 mem=17658824
103327101 HeapGoal p=1 g=80 off=95363 mem=49754376
106035005 HeapGoal p=1 g=34 off=95542 mem=55731352
112637966 HeapGoal p=1 g=34 off=95774 mem=67923528
122922303 HeapGoal p=0 g=50 off=57951 mem=91832744
127586144 HeapGoal p=1 g=146 off=97325 mem=8946670875736242639
128176272 HeapGoal p=1 g=146 off=97379 mem=91832744
135046177 HeapGoal p=6 g=15 off=143059 mem=19712536
144138898 HeapGoal p=7 g=14 off=144046 mem=35340824
165010277 HeapGoal p=1 g=14 off=104248 mem=53870584
185668071 HeapGoal p=0 g=121 off=80009 mem=8946670875735194404
186297063 HeapGoal p=0 g=121 off=80048 mem=53870584
199934729 HeapGoal p=4 g=34 off=138916 mem=33694248
214716523 HeapGoal p=1 g=50 off=115986 mem=50463048
233048733 HeapGoal p=3 g=18 off=136782 mem=22212712
250342656 HeapGoal p=3 g=19 off=136882 mem=34606152
260790321 HeapGoal p=2 g=35 off=132457 mem=35196680
265980994 HeapGoal p=2 g=14 off=132538 mem=62106312
3条答案
按热度按时间juzqafwq1#
哎。我认为这可能不是一个bug,而是当调用
SetGCPercent(-1)时发生的事情的产物。它将 GC 百分比目标设置为defaultHeapMinimum*uint64(-1)/100。然后堆目标计算可能会从这个数字中减去一些相对较小的数，这就是为什么它会波动一点的原因。我一直都不喜欢这种逻辑。也许现在是时候终于修复它了。
这也让我意识到我们确实没有发出足够的
HeapGoal事件。据我所知，我们只在跟踪开始时发出一个事件，以及在调用SetGCPercent或SetMemoryLimit时发出一个事件。我们应该至少每隔一个 GC 周期发出一个事件。xwmevbvl2#
实际上，我们应该如何在trace viewer中表示设置
GOGC=off?仅仅选择一个高数值似乎并不完全正确，因为它们都使图形看起来很奇怪。我猜想理想情况下，图形在该区域不应该有任何数据，所以也许这意味着它应该是零？tcbh2hod3#
啊，我没想到编码/json测试会调用SetGCPercent(-1)。我认为零是一个很好的值，正如你提到的原因。它也与当前的cmd/trace代码很好地配合。所以给零加1分。