On Tue, May 12, 2020 at 1:01 PM Steve Canfield <stevencanfi...@gmail.com> wrote: > > Thanks Ian. Are there limits on how many such labels exist for the life of > the process, or can be active at once? Would labeling by rpc_guid be > acceptable?
There are no limits on labels other than memory usage. Ian > On Tue, May 12, 2020 at 12:06 PM Ian Lance Taylor <i...@golang.org> wrote: >> >> On Tue, May 12, 2020 at 10:31 AM Steve Canfield >> <stevencanfi...@gmail.com> wrote: >> > >> > I feel like I must be really dense, but it doesn't seem like you are >> > answering my question. >> > >> > Again, assume I have good reasons to want to know the cpu usage for every >> > request. Let's say I want to do isolation or billing or whatever on the >> > basis of cpu usage. >> > >> > Is this possible in Go? >> >> Use context labels (https://golang.org/pkg/runtime/pprof/#WithLabels) >> and CPU profiling. The profile should let you attribute CPU usage per >> label. >> >> However, that approach would only do sampling. I do not know of an >> approach that would let you get fairly precise CPU usage for every >> request, as when multiple goroutines are running in parallel there is >> no good way to separate out the CPU usage of each goroutine. >> >> Ian >> >> >> > On Mon, May 11, 2020 at 9:51 PM robert engels <reng...@ix.netcom.com> >> > wrote: >> >> >> >> Also, you may be interested in github.com/robaho/goanalyzer - I feel it >> >> makes latency analysis much easier. >> >> >> >> On May 11, 2020, at 11:46 PM, robert engels <reng...@ix.netcom.com> wrote: >> >> >> >> You don’t need to do it this way. see https://rakyll.org/profiler-labels/ >> >> >> >> You label the work. The work will be recorded with the labels for >> >> analysis. The labels can be nested. This will allow you to use the >> >> execution trace to profile wall time, see >> >> https://talks.golang.org/2015/dynamic-tools.slide#30 >> >> >> >> The standard pprof/profile will do cpu time profiling. >> >> >> >> This is all you really need to do the profiling. >> >> >> >> On May 11, 2020, at 10:58 PM, Steve Canfield <stevencanfi...@gmail.com> >> >> wrote: >> >> >> >> Thanks, but what about the "I can't enable profiling for every request" >> >> bit? Assume it's actually important for me to know the cpu consumption on >> >> a per request basis. >> >> >> >> On Mon, May 11, 2020 at 4:55 PM Robert Engels <reng...@ix.netcom.com> >> >> wrote: >> >>> >> >>> Look at pprof labels. >> >>> >> >>> On May 11, 2020, at 6:29 PM, Steven Canfield <stevencanfi...@gmail.com> >> >>> wrote: >> >>> >> >>> >> >>> Hi, >> >>> >> >>> I have an RPC server which has heterogenous requests, e.g. some calls >> >>> hit cache and are cheaper to serve while others need to compute a result. >> >>> >> >>> Is there any way to keep track of the cpu used just by one particular >> >>> goroutine[1]? It seems like there's not a straightforward way today >> >>> without adding logic around every single blocking piece (to start/stop a >> >>> timer), and in the future will become completely impossible with >> >>> "Non-cooperative goroutine preemption". >> >>> >> >>> I would be happy with only knowing this number when a goroutine finishes. >> >>> >> >>> I'm familiar with using pprof for measuring the entire process, but it's >> >>> not clear to me how to go from there to what was used by a particular >> >>> RPC, and I also can't enable profiling for every request. >> >>> >> >>> Thanks, >> >>> -Steve >> >>> >> >>> 1: I really want a goroutine and its children, but I create new >> >>> goroutines in few enough places that I could do some context mgmt to >> >>> manage this. >> >>> >> >>> -- >> >>> You received this message because you are subscribed to the Google >> >>> Groups "golang-nuts" group. >> >>> To unsubscribe from this group and stop receiving emails from it, send >> >>> an email to golang-nuts+unsubscr...@googlegroups.com. >> >>> To view this discussion on the web visit >> >>> https://groups.google.com/d/msgid/golang-nuts/e2d7e3d7-c678-4515-9cdb-060d29b14500%40googlegroups.com. >> >> >> >> >> >> >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> >> "golang-nuts" group. >> >> To unsubscribe from this group and stop receiving emails from it, send an >> >> email to golang-nuts+unsubscr...@googlegroups.com. >> >> To view this discussion on the web visit >> >> https://groups.google.com/d/msgid/golang-nuts/A1D870A7-ADFD-4F00-B678-E7C6C0FE80FD%40ix.netcom.com. >> >> >> >> >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "golang-nuts" group. >> > To unsubscribe from this group and stop receiving emails from it, send an >> > email to golang-nuts+unsubscr...@googlegroups.com. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/golang-nuts/CANLJsyBF9BezZVYtoFcGCTNYQrTuVVAQoEgBC2CWVRJOxb8P-A%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVknCuT8e8KSwR1VQa%2BQSnBzZ9RUdBLC1PQfAYDVJzPtQ%40mail.gmail.com.
