On 15/01/14 10:00, Nathan Scott wrote:
...
How does the order of the config file blocks impact on "how much is logged"?
So, each config file block == a separate task_t, each separate
task_t == at least one pmFetch (and hence pmResult). Before
Franks commit, even exactly-duplicated metric names in different
blocks were fetched and logged twice (usually within a few usec
of each other).
OK, I agree metric replication in multiple config blocks produces
additional and unhelpful data in the archives.
But re-ordering a set of config blocks does not change how much is
logged ... I think this is a wording issue not a concept mismatch.
...
Right & I do :) - there does still come a point where it would make sense
to split, as we approach the PDU_SIZE limit for pmcd requests. I suspect
the optfetch code is not taking that into account yet though? - but it is
something we may need to do at some point. So, keeping the ability to
split fetches sounds useful - mostly I'm thinking about tweaking pmlogger
further at this stage though (mental note made to come back to optfetch,
too, and investigate further).
OK and good luck with optfetch .. we know who wrote that code, and let
me only say that optfetch was the warm-up exercise before the interp.c
main game!
One thing you'll have to watch in the pmlogger change is that the -r
option will no longer work ... this very useful option reports archive
size projections based on the config block and does not enumerate all
the metrics in the block in the report ... you'll need to change this to
report per task_t and list all metrics in the pmFetch (as the rationale
here is to be able to tune the config file if the archives are becoming
too large) ... if you get too aggressive with rolling config blocks into
a small number of task_t's this won't be possible, or the report will
have to be per metric (which may be a better idea anyway). Probably
needs some sleep and think time on this, rather than design on the fly.
|