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

From: Stefan Knecht <knecht.stefan_at_gmail.com>
Date: Tue, 8 Sep 2009 14:29:58 +0200
Message-ID: <486b2b610909080529s1cee8e25x438f0cef9eed7114_at_mail.gmail.com>



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


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 2:09 PM, Tanel Poder <tanel_at_poderc.com> wrote:

> You need to do stack profiling on your dispatcher process for understanding
> in which Oracle functions most of time is spent. Then you can send the top
> stacks to Oracle support and they can search their internal knowledge bases
> based on that.
>
> You can use pstack for getting a bunch of stack traces and aggregate them
> with an awk script or use HP's Caliper tool for doing the call graph
> aggregation for you.
>
> This all is of course if you have narrowed the issue down to dispatcher
> (and dispatcher only), otherwise regular Oracle troubleshooting techniques
> should be used first.
>
> Tanel.
>
>
>
> On Tue, Sep 8, 2009 at 4:48 PM, Stefan Knecht <knecht.stefan_at_gmail.com>wrote:
>
>> Ciao Martin
>>
>>
>> On Tue, Sep 8, 2009 at 10:17 AM, Martin Berger <martin.a.berger_at_gmail.com
>> > wrote:
>>
>>> Hi Stefan,
>>> so I'm prety sure you know these 2 ML-notes:
>>> Subject: *Multi-Threaded Server (MTS) Trace Events* Doc ID<https://metalink2.oracle.com/help/usaeng/Search/search.html#file>:
>>> *106624.1*
>>> *Subject: MTS: How to Debug a Hanging Multi-Threaded Server Connection
>>> Doc ID<https://metalink2.oracle.com/help/usaeng/Search/search.html#file>:
>>> 106621.1*
>>>
>>>
>> Yep, I'm aware of those. Unfortunately they don't ehlp in this case.
>>
>>
>>> If a tusc trace did not give any hints, the next step would be attaching
>>> a debugger to the process. But this is of realy limited use; even if you
>>> know which CPU-commands it's using all the time, of which loops are
>>> spinning, you can hardly find the reason without the source-code and
>>> debug-hooks prepared in the binary.
>>>
>>> Yes, problem is that even tusc slows down the process quite massively.
>> And since we only experience the issue in production, we can't really use
>> any even more intrusive tools. I was merely hoping HP-UX provides some new
>> hooks in the release 3 kernel that are not yet widely known, that allow for
>> measurign those things (analogous to i.e. dtrace on sun).
>>
>> Just some tries to get a lucky hit:
>>> As users has not changed, has anything else changed?
>>>
>>
>> Nope, not that I'm aware of, nor did the apps guys claim any changes
>>
>>
>>> OS-patched?
>>>
>> Nope
>>
>>
>>> network subsystem? (new switches, now network card new drivers, new
>>> team?)
>>>
>> Nope
>>
>>
>>> io-subsystem?
>>>
>> Some new disks were added to ASM. However, we don't experience any storage
>> issues.
>>
>>
>>> clients?
>>>
>> Nope
>>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Sep 08 2009 - 07:29:58 CDT

Original text of this message