pcp
[Top] [All Lists]

Re: Oracle connection debugging (was Re: [pcp] Handling Oracle PMDA Late

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: Oracle connection debugging (was Re: [pcp] Handling Oracle PMDA Latencies)
From: Marko Myllynen <myllynen@xxxxxxxxxx>
Date: Mon, 23 May 2016 11:51:42 +0300
Cc: pcp developers <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <594283644.49214956.1463982724891.JavaMail.zimbra@xxxxxxxxxx>
Organization: Red Hat
References: <56F25541.9020602@xxxxxxxxxx> <57175FC8.2000600@xxxxxxxxxx> <1558022602.42320984.1461208897951.JavaMail.zimbra@xxxxxxxxxx> <57395F04.2090909@xxxxxxxxxx> <1695396289.47966126.1463381940778.JavaMail.zimbra@xxxxxxxxxx> <573D897A.5070804@xxxxxxxxxx> <626822210.48972762.1463726815586.JavaMail.zimbra@xxxxxxxxxx> <573EDF38.1020102@xxxxxxxxxx> <594283644.49214956.1463982724891.JavaMail.zimbra@xxxxxxxxxx>
Reply-to: Marko Myllynen <myllynen@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
Hi,

On 2016-05-23 08:52, Nathan Scott wrote:
> ----- Original Message -----
>> On 2016-05-20 09:46, Nathan Scott wrote:
>>> ----- Original Message -----
>>>> [...]
>>>>> I wonder if the best we can do here is something like:
>>>>> - disable these two clusters by default
>>>>> - add oracle.control metrics for each
>>>>> - add pmstore support to allow people to opt-in to these clusters.
>>>>
>>>> But if opting in for these means that the timeout is hit pretty much
>>>> guaranteed, not sure what's the point then?
>>>
>>> The point was to give you a working agent (with all the other metrics).
>>>
>>> The agent is working fine for "everyone" else ... (although thats a small
>>> set at this stage, I suspect).
>>
>> I think this is one of the larger setups tested so far. I mentioned that
>> e.g. for oracle.object_cache the select query returned over 220k rows
>> here, how many rows it returns on your test setup?
> 
> I no longer have access to the large system from the perf folk here.  But,
> on my laptop with a default Oracle install, there's ~8K rows there - when
> fetching that it takes 0.05 seconds (elapsed time).  So yep its definitely
> feasible that 220k will take ~1.3 seconds (approx linear).

Yes, I presume (even after seeing your follow-up email) that size/layout
has something to do with this but since this is a view it's hard to know
exactly what happens internally when doing this query. (But as mentioned
the system in general is pretty well optimized so I don't think it can
be because of some missing OS/Oracle patch or such.)

> This doesn't equate to that many metrics/instances, so perhaps some cunning
> query rewriting there could solve that aspect, and could get us most of the
> way home here.  (would involve rewriting the object_cache_values() function
> in pmdaoracle.pl)

The queries are like:

echo 'select file#, phyrds, phywrts, phyblkrd, phyblkwrt, readtim,
writetim from v$filestat;' | sqlplus scott/tiger@orcl

Querying any of the columns individually takes pretty much the same time
so I can't see how to improve this. Thus your suggestion to make these
two clusters opt-in is probably the most feasible solution at least in
the short-term. Here oracle.object_cache will be ignored but I can try
to see how things work after enabling oracle.file.

Thanks,

-- 
Marko Myllynen

<Prev in Thread] Current Thread [Next in Thread>