Thanks for getting back to me. I have posted the output from a 30-second
runtime/trace session here, which appears to show three 80ms GC's:
https://www.dropbox.com/s/wc3hp6k17txaofh/staging-trace.tar.gz?dl=0
I'm struggling a bit to interpret what's there though.
On Thursday, February 23, 2017 a
, Thu 16:18
To: Austin Clements; Oliver Beattie
Cc: golang-nuts
Subject: Re: [go-nuts] Debugging long GC pauses
What would happen if you inserted a dummy function call inside the
non-preemptible loop and made an appropriate sacrifice on the altar of the SSA
dead-code-eliminator so it doesn&#
What would happen if you inserted a dummy function call inside the
non-preemptible loop and made an appropriate sacrifice on the altar of the
SSA dead-code-eliminator so it doesn't trigger?
On Thu, Feb 23, 2017 at 8:46 PM 'Austin Clements' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
>
AFAIK, the only thing that can cause this in Go 1.8 is a non-preemptible
loop. It's not related to the heap size at all.
To test this theory, you can set GOEXPERIMENT=preemptibleloops and rebuild
your Go tree (the compiler has to be built with this, so you can't just
turn it on to build your proje
+rlh, austin
Interesting behavior. I would recommend filing a bug. It would be most
helpful if you can create a complete repro case including either the
production code or some minimization of it that demonstrates the same
pauses.
On Thu, Feb 23, 2017 at 10:46 AM, Oliver Beattie wrote:
> I am lo
I am looking for some advice about how I can debug some long GC pauses I am
observing in our production workloads under go 1.8 (the problem is not
specific to 1.8, though). This is a very simple network server – basically
a HTTP ping endpoint – but I regularly see tail request latencies of
>100
