HI Ian,
We don't need to set MemProfileRate. It is about block and mutex profiling
where we need to set the rate (SetBlockProfileRate,
SetMutexProfileFraction) at application start. Is there any performance
impacts of doing that ?
It is not causing any issue we want to enable block and mutex profiling so
i am thinking if we can do something like
SetBlockProfileRate(1)
pprof.Lookup("block").WriteTo(f, 0);
sleep(20)
SetBlockProfileRate(0)
just like how cpu and trace profile works. But i am curious why isn't it
not already done in the library. What can be the reason behind this?
I am curious why they are different from cpu and trace profiling, trying to
understand the inner working of this. It would be really helpful if you can
give me some pointers on where i can read about the high level design of
the pprof.
Thanks
On Sun, Oct 20, 2019 at 2:44 AM Ian Lance Taylor <i...@golang.org> wrote:
> On Fri, Oct 18, 2019 at 11:03 PM Nidhi Agrawal <nidhi11...@gmail.com>
> wrote:
> >
> > Golang runtime profiler (for cpu & trace) gives us an option to decide
> the time of profiling. It then sets the rate of profiling at start of the
> call and reset the rate at the end of the call. So it goes like this
> >
> > CPUProfiling() {
> > StartCPUProfile() // internally calls SetCPUProfileRate(100)
> > sleep(seconds)
> > StopCPUProfile () // internally calls SetCPUProfileRate(0)
> > }
> >
> > On the other hand for mutex and block profiling, it expects us to set
> the rate at the start of the application and while calling profiling, it
> just gathers the information and return.
> > My doubt is why mutex and block profiling have different behaviour ?
> Here also we could have set the rate at call start and reset at call end
> with some sleep time.
>
> The two kinds of profiling work differently. Memory profiling is
> based on sampling allocations as determined by runtime.MemProfileRate.
> Adjusting that on the fly won't give you reasonable results, because
> of how the profiling tools handle the data. Changing this would
> require some mechanism to tell the tools when MemProfileRate changes,
> and we don't have a way to do that.
>
> Is this causing a problem?
>
> Ian
>
--
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/CACcVEiXW1J8iax-tmLwov8uASpf_g%3DOi%2BCLWaLv-0PjV7tFq5g%40mail.gmail.com.
