2016-03-01 22:57:46 +00:00
|
|
|
// Copyright 2014 The Go Authors. All rights reserved.
|
2015-01-30 13:31:43 +03:00
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
|
|
|
|
// Serving of pprof-like profiles.
|
|
|
|
|
|
|
|
|
|
package main
|
|
|
|
|
|
|
|
|
|
import (
|
|
|
|
|
"bufio"
|
|
|
|
|
"fmt"
|
2016-05-24 12:50:38 +01:00
|
|
|
"io"
|
2015-01-30 13:31:43 +03:00
|
|
|
"io/ioutil"
|
|
|
|
|
"net/http"
|
|
|
|
|
"os"
|
|
|
|
|
"os/exec"
|
2017-09-19 18:18:09 +09:00
|
|
|
"path/filepath"
|
|
|
|
|
"runtime"
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
"sort"
|
2017-11-02 19:17:39 -04:00
|
|
|
"strconv"
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
"time"
|
2017-02-17 00:17:26 -05:00
|
|
|
|
2018-10-29 10:18:05 -04:00
|
|
|
trace "internal/traceparser"
|
|
|
|
|
|
2017-02-17 00:17:26 -05:00
|
|
|
"github.com/google/pprof/profile"
|
2015-01-30 13:31:43 +03:00
|
|
|
)
|
|
|
|
|
|
2017-09-19 18:18:09 +09:00
|
|
|
func goCmd() string {
|
|
|
|
|
var exeSuffix string
|
|
|
|
|
if runtime.GOOS == "windows" {
|
|
|
|
|
exeSuffix = ".exe"
|
|
|
|
|
}
|
|
|
|
|
path := filepath.Join(runtime.GOROOT(), "bin", "go"+exeSuffix)
|
|
|
|
|
if _, err := os.Stat(path); err == nil {
|
|
|
|
|
return path
|
|
|
|
|
}
|
|
|
|
|
return "go"
|
|
|
|
|
}
|
|
|
|
|
|
2015-01-30 13:31:43 +03:00
|
|
|
func init() {
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
http.HandleFunc("/io", serveSVGProfile(pprofByGoroutine(computePprofIO)))
|
|
|
|
|
http.HandleFunc("/block", serveSVGProfile(pprofByGoroutine(computePprofBlock)))
|
|
|
|
|
http.HandleFunc("/syscall", serveSVGProfile(pprofByGoroutine(computePprofSyscall)))
|
|
|
|
|
http.HandleFunc("/sched", serveSVGProfile(pprofByGoroutine(computePprofSched)))
|
|
|
|
|
|
runtime/trace: rename "Span" with "Region"
"Span" is a commonly used term in many distributed tracing systems
(Dapper, OpenCensus, OpenTracing, ...). They use it to refer to a
period of time, not necessarily tied into execution of underlying
processor, thread, or goroutine, unlike the "Span" of runtime/trace
package.
Since distributed tracing and go runtime execution tracing are
already similar enough to cause confusion, this CL attempts to avoid
using the same word if possible.
"Region" is being used in a certain tracing system to refer to a code
region which is pretty close to what runtime/trace.Span currently
refers to. So, replace that.
https://software.intel.com/en-us/itc-user-and-reference-guide-defining-and-recording-functions-or-regions
This CL also tweaks APIs a bit based on jbd and heschi's comments:
NewContext -> NewTask
and it now returns a Task object that exports End method.
StartSpan -> StartRegion
and it now returns a Region object that exports End method.
Also, changed WithSpan to WithRegion and it now takes func() with no
context. Another thought is to get rid of WithRegion. It is a nice
concept but in practice, it seems problematic (a lot of code churn,
and polluting stack trace). Already, the tracing concept is very low
level, and we hope this API to be used with great care.
Recommended usage will be
defer trace.StartRegion(ctx, "someRegion").End()
Left old APIs untouched in this CL. Once the usage of them are cleaned
up, they will be removed in a separate CL.
Change-Id: I73880635e437f3aad51314331a035dd1459b9f3a
Reviewed-on: https://go-review.googlesource.com/108296
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: JBD <jbd@google.com>
2018-04-19 14:58:42 -04:00
|
|
|
http.HandleFunc("/regionio", serveSVGProfile(pprofByRegion(computePprofIO)))
|
|
|
|
|
http.HandleFunc("/regionblock", serveSVGProfile(pprofByRegion(computePprofBlock)))
|
|
|
|
|
http.HandleFunc("/regionsyscall", serveSVGProfile(pprofByRegion(computePprofSyscall)))
|
|
|
|
|
http.HandleFunc("/regionsched", serveSVGProfile(pprofByRegion(computePprofSched)))
|
2015-01-30 13:31:43 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Record represents one entry in pprof-like profiles.
|
|
|
|
|
type Record struct {
|
|
|
|
|
stk []*trace.Frame
|
|
|
|
|
n uint64
|
|
|
|
|
time int64
|
|
|
|
|
}
|
|
|
|
|
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
// interval represents a time interval in the trace.
|
|
|
|
|
type interval struct {
|
|
|
|
|
begin, end int64 // nanoseconds.
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-29 10:18:05 -04:00
|
|
|
func pprofByGoroutine(compute func(io.Writer, map[uint64][]interval, *trace.Parsed) error) func(w io.Writer, r *http.Request) error {
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
return func(w io.Writer, r *http.Request) error {
|
|
|
|
|
id := r.FormValue("id")
|
2018-10-29 10:18:05 -04:00
|
|
|
res, err := parseTrace()
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
if err != nil {
|
|
|
|
|
return err
|
|
|
|
|
}
|
2018-10-29 10:18:05 -04:00
|
|
|
gToIntervals, err := pprofMatchingGoroutines(id, res)
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
if err != nil {
|
|
|
|
|
return err
|
|
|
|
|
}
|
2018-10-29 10:18:05 -04:00
|
|
|
return compute(w, gToIntervals, res)
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-29 10:18:05 -04:00
|
|
|
func pprofByRegion(compute func(io.Writer, map[uint64][]interval, *trace.Parsed) error) func(w io.Writer, r *http.Request) error {
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
return func(w io.Writer, r *http.Request) error {
|
runtime/trace: rename "Span" with "Region"
"Span" is a commonly used term in many distributed tracing systems
(Dapper, OpenCensus, OpenTracing, ...). They use it to refer to a
period of time, not necessarily tied into execution of underlying
processor, thread, or goroutine, unlike the "Span" of runtime/trace
package.
Since distributed tracing and go runtime execution tracing are
already similar enough to cause confusion, this CL attempts to avoid
using the same word if possible.
"Region" is being used in a certain tracing system to refer to a code
region which is pretty close to what runtime/trace.Span currently
refers to. So, replace that.
https://software.intel.com/en-us/itc-user-and-reference-guide-defining-and-recording-functions-or-regions
This CL also tweaks APIs a bit based on jbd and heschi's comments:
NewContext -> NewTask
and it now returns a Task object that exports End method.
StartSpan -> StartRegion
and it now returns a Region object that exports End method.
Also, changed WithSpan to WithRegion and it now takes func() with no
context. Another thought is to get rid of WithRegion. It is a nice
concept but in practice, it seems problematic (a lot of code churn,
and polluting stack trace). Already, the tracing concept is very low
level, and we hope this API to be used with great care.
Recommended usage will be
defer trace.StartRegion(ctx, "someRegion").End()
Left old APIs untouched in this CL. Once the usage of them are cleaned
up, they will be removed in a separate CL.
Change-Id: I73880635e437f3aad51314331a035dd1459b9f3a
Reviewed-on: https://go-review.googlesource.com/108296
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: JBD <jbd@google.com>
2018-04-19 14:58:42 -04:00
|
|
|
filter, err := newRegionFilter(r)
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
if err != nil {
|
|
|
|
|
return err
|
|
|
|
|
}
|
runtime/trace: rename "Span" with "Region"
"Span" is a commonly used term in many distributed tracing systems
(Dapper, OpenCensus, OpenTracing, ...). They use it to refer to a
period of time, not necessarily tied into execution of underlying
processor, thread, or goroutine, unlike the "Span" of runtime/trace
package.
Since distributed tracing and go runtime execution tracing are
already similar enough to cause confusion, this CL attempts to avoid
using the same word if possible.
"Region" is being used in a certain tracing system to refer to a code
region which is pretty close to what runtime/trace.Span currently
refers to. So, replace that.
https://software.intel.com/en-us/itc-user-and-reference-guide-defining-and-recording-functions-or-regions
This CL also tweaks APIs a bit based on jbd and heschi's comments:
NewContext -> NewTask
and it now returns a Task object that exports End method.
StartSpan -> StartRegion
and it now returns a Region object that exports End method.
Also, changed WithSpan to WithRegion and it now takes func() with no
context. Another thought is to get rid of WithRegion. It is a nice
concept but in practice, it seems problematic (a lot of code churn,
and polluting stack trace). Already, the tracing concept is very low
level, and we hope this API to be used with great care.
Recommended usage will be
defer trace.StartRegion(ctx, "someRegion").End()
Left old APIs untouched in this CL. Once the usage of them are cleaned
up, they will be removed in a separate CL.
Change-Id: I73880635e437f3aad51314331a035dd1459b9f3a
Reviewed-on: https://go-review.googlesource.com/108296
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: JBD <jbd@google.com>
2018-04-19 14:58:42 -04:00
|
|
|
gToIntervals, err := pprofMatchingRegions(filter)
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
if err != nil {
|
|
|
|
|
return err
|
|
|
|
|
}
|
2018-10-29 10:18:05 -04:00
|
|
|
events, _ := parseTrace()
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
|
|
|
|
|
return compute(w, gToIntervals, events)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-02 19:17:39 -04:00
|
|
|
// pprofMatchingGoroutines parses the goroutine type id string (i.e. pc)
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
// and returns the ids of goroutines of the matching type and its interval.
|
2017-11-02 19:17:39 -04:00
|
|
|
// If the id string is empty, returns nil without an error.
|
2018-10-29 10:18:05 -04:00
|
|
|
func pprofMatchingGoroutines(id string, p *trace.Parsed) (map[uint64][]interval, error) {
|
2017-11-02 19:17:39 -04:00
|
|
|
if id == "" {
|
|
|
|
|
return nil, nil
|
|
|
|
|
}
|
|
|
|
|
pc, err := strconv.ParseUint(id, 10, 64) // id is string
|
|
|
|
|
if err != nil {
|
|
|
|
|
return nil, fmt.Errorf("invalid goroutine type: %v", id)
|
|
|
|
|
}
|
2018-10-29 10:18:05 -04:00
|
|
|
analyzeGoroutines(p)
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
var res map[uint64][]interval
|
2017-11-02 19:17:39 -04:00
|
|
|
for _, g := range gs {
|
|
|
|
|
if g.PC != pc {
|
|
|
|
|
continue
|
|
|
|
|
}
|
|
|
|
|
if res == nil {
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
res = make(map[uint64][]interval)
|
|
|
|
|
}
|
|
|
|
|
endTime := g.EndTime
|
|
|
|
|
if g.EndTime == 0 {
|
|
|
|
|
endTime = lastTimestamp() // the trace doesn't include the goroutine end event. Use the trace end time.
|
2017-11-02 19:17:39 -04:00
|
|
|
}
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
res[g.ID] = []interval{{begin: g.StartTime, end: endTime}}
|
2017-11-02 19:17:39 -04:00
|
|
|
}
|
|
|
|
|
if len(res) == 0 && id != "" {
|
|
|
|
|
return nil, fmt.Errorf("failed to find matching goroutines for id: %s", id)
|
|
|
|
|
}
|
|
|
|
|
return res, nil
|
|
|
|
|
}
|
|
|
|
|
|
runtime/trace: rename "Span" with "Region"
"Span" is a commonly used term in many distributed tracing systems
(Dapper, OpenCensus, OpenTracing, ...). They use it to refer to a
period of time, not necessarily tied into execution of underlying
processor, thread, or goroutine, unlike the "Span" of runtime/trace
package.
Since distributed tracing and go runtime execution tracing are
already similar enough to cause confusion, this CL attempts to avoid
using the same word if possible.
"Region" is being used in a certain tracing system to refer to a code
region which is pretty close to what runtime/trace.Span currently
refers to. So, replace that.
https://software.intel.com/en-us/itc-user-and-reference-guide-defining-and-recording-functions-or-regions
This CL also tweaks APIs a bit based on jbd and heschi's comments:
NewContext -> NewTask
and it now returns a Task object that exports End method.
StartSpan -> StartRegion
and it now returns a Region object that exports End method.
Also, changed WithSpan to WithRegion and it now takes func() with no
context. Another thought is to get rid of WithRegion. It is a nice
concept but in practice, it seems problematic (a lot of code churn,
and polluting stack trace). Already, the tracing concept is very low
level, and we hope this API to be used with great care.
Recommended usage will be
defer trace.StartRegion(ctx, "someRegion").End()
Left old APIs untouched in this CL. Once the usage of them are cleaned
up, they will be removed in a separate CL.
Change-Id: I73880635e437f3aad51314331a035dd1459b9f3a
Reviewed-on: https://go-review.googlesource.com/108296
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: JBD <jbd@google.com>
2018-04-19 14:58:42 -04:00
|
|
|
// pprofMatchingRegions returns the time intervals of matching regions
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
// grouped by the goroutine id. If the filter is nil, returns nil without an error.
|
runtime/trace: rename "Span" with "Region"
"Span" is a commonly used term in many distributed tracing systems
(Dapper, OpenCensus, OpenTracing, ...). They use it to refer to a
period of time, not necessarily tied into execution of underlying
processor, thread, or goroutine, unlike the "Span" of runtime/trace
package.
Since distributed tracing and go runtime execution tracing are
already similar enough to cause confusion, this CL attempts to avoid
using the same word if possible.
"Region" is being used in a certain tracing system to refer to a code
region which is pretty close to what runtime/trace.Span currently
refers to. So, replace that.
https://software.intel.com/en-us/itc-user-and-reference-guide-defining-and-recording-functions-or-regions
This CL also tweaks APIs a bit based on jbd and heschi's comments:
NewContext -> NewTask
and it now returns a Task object that exports End method.
StartSpan -> StartRegion
and it now returns a Region object that exports End method.
Also, changed WithSpan to WithRegion and it now takes func() with no
context. Another thought is to get rid of WithRegion. It is a nice
concept but in practice, it seems problematic (a lot of code churn,
and polluting stack trace). Already, the tracing concept is very low
level, and we hope this API to be used with great care.
Recommended usage will be
defer trace.StartRegion(ctx, "someRegion").End()
Left old APIs untouched in this CL. Once the usage of them are cleaned
up, they will be removed in a separate CL.
Change-Id: I73880635e437f3aad51314331a035dd1459b9f3a
Reviewed-on: https://go-review.googlesource.com/108296
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: JBD <jbd@google.com>
2018-04-19 14:58:42 -04:00
|
|
|
func pprofMatchingRegions(filter *regionFilter) (map[uint64][]interval, error) {
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
res, err := analyzeAnnotations()
|
2015-01-30 13:31:43 +03:00
|
|
|
if err != nil {
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
return nil, err
|
2015-01-30 13:31:43 +03:00
|
|
|
}
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
if filter == nil {
|
|
|
|
|
return nil, nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gToIntervals := make(map[uint64][]interval)
|
runtime/trace: rename "Span" with "Region"
"Span" is a commonly used term in many distributed tracing systems
(Dapper, OpenCensus, OpenTracing, ...). They use it to refer to a
period of time, not necessarily tied into execution of underlying
processor, thread, or goroutine, unlike the "Span" of runtime/trace
package.
Since distributed tracing and go runtime execution tracing are
already similar enough to cause confusion, this CL attempts to avoid
using the same word if possible.
"Region" is being used in a certain tracing system to refer to a code
region which is pretty close to what runtime/trace.Span currently
refers to. So, replace that.
https://software.intel.com/en-us/itc-user-and-reference-guide-defining-and-recording-functions-or-regions
This CL also tweaks APIs a bit based on jbd and heschi's comments:
NewContext -> NewTask
and it now returns a Task object that exports End method.
StartSpan -> StartRegion
and it now returns a Region object that exports End method.
Also, changed WithSpan to WithRegion and it now takes func() with no
context. Another thought is to get rid of WithRegion. It is a nice
concept but in practice, it seems problematic (a lot of code churn,
and polluting stack trace). Already, the tracing concept is very low
level, and we hope this API to be used with great care.
Recommended usage will be
defer trace.StartRegion(ctx, "someRegion").End()
Left old APIs untouched in this CL. Once the usage of them are cleaned
up, they will be removed in a separate CL.
Change-Id: I73880635e437f3aad51314331a035dd1459b9f3a
Reviewed-on: https://go-review.googlesource.com/108296
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: JBD <jbd@google.com>
2018-04-19 14:58:42 -04:00
|
|
|
for id, regions := range res.regions {
|
|
|
|
|
for _, s := range regions {
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
if filter.match(id, s) {
|
|
|
|
|
gToIntervals[s.G] = append(gToIntervals[s.G], interval{begin: s.firstTimestamp(), end: s.lastTimestamp()})
|
|
|
|
|
}
|
|
|
|
|
}
|
2017-11-02 19:17:39 -04:00
|
|
|
}
|
|
|
|
|
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
for g, intervals := range gToIntervals {
|
runtime/trace: rename "Span" with "Region"
"Span" is a commonly used term in many distributed tracing systems
(Dapper, OpenCensus, OpenTracing, ...). They use it to refer to a
period of time, not necessarily tied into execution of underlying
processor, thread, or goroutine, unlike the "Span" of runtime/trace
package.
Since distributed tracing and go runtime execution tracing are
already similar enough to cause confusion, this CL attempts to avoid
using the same word if possible.
"Region" is being used in a certain tracing system to refer to a code
region which is pretty close to what runtime/trace.Span currently
refers to. So, replace that.
https://software.intel.com/en-us/itc-user-and-reference-guide-defining-and-recording-functions-or-regions
This CL also tweaks APIs a bit based on jbd and heschi's comments:
NewContext -> NewTask
and it now returns a Task object that exports End method.
StartSpan -> StartRegion
and it now returns a Region object that exports End method.
Also, changed WithSpan to WithRegion and it now takes func() with no
context. Another thought is to get rid of WithRegion. It is a nice
concept but in practice, it seems problematic (a lot of code churn,
and polluting stack trace). Already, the tracing concept is very low
level, and we hope this API to be used with great care.
Recommended usage will be
defer trace.StartRegion(ctx, "someRegion").End()
Left old APIs untouched in this CL. Once the usage of them are cleaned
up, they will be removed in a separate CL.
Change-Id: I73880635e437f3aad51314331a035dd1459b9f3a
Reviewed-on: https://go-review.googlesource.com/108296
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: JBD <jbd@google.com>
2018-04-19 14:58:42 -04:00
|
|
|
// in order to remove nested regions and
|
|
|
|
|
// consider only the outermost regions,
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
// first, we sort based on the start time
|
runtime/trace: rename "Span" with "Region"
"Span" is a commonly used term in many distributed tracing systems
(Dapper, OpenCensus, OpenTracing, ...). They use it to refer to a
period of time, not necessarily tied into execution of underlying
processor, thread, or goroutine, unlike the "Span" of runtime/trace
package.
Since distributed tracing and go runtime execution tracing are
already similar enough to cause confusion, this CL attempts to avoid
using the same word if possible.
"Region" is being used in a certain tracing system to refer to a code
region which is pretty close to what runtime/trace.Span currently
refers to. So, replace that.
https://software.intel.com/en-us/itc-user-and-reference-guide-defining-and-recording-functions-or-regions
This CL also tweaks APIs a bit based on jbd and heschi's comments:
NewContext -> NewTask
and it now returns a Task object that exports End method.
StartSpan -> StartRegion
and it now returns a Region object that exports End method.
Also, changed WithSpan to WithRegion and it now takes func() with no
context. Another thought is to get rid of WithRegion. It is a nice
concept but in practice, it seems problematic (a lot of code churn,
and polluting stack trace). Already, the tracing concept is very low
level, and we hope this API to be used with great care.
Recommended usage will be
defer trace.StartRegion(ctx, "someRegion").End()
Left old APIs untouched in this CL. Once the usage of them are cleaned
up, they will be removed in a separate CL.
Change-Id: I73880635e437f3aad51314331a035dd1459b9f3a
Reviewed-on: https://go-review.googlesource.com/108296
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: JBD <jbd@google.com>
2018-04-19 14:58:42 -04:00
|
|
|
// and then scan through to select only the outermost regions.
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
sort.Slice(intervals, func(i, j int) bool {
|
|
|
|
|
x := intervals[i].begin
|
|
|
|
|
y := intervals[j].begin
|
|
|
|
|
if x == y {
|
|
|
|
|
return intervals[i].end < intervals[j].end
|
|
|
|
|
}
|
|
|
|
|
return x < y
|
|
|
|
|
})
|
|
|
|
|
var lastTimestamp int64
|
|
|
|
|
var n int
|
runtime/trace: rename "Span" with "Region"
"Span" is a commonly used term in many distributed tracing systems
(Dapper, OpenCensus, OpenTracing, ...). They use it to refer to a
period of time, not necessarily tied into execution of underlying
processor, thread, or goroutine, unlike the "Span" of runtime/trace
package.
Since distributed tracing and go runtime execution tracing are
already similar enough to cause confusion, this CL attempts to avoid
using the same word if possible.
"Region" is being used in a certain tracing system to refer to a code
region which is pretty close to what runtime/trace.Span currently
refers to. So, replace that.
https://software.intel.com/en-us/itc-user-and-reference-guide-defining-and-recording-functions-or-regions
This CL also tweaks APIs a bit based on jbd and heschi's comments:
NewContext -> NewTask
and it now returns a Task object that exports End method.
StartSpan -> StartRegion
and it now returns a Region object that exports End method.
Also, changed WithSpan to WithRegion and it now takes func() with no
context. Another thought is to get rid of WithRegion. It is a nice
concept but in practice, it seems problematic (a lot of code churn,
and polluting stack trace). Already, the tracing concept is very low
level, and we hope this API to be used with great care.
Recommended usage will be
defer trace.StartRegion(ctx, "someRegion").End()
Left old APIs untouched in this CL. Once the usage of them are cleaned
up, they will be removed in a separate CL.
Change-Id: I73880635e437f3aad51314331a035dd1459b9f3a
Reviewed-on: https://go-review.googlesource.com/108296
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: JBD <jbd@google.com>
2018-04-19 14:58:42 -04:00
|
|
|
// select only the outermost regions.
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
for _, i := range intervals {
|
|
|
|
|
if lastTimestamp <= i.begin {
|
runtime/trace: rename "Span" with "Region"
"Span" is a commonly used term in many distributed tracing systems
(Dapper, OpenCensus, OpenTracing, ...). They use it to refer to a
period of time, not necessarily tied into execution of underlying
processor, thread, or goroutine, unlike the "Span" of runtime/trace
package.
Since distributed tracing and go runtime execution tracing are
already similar enough to cause confusion, this CL attempts to avoid
using the same word if possible.
"Region" is being used in a certain tracing system to refer to a code
region which is pretty close to what runtime/trace.Span currently
refers to. So, replace that.
https://software.intel.com/en-us/itc-user-and-reference-guide-defining-and-recording-functions-or-regions
This CL also tweaks APIs a bit based on jbd and heschi's comments:
NewContext -> NewTask
and it now returns a Task object that exports End method.
StartSpan -> StartRegion
and it now returns a Region object that exports End method.
Also, changed WithSpan to WithRegion and it now takes func() with no
context. Another thought is to get rid of WithRegion. It is a nice
concept but in practice, it seems problematic (a lot of code churn,
and polluting stack trace). Already, the tracing concept is very low
level, and we hope this API to be used with great care.
Recommended usage will be
defer trace.StartRegion(ctx, "someRegion").End()
Left old APIs untouched in this CL. Once the usage of them are cleaned
up, they will be removed in a separate CL.
Change-Id: I73880635e437f3aad51314331a035dd1459b9f3a
Reviewed-on: https://go-review.googlesource.com/108296
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: JBD <jbd@google.com>
2018-04-19 14:58:42 -04:00
|
|
|
intervals[n] = i // new non-overlapping region starts.
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
lastTimestamp = i.end
|
|
|
|
|
n++
|
runtime/trace: rename "Span" with "Region"
"Span" is a commonly used term in many distributed tracing systems
(Dapper, OpenCensus, OpenTracing, ...). They use it to refer to a
period of time, not necessarily tied into execution of underlying
processor, thread, or goroutine, unlike the "Span" of runtime/trace
package.
Since distributed tracing and go runtime execution tracing are
already similar enough to cause confusion, this CL attempts to avoid
using the same word if possible.
"Region" is being used in a certain tracing system to refer to a code
region which is pretty close to what runtime/trace.Span currently
refers to. So, replace that.
https://software.intel.com/en-us/itc-user-and-reference-guide-defining-and-recording-functions-or-regions
This CL also tweaks APIs a bit based on jbd and heschi's comments:
NewContext -> NewTask
and it now returns a Task object that exports End method.
StartSpan -> StartRegion
and it now returns a Region object that exports End method.
Also, changed WithSpan to WithRegion and it now takes func() with no
context. Another thought is to get rid of WithRegion. It is a nice
concept but in practice, it seems problematic (a lot of code churn,
and polluting stack trace). Already, the tracing concept is very low
level, and we hope this API to be used with great care.
Recommended usage will be
defer trace.StartRegion(ctx, "someRegion").End()
Left old APIs untouched in this CL. Once the usage of them are cleaned
up, they will be removed in a separate CL.
Change-Id: I73880635e437f3aad51314331a035dd1459b9f3a
Reviewed-on: https://go-review.googlesource.com/108296
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: JBD <jbd@google.com>
2018-04-19 14:58:42 -04:00
|
|
|
} // otherwise, skip because this region overlaps with a previous region.
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
}
|
|
|
|
|
gToIntervals[g] = intervals[:n]
|
|
|
|
|
}
|
|
|
|
|
return gToIntervals, nil
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-29 10:18:05 -04:00
|
|
|
func stklen(p *trace.Parsed, ev *trace.Event) int {
|
|
|
|
|
if ev.StkID == 0 {
|
|
|
|
|
return 0
|
|
|
|
|
}
|
|
|
|
|
return len(p.Stacks[ev.StkID])
|
|
|
|
|
}
|
|
|
|
|
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
// computePprofIO generates IO pprof-like profile (time spent in IO wait, currently only network blocking event).
|
2018-10-29 10:18:05 -04:00
|
|
|
func computePprofIO(w io.Writer, gToIntervals map[uint64][]interval, res *trace.Parsed) error {
|
|
|
|
|
events := res.Events
|
|
|
|
|
prof := make(map[uint32]Record)
|
2015-01-30 13:31:43 +03:00
|
|
|
for _, ev := range events {
|
2018-10-29 10:18:05 -04:00
|
|
|
if ev.Type != trace.EvGoBlockNet || ev.Link == nil || ev.StkID == 0 || stklen(res, ev) == 0 {
|
2015-01-30 13:31:43 +03:00
|
|
|
continue
|
|
|
|
|
}
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
overlapping := pprofOverlappingDuration(gToIntervals, ev)
|
|
|
|
|
if overlapping > 0 {
|
|
|
|
|
rec := prof[ev.StkID]
|
2018-10-29 10:18:05 -04:00
|
|
|
rec.stk = res.Stacks[ev.StkID]
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
rec.n++
|
|
|
|
|
rec.time += overlapping.Nanoseconds()
|
|
|
|
|
prof[ev.StkID] = rec
|
2017-11-02 19:17:39 -04:00
|
|
|
}
|
2015-01-30 13:31:43 +03:00
|
|
|
}
|
2016-05-24 12:50:38 +01:00
|
|
|
return buildProfile(prof).Write(w)
|
2015-01-30 13:31:43 +03:00
|
|
|
}
|
|
|
|
|
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
// computePprofBlock generates blocking pprof-like profile (time spent blocked on synchronization primitives).
|
2018-10-29 10:18:05 -04:00
|
|
|
func computePprofBlock(w io.Writer, gToIntervals map[uint64][]interval, res *trace.Parsed) error {
|
|
|
|
|
events := res.Events
|
|
|
|
|
prof := make(map[uint32]Record)
|
2015-01-30 13:31:43 +03:00
|
|
|
for _, ev := range events {
|
|
|
|
|
switch ev.Type {
|
|
|
|
|
case trace.EvGoBlockSend, trace.EvGoBlockRecv, trace.EvGoBlockSelect,
|
runtime, cmd/trace: track goroutines blocked on GC assists
Currently when a goroutine blocks on a GC assist, it emits a generic
EvGoBlock event. Since assist blocking events and, in particular, the
length of the blocked assist queue, are important for diagnosing GC
behavior, this commit adds a new EvGoBlockGC event for blocking on a
GC assist. The trace viewer uses this event to report a "waiting on
GC" count in the "Goroutines" row. This makes sense because, unlike
other blocked goroutines, these goroutines do have work to do, so
being blocked on a GC assist is quite similar to being in the
"runnable" state, which we also report in the trace viewer.
Change-Id: Ic21a326992606b121ea3d3d00110d8d1fdc7a5ef
Reviewed-on: https://go-review.googlesource.com/30704
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
2016-10-08 18:38:35 -04:00
|
|
|
trace.EvGoBlockSync, trace.EvGoBlockCond, trace.EvGoBlockGC:
|
2017-11-02 19:17:39 -04:00
|
|
|
// TODO(hyangah): figure out why EvGoBlockGC should be here.
|
|
|
|
|
// EvGoBlockGC indicates the goroutine blocks on GC assist, not
|
|
|
|
|
// on synchronization primitives.
|
2015-01-30 13:31:43 +03:00
|
|
|
default:
|
|
|
|
|
continue
|
|
|
|
|
}
|
2018-10-29 10:18:05 -04:00
|
|
|
if ev.Link == nil || ev.StkID == 0 || stklen(res, ev) == 0 {
|
2015-01-30 13:31:43 +03:00
|
|
|
continue
|
|
|
|
|
}
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
overlapping := pprofOverlappingDuration(gToIntervals, ev)
|
|
|
|
|
if overlapping > 0 {
|
|
|
|
|
rec := prof[ev.StkID]
|
2018-10-29 10:18:05 -04:00
|
|
|
rec.stk = res.Stacks[ev.StkID]
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
rec.n++
|
|
|
|
|
rec.time += overlapping.Nanoseconds()
|
|
|
|
|
prof[ev.StkID] = rec
|
2017-11-02 19:17:39 -04:00
|
|
|
}
|
2015-01-30 13:31:43 +03:00
|
|
|
}
|
2016-05-24 12:50:38 +01:00
|
|
|
return buildProfile(prof).Write(w)
|
2015-01-30 13:31:43 +03:00
|
|
|
}
|
|
|
|
|
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
// computePprofSyscall generates syscall pprof-like profile (time spent blocked in syscalls).
|
2018-10-29 10:18:05 -04:00
|
|
|
func computePprofSyscall(w io.Writer, gToIntervals map[uint64][]interval, res *trace.Parsed) error {
|
|
|
|
|
events := res.Events
|
|
|
|
|
prof := make(map[uint32]Record)
|
2015-01-30 13:31:43 +03:00
|
|
|
for _, ev := range events {
|
2018-10-29 10:18:05 -04:00
|
|
|
if ev.Type != trace.EvGoSysCall || ev.Link == nil || ev.StkID == 0 || stklen(res, ev) == 0 {
|
2015-01-30 13:31:43 +03:00
|
|
|
continue
|
|
|
|
|
}
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
overlapping := pprofOverlappingDuration(gToIntervals, ev)
|
|
|
|
|
if overlapping > 0 {
|
|
|
|
|
rec := prof[ev.StkID]
|
2018-10-29 10:18:05 -04:00
|
|
|
rec.stk = res.Stacks[ev.StkID]
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
rec.n++
|
|
|
|
|
rec.time += overlapping.Nanoseconds()
|
|
|
|
|
prof[ev.StkID] = rec
|
2017-11-02 19:17:39 -04:00
|
|
|
}
|
2015-01-30 13:31:43 +03:00
|
|
|
}
|
2016-05-24 12:50:38 +01:00
|
|
|
return buildProfile(prof).Write(w)
|
2015-01-30 13:31:43 +03:00
|
|
|
}
|
|
|
|
|
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
// computePprofSched generates scheduler latency pprof-like profile
|
2015-01-30 13:31:43 +03:00
|
|
|
// (time between a goroutine become runnable and actually scheduled for execution).
|
2018-10-29 10:18:05 -04:00
|
|
|
func computePprofSched(w io.Writer, gToIntervals map[uint64][]interval, res *trace.Parsed) error {
|
|
|
|
|
events := res.Events
|
|
|
|
|
prof := make(map[uint32]Record)
|
2015-01-30 13:31:43 +03:00
|
|
|
for _, ev := range events {
|
|
|
|
|
if (ev.Type != trace.EvGoUnblock && ev.Type != trace.EvGoCreate) ||
|
2018-10-29 10:18:05 -04:00
|
|
|
ev.Link == nil || ev.StkID == 0 || stklen(res, ev) == 0 {
|
2015-01-30 13:31:43 +03:00
|
|
|
continue
|
|
|
|
|
}
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
overlapping := pprofOverlappingDuration(gToIntervals, ev)
|
|
|
|
|
if overlapping > 0 {
|
|
|
|
|
rec := prof[ev.StkID]
|
2018-10-29 10:18:05 -04:00
|
|
|
rec.stk = res.Stacks[ev.StkID]
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
rec.n++
|
|
|
|
|
rec.time += overlapping.Nanoseconds()
|
|
|
|
|
prof[ev.StkID] = rec
|
2017-11-02 19:17:39 -04:00
|
|
|
}
|
2015-01-30 13:31:43 +03:00
|
|
|
}
|
2016-05-24 12:50:38 +01:00
|
|
|
return buildProfile(prof).Write(w)
|
2015-01-30 13:31:43 +03:00
|
|
|
}
|
|
|
|
|
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
// pprofOverlappingDuration returns the overlapping duration between
|
|
|
|
|
// the time intervals in gToIntervals and the specified event.
|
|
|
|
|
// If gToIntervals is nil, this simply returns the event's duration.
|
|
|
|
|
func pprofOverlappingDuration(gToIntervals map[uint64][]interval, ev *trace.Event) time.Duration {
|
|
|
|
|
if gToIntervals == nil { // No filtering.
|
|
|
|
|
return time.Duration(ev.Link.Ts-ev.Ts) * time.Nanosecond
|
|
|
|
|
}
|
|
|
|
|
intervals := gToIntervals[ev.G]
|
|
|
|
|
if len(intervals) == 0 {
|
|
|
|
|
return 0
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
var overlapping time.Duration
|
|
|
|
|
for _, i := range intervals {
|
|
|
|
|
if o := overlappingDuration(i.begin, i.end, ev.Ts, ev.Link.Ts); o > 0 {
|
|
|
|
|
overlapping += o
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return overlapping
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-24 12:50:38 +01:00
|
|
|
// serveSVGProfile serves pprof-like profile generated by prof as svg.
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
func serveSVGProfile(prof func(w io.Writer, r *http.Request) error) http.HandlerFunc {
|
2016-05-24 12:50:38 +01:00
|
|
|
return func(w http.ResponseWriter, r *http.Request) {
|
2017-11-02 19:17:39 -04:00
|
|
|
|
|
|
|
|
if r.FormValue("raw") != "" {
|
|
|
|
|
w.Header().Set("Content-Type", "application/octet-stream")
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
if err := prof(w, r); err != nil {
|
2017-11-02 19:17:39 -04:00
|
|
|
w.Header().Set("Content-Type", "text/plain; charset=utf-8")
|
|
|
|
|
w.Header().Set("X-Go-Pprof", "1")
|
|
|
|
|
http.Error(w, fmt.Sprintf("failed to get profile: %v", err), http.StatusInternalServerError)
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-24 12:50:38 +01:00
|
|
|
blockf, err := ioutil.TempFile("", "block")
|
|
|
|
|
if err != nil {
|
|
|
|
|
http.Error(w, fmt.Sprintf("failed to create temp file: %v", err), http.StatusInternalServerError)
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
defer func() {
|
|
|
|
|
blockf.Close()
|
|
|
|
|
os.Remove(blockf.Name())
|
|
|
|
|
}()
|
|
|
|
|
blockb := bufio.NewWriter(blockf)
|
cmd/trace: pprof computation for span types
/spanio, /spanblock, /spansched, /spansyscall provide
the pprof-style summary of span execution's
io, block, scheduling, syscall latency distributions
respectively.
The computation logic for /io, /block, /sched, /syscall
analysis was refactored and extended for reuse in these
new types of analysis. Upon the analysis query, we create
a map of goroutine id to time intervals based on the query
parameter, that represents the interesting time intervals
of matching goroutines. Only the events from the matching
goroutines that fall into the intervals are considered
in the pprof computation.
The new endpoints are not yet hooked into other span
analysis page (e.g. /userspan) yet.
Change-Id: I80c3396e45a2d6631758710de67d132e5832c7ce
Reviewed-on: https://go-review.googlesource.com/105822
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04 14:24:02 -04:00
|
|
|
if err := prof(blockb, r); err != nil {
|
2016-05-24 12:50:38 +01:00
|
|
|
http.Error(w, fmt.Sprintf("failed to generate profile: %v", err), http.StatusInternalServerError)
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
if err := blockb.Flush(); err != nil {
|
|
|
|
|
http.Error(w, fmt.Sprintf("failed to flush temp file: %v", err), http.StatusInternalServerError)
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
if err := blockf.Close(); err != nil {
|
|
|
|
|
http.Error(w, fmt.Sprintf("failed to close temp file: %v", err), http.StatusInternalServerError)
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
svgFilename := blockf.Name() + ".svg"
|
2017-09-19 18:18:09 +09:00
|
|
|
if output, err := exec.Command(goCmd(), "tool", "pprof", "-svg", "-output", svgFilename, blockf.Name()).CombinedOutput(); err != nil {
|
2016-05-24 12:50:38 +01:00
|
|
|
http.Error(w, fmt.Sprintf("failed to execute go tool pprof: %v\n%s", err, output), http.StatusInternalServerError)
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
defer os.Remove(svgFilename)
|
|
|
|
|
w.Header().Set("Content-Type", "image/svg+xml")
|
|
|
|
|
http.ServeFile(w, r, svgFilename)
|
2015-01-30 13:31:43 +03:00
|
|
|
}
|
|
|
|
|
}
|
2016-04-12 20:50:59 +02:00
|
|
|
|
2018-10-29 10:18:05 -04:00
|
|
|
func buildProfile(prof map[uint32]Record) *profile.Profile {
|
2016-04-12 20:50:59 +02:00
|
|
|
p := &profile.Profile{
|
|
|
|
|
PeriodType: &profile.ValueType{Type: "trace", Unit: "count"},
|
|
|
|
|
Period: 1,
|
|
|
|
|
SampleType: []*profile.ValueType{
|
|
|
|
|
{Type: "contentions", Unit: "count"},
|
|
|
|
|
{Type: "delay", Unit: "nanoseconds"},
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
locs := make(map[uint64]*profile.Location)
|
|
|
|
|
funcs := make(map[string]*profile.Function)
|
|
|
|
|
for _, rec := range prof {
|
|
|
|
|
var sloc []*profile.Location
|
|
|
|
|
for _, frame := range rec.stk {
|
|
|
|
|
loc := locs[frame.PC]
|
|
|
|
|
if loc == nil {
|
|
|
|
|
fn := funcs[frame.File+frame.Fn]
|
|
|
|
|
if fn == nil {
|
|
|
|
|
fn = &profile.Function{
|
|
|
|
|
ID: uint64(len(p.Function) + 1),
|
|
|
|
|
Name: frame.Fn,
|
|
|
|
|
SystemName: frame.Fn,
|
|
|
|
|
Filename: frame.File,
|
|
|
|
|
}
|
|
|
|
|
p.Function = append(p.Function, fn)
|
|
|
|
|
funcs[frame.File+frame.Fn] = fn
|
|
|
|
|
}
|
|
|
|
|
loc = &profile.Location{
|
|
|
|
|
ID: uint64(len(p.Location) + 1),
|
|
|
|
|
Address: frame.PC,
|
|
|
|
|
Line: []profile.Line{
|
|
|
|
|
profile.Line{
|
|
|
|
|
Function: fn,
|
|
|
|
|
Line: int64(frame.Line),
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
p.Location = append(p.Location, loc)
|
|
|
|
|
locs[frame.PC] = loc
|
|
|
|
|
}
|
|
|
|
|
sloc = append(sloc, loc)
|
|
|
|
|
}
|
|
|
|
|
p.Sample = append(p.Sample, &profile.Sample{
|
|
|
|
|
Value: []int64{int64(rec.n), rec.time},
|
|
|
|
|
Location: sloc,
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
return p
|
|
|
|
|
}
|