You might have a ticker leak. Check that you're not accidentally calling time.NewTicker in a loop. Get a pprof heap dump and look for time.NewTicker objects. The total size of them should not be large. If it is, then you have a ticker leak.
On Tuesday, 13 November 2018 at 15:26:29 UTC+1 Anon wrote: > Hi Ian, > > I am facing the same issue. The CPU usage on my servers increases from > very low to 100% of CPU. Did you find the solution to your problem? > > go version : 1.10.1 > OS : centOS > > Thanks, > > > On Thursday, January 31, 2013 at 7:27:33 AM UTC+5:30, Ian Ragsdale wrote: >> >> Thanks Dave, those look like great suggestions. I'm running Go 1.0.3 on >> Ubuntu: >> >> # go version >> >> >> go version >> go1.0.3 >> >> # uname -a >> Linux 4bf343d4-786f-4fa6-b37c-8bdd018fc63b 2.6.32-350-ec2 #57-Ubuntu SMP >> Thu Nov 15 15:59:03 UTC 2012 x86_64 GNU/Linux >> >> I'll work on gathering the SIGQUIT & GOGCTRACE output - didn't know about >> those techniques. I can't really share the source, and I'm not sure if >> there's a good way to cut it down to a sharable chunk, but I'll give it a >> shot. Strace was going to be my next move. >> >> I think your theory in general makes sense, as I'm familiar with that >> kind of failure, but if that was the case, would it not immediately shoot >> up to 100% cpu usage as soon as the problem occurred? In this situation, >> the cpu usage creeps up quite slowly, in a nearly perfect linear fashion >> over the course of many hours. >> >> - Ian >> >> On Jan 30, 2013, at 4:00 PM, Dave Cheney <da...@cheney.net> wrote: >> >> >> Can you please provide the following details >> >> * your Go version and operating system details >> * the full output from the process when sent a SIGQUIT, once it entered >> the high CPU usage scenario. >> * the full output from running the process with GOGCTRACE=1 as above. >> * the source, I possible, or at least a sample that reproduces the issue. >> * if you are using Linux, try running the process under the perf(1) tool. >> * if you able, try running the process under strace(1). >> >> My gut feeling is your code, or a library is not checking an error code >> from a socket operation and entering into a tight loop. If this is the case >> temporarily breaking the networking on this host may induce the failure. >> >> >> >> > ::DISCLAIMER:: > > > ---------------------------------------------------------------------------------------------------------------------------------------------------- > > > This message is intended only for the use of the addressee and may contain > information that is privileged, confidential and exempt from disclosure > under applicable law. If the reader of this message is not the intended > recipient, or the employee or agent responsible for delivering the message > to the intended recipient, you are hereby notified that any dissemination, > distribution or copying of this communication is strictly prohibited. If > you have received this e-mail in error, please notify us immediately by > return e-mail and delete this e-mail and all attachments from your system. > -- 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/f517f60a-50cd-4a87-b552-ec02e991fd53n%40googlegroups.com.
