Re: CPU Usage in running process on HP-UX 11.31
- From: Tanel Poder <tanel@xxxxxxxxxx>
- To: Stefan Knecht <knecht.stefan@xxxxxxxxx>
- Date: Wed, 9 Sep 2009 16:35:19 +0800
Hi Stefan,
Yep, no objections here.
Production and debuggers usually don't go together unless you already have a
bad problem happening and you know exactly what you're doing. Also you would
have to be fast as you may unentionally suspend the process while it's
holding a latch or some critical lock. And I definitely stay away from
critical background processes, both with debuggers and undocumented events.
I even think twice before enabling plain old SQL trace for a background
process as its not a very common thing to do, thus results in less tested
code paths.
In original mail you asked for some events for dispatcher tracing, there is
such event:
10248, 00000, "turn on tracing for dispatchers"
// *Cause:
// *Action:
BUT - I have never used it nor seen anyone using it, so enabling this would
be much more riskier than getting stack traces with a debugger, as we don't
have an idea how this event affects dispatcher code execution.
There's third way btw, if youre interested, drop me a mail offline.
Tanel.
On Wed, Sep 9, 2009 at 3:59 PM, Stefan Knecht <knecht.stefan@xxxxxxxxx>wrote:
> Thanks for the input ...
>
> Andrew: We're way past this already. The system has been running stable and
> well performing for a long time (using dedicated servers). Lately, due to
> increasing number of users we've been running out of memory. Hence, shared
> servers were turned on. And now we're running low on CPU due to the
> dispatchers eating it all up. (before switching to shared server, CPU usage
> was constantly at about 50%).
>
> Tanel: You're right. However, we're on PA-Risc and pstack isn't available
> there. So I suppose we have to use a debugger to get that information. And
> I'm a bit reluctant to attach to a running process in production with a
> debugger.
>
> Cheers
>
> Stefan
>
> =========================
>
> Stefan P Knecht
> CEO & Founder
> s@xxxxxxxx
>
> 10046 Consulting GmbH
> Schwarzackerstrasse 29
> CH-8304 Wallisellen
> Switzerland
>
> Phone +41-(0)8400-10046
> Cell +41 (0) 79 571 36 27
> info@xxxxxxxx
> http://www.10046.ch
>
> =========================
>
>
> On Tue, Sep 8, 2009 at 5:11 PM, Andrew Kerber <andrew.kerber@xxxxxxxxx>wrote:
>
>> Can you tell what the CPU is doing? Is your library cache hit rate low,
>> for example? This might indicate a lot of time spent parsing...
>>
>>
>> On Tue, Sep 8, 2009 at 9:56 AM, Tanel Poder <tanel@xxxxxxxxxx> wrote:
>>
>>> tusc -c should be able to do what strace -c does on linux.
>>>
>>> However these tools do something different what pstack and stack
>>> profilers do. Tusc and strace only show you *system call* information,
>>> but your problem may not be in system calls but just excessive CPU usage in
>>> user mode. A stack profiler will show you which codepath takes the most of
>>> time in an executable.
>>>
>>> Tanel.
>>>
>>>
>>> On Tue, Sep 8, 2009 at 8:29 PM, Stefan Knecht
>>> <knecht.stefan@xxxxxxxxx>wrote:
>>>
>>>> Hi Tanel
>>>>
>>>> Good point! I was hoping there was a tool that would do that for me ...
>>>> Similar to what strace -c does on linux :-)
>>>>
>>>> I'll take a look at that
>>>>
>>>> Cheers
>>>>
>>>>
>>>>
>>>>
>>> --
>>> Tanel Poder
>>> http://blog.tanelpoder.com
>>>
>>>
>>
>>
>> --
>> Andrew W. Kerber
>>
>> 'If at first you dont succeed, dont take up skydiving.'
>>
>
>
--
Tanel Poder
http://blog.tanelpoder.com
Other related posts:
