[Mono-list] Determine what's using CPU

[David Evans]

I think the kill -QUIT stack dump shows you all managed stacks with managed stack traces, but may omit native stacks like the GC marker threads and finalizer thread. If you have a 16 processor or equivalent, it's likely you'll get 15 marker threads and 1 finalizer thread. So that would explain your missing 16 threads. But if you attach with gdb to the process and "info threads" you should see all 20 and can probably deduce which are the GC threads based upon their stack traces pretty easily.

Cheers

From: Dave Curylo [mailto:dacurylo at gmail.com] On Behalf Of Dave Curylo
Sent: Tuesday, April 09, 2013 3:39 PM
To: David Evans
Cc: mono-list at lists.ximian.com
Subject: Re: [Mono-list] Determine what's using CPU

Yes, I meant that top -H was showing me several ~20 threads for my process (I could spot them right away since it's the only process running mono-sgen), but the stack dump only listed 4.  Are the rest just idle in the thread pool or something so they aren't shown?

On Apr 9, 2013, at 4:37 PM, David Evans wrote:

top shows you all processes and their threads by default. If you'd like to constrain it to only show you information about a particular process then that is an option too. In linux -p with the process id should restrict output to just that process. Or when listing threads it will then only show you threads within that process. There are some other options to customize top output if you dig into the docs but probably that's all you need.

From: Dave Curylo [mailto:dacurylo at gmail.com] On Behalf Of Dave Curylo
Sent: Tuesday, April 09, 2013 10:55 AM
To: Rodrigo Kumpera
Cc: David Evans; mono-list at lists.ximian.com<mailto:mono-list at lists.ximian.com>
Subject: Re: [Mono-list] Determine what's using CPU

Thanks Rodrigo and David, this was helpful, this points me to code that could be the issue.  One concern, though, when I use kill -QUIT, my stack dump only shows 4 threads, but when I use top -H, I see many more (about 20).  Where are the rest of the threads listed?

On Apr 9, 2013, at 12:41 PM, Rodrigo Kumpera wrote:



You can try to use kill -QUIT to ask mono to produce a full stack dump to stderr.

On Tue, Apr 9, 2013 at 12:14 PM, David Evans <devans at pacificbiosciences.com<mailto:devans at pacificbiosciences.com>> wrote:
I usually use "top -H" to get the thread id of the thread that is hogging the CPU. Then I use "top" to get the process id, then connect to that process using gdb and use "info threads" to find the thread number for the thread id that was hogging the CPU. Then I switch to that thread and back trace to see what it's doing, sometimes continuing and breaking a few times as a poor man's sample of different stack traces for what it's doing.

There are probably better ways of doing this, but that's the simple approach I've used with gdb.

-----Original Message-----
From: mono-list-bounces at lists.ximian.com<mailto:mono-list-bounces at lists.ximian.com> [mailto:mono-list-bounces at lists.ximian.com<mailto:mono-list-bounces at lists.ximian.com>] On Behalf Of Dave Curylo
Sent: Tuesday, April 09, 2013 8:20 AM
To: mono-list at lists.ximian.com<mailto:mono-list at lists.ximian.com>
Subject: [Mono-list] Determine what's using CPU

I have a process that sporadically becomes unresponsive and starts using a lot of CPU.  Before I thought this was a GC issue, and switched to sgen, but the issue is still there.  I've use gdb with "thread apply all bk" in the past, which pointed me to the GC issues, but now it appears GC isn't really the problem.  Is there some other way to see what is causing the high CPU in gdb or is my only option to start the process with the mono profiler attached?
_______________________________________________
Mono-list maillist  -  Mono-list at lists.ximian.com<mailto:Mono-list at lists.ximian.com> http://lists.ximian.com/mailman/listinfo/mono-list
_______________________________________________
Mono-list maillist  -  Mono-list at lists.ximian.com<mailto:Mono-list at lists.ximian.com>
http://lists.ximian.com/mailman/listinfo/mono-list



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-list/attachments/20130409/acce45dd/attachment.html>