On Fri, Apr 21, 2017 at 5:22 PM <lesm...@gmail.com> wrote: > Managed to find time to run it quickly before the end of UK time... > > gc 62 @368.812s 3%: 0.027+770+0.070 ms clock, 0.054+188/386/412+0.14 ms > cpu, 467->485->250 MB, 495 MB goal, 2 P > gc 63 @375.551s 3%: 0.041+0+360 ms clock, 0.082+188/386/412+720 ms cpu, > 393->393->238 MB, 393 MB goal, 2 P (forced) > > rlh@ is the official authoritative source here, but I have a hunch about the above:
Somewhere in the program, you are calling runtime.GC(). Its documentation says it may block the entire program. If you look at gc 63, it is forced, which means it is a call to runtime.GC(). It also spends 360ms in mark termination compared to 0.070 for a normally invoked GC. One possible venue is to remove your own forced GC calls and let the runtime itself manage them and then look if that helps the programs behavior w.r.t. stalls. The 3% spent in the collector suggests you have good productivity in the mutator. And every forced GC has a long pause, which coincides with your original graph. Note that the decision to make the runtime.GC() call may be a couple of releases old, when the behavior of that call was different. So you can have hit a situation where a good decision then is a bad decision now. -- 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. For more options, visit https://groups.google.com/d/optout.
