Lee, As far as I can tell this is resolved. Thanks for the discussion and for working with stackimpact to fix the root cause.
On Friday, April 21, 2017 at 3:52:55 PM UTC-4, Keith Randall wrote: > > It is almost never a good idea to call runtime.GC explicitly. > It does block until a garbage collection completes. This behavior is > sometimes useful in tests, but almost never otherwise. If it weren't for > go1 compatibility, we'd rename this function to something that more clearly > spells out its blocking behavior. > > On Friday, April 21, 2017 at 11:51:17 AM UTC-7, Lee Armstrong wrote: >> >> Interestingly stackimpact.com just updated their code to remove the >> runtime.GC() calls. >> >> It has made a HUGE difference to the GC pauses. >> >> The code was updated just before 19:30. >> >> Interesting that the manual call had such an impact! >> >> >> <https://lh3.googleusercontent.com/-Cfl2uxAbqSk/WPpUa3aDMZI/AAAAAAAA-3k/_g3b1RZp6MYuBOSbeUHlBRbeFTaqeQTKQCLcB/s1600/2017-04-21_19-44-20.png> >> >> >> On Thursday, April 20, 2017 at 2:49:49 PM UTC+1, Lee Armstrong wrote: >>> >>> See attached graph which shows the GC pauses of an application we have. >>> >>> I am frequently seeing pauses of 1-1.5 seconds. This is using Go 1.8.1 >>> and have a large map that is frequently accessed and items are removed and >>> added to it. These can be of some size. >>> >>> Is there a way to get these pauses down at all? Would forcing a GC() >>> after removing a batch of elements help at all? >>> >>> Alongside the pauses I see some substantial CPU usage showing up in >>> traces for the GC scan. >>> >>> Thanks in advance! >>> >> -- 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.
