Hi Marko,
----- 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).
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)
>
> Might as well be the DB layout, size or load as well. In general the
+1
cheers.
--
Nathan
|