-
Notifications
You must be signed in to change notification settings - Fork 18.8k
Open
Labels
NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.compiler/runtimeIssues related to the Go compiler and/or runtime.Issues related to the Go compiler and/or runtime.
Milestone
Description
What version of Go are you using (go version)?
$ go version go version go1.13.4 linux/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/eg/.cache/go-build" GOENV="/home/eg/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/eg/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/lib/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/home/eg/go/src/bitbucket.org/triangleteam/resource-manager/go.mod" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build569889623=/tmp/go-build -gno-record-gcc-switches"
What did you do?
I wrote a simple code to check built in golang tracing:
package main
import (
"os"
"runtime"
"runtime/trace"
"sync"
"time"
)
func main() {
f, err := os.Create("trace.out")
if err != nil {
panic(err)
}
trace.Start(f)
defer func() {
trace.Stop()
_ = f.Close()
}()
wg := sync.WaitGroup{}
for g := 0; g < runtime.NumCPU(); g++ {
wg.Add(1)
go func() {
for i := 0; i < 40; i++ {
bs := make([]byte, 1024*1024)
for k := range bs {
bs[k] = byte(k % 8)
}
time.Sleep(50 * time.Millisecond)
}
wg.Done()
}()
}
wg.Wait()
}After running this program and getting trace.out file as an output I do $ go tool trace trace.out, open http://127.0.0.1:32935/mmu in the browser and look at the plots with and without STW checkbox set.
What did you expect to see?
I expect that X-axis range (min and max Window duration for which MMU function is evaluated) is the same with STW set and not set.
What did you see instead?
I see that with STW checkbox set the window duration range is [1ms, ~10s], and when checkbox is unset range is [1ns, 1ms].
To conclude: if I get everything correctly, such behavior makes it harder to understand how GC affects the utilization. Should we make the window duration range consistent across any set of checked options? Or maybe we should make it possible for user to configure the range.
Metadata
Metadata
Assignees
Labels
NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.compiler/runtimeIssues related to the Go compiler and/or runtime.Issues related to the Go compiler and/or runtime.

