Re: CPU Usage in running process on HP-UX 11.31

From: Tanel Poder <tanel_at_poderc.com>
Date: Wed, 9 Sep 2009 16:35:19 +0800
Message-ID: <4602f23c0909090135x6d4600few261caa1d244a4238_at_mail.gmail.com>



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_at_gmail.com>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_at_10046.ch
>
> 10046 Consulting GmbH
> Schwarzackerstrasse 29
> CH-8304 Wallisellen
> Switzerland
>
> Phone +41-(0)8400-10046
> Cell +41 (0) 79 571 36 27
> info_at_10046.ch
> http://www.10046.ch
>
> =========================
>
>
> On Tue, Sep 8, 2009 at 5:11 PM, Andrew Kerber <andrew.kerber_at_gmail.com>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_at_poderc.com> 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_at_gmail.com>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

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Sep 09 2009 - 03:35:19 CDT

Original text of this message