Ken,
I can go down that path if that is the right way to do it. But I was
hoping for some sort of "log this list of metrics right now, just once,
but don't otherwise change pmlogger" command.
Thanks for the insight Martins.
Well this is truly interesting. Your use case is something that has
not previously been encountered in over a decade of belting PCP in
production environments. I find that both surprising and exciting.
Ha!
I can't see a way to achieve what you want with the single pmlogger
process and the capabilities today. This is because the log mandatory
pmlc command updates the logging state for all the named metrics
within pmlogger, so what you describe is what I'd expect to happen.
The options are:
1. extend pmlc and pmlogger to have an additional set of metrics that
can have duration and logging state that co-exists with the config
file ones at startup (so the state change from pmlc is independent of,
not a replacement of, the original state) ... it would be nice to have
some short hand notation for turning all of these additional metrics
off in one command and extend the "once" duration to allow N times.
2. Have your script that is currently calling pmlc actually launch a
_new_ pmlogger to capture just the metrics you want at the start or
end of the computation or with some particular frequency during the
computation. Then at the end of the day, you can use pmlogextract to
merge together the archive from the default system logging (or
whatever pmlogger you're pointing pmlc at) with one or more archives
from your computation runs. The merged archive will be the same as if
1. was implemented.
Thanks for the ideas. I'll work on 2 for now and test 1 as it evolves.
Thanks
Martins
|