I've started implementing a Performance CoPilot* PMDA**, so that we can
collect all the metrics from "unbound-control stats_noreset" together
with other system performance metrics, and view the performance
numbers both realtime and collect historically. Example screenshot of
pmchart visualizer showing some live unbound and cpu performance metrics: http://tanso.net/pcp-unbound.png
So, this PMDA is now running "unbound-control stats_noreset" every second,
which seems a bit excessive maybe, but is there any reason to be carefull
with how often we call stats_noreset? Or are there any more efficient
way of polling these numbers if stats_noreset is unadvicable?
I've started implementing a Performance CoPilot* PMDA**, so that we
can collect all the metrics from "unbound-control stats_noreset"
together with other system performance metrics, and view the
performance numbers both realtime and collect historically. Example
screenshot of pmchart visualizer showing some live unbound and cpu
performance metrics: http://tanso.net/pcp-unbound.png
So, this PMDA is now running "unbound-control stats_noreset" every
second, which seems a bit excessive maybe, but is there any reason
to be carefull with how often we call stats_noreset? Or are there
any more efficient way of polling these numbers if stats_noreset is
unadvicable?
Unbound will briefly poll the other threads over the internal pipes to
collect the information and thread-0 is busy answering this data over
the control connection. Other than that, once per second should work
fine. I would personally recommend a lower polling rate, but it
should work.
For NSD (which you did not mention), this would be a problem, and you
would need to upgrade to the latest version to get a repeated-fork-fix
that stops (Linux-)system performance degrade after millions of fork
operations.
Unbound will briefly poll the other threads over the internal pipes to
collect the information and thread-0 is busy answering this data over
the control connection. Other than that, once per second should work
fine. I would personally recommend a lower polling rate, but it
should work.
Ok, great! It turned out that PCP won't be polling at all by defalt,
it's the client tools that are triggering the polls. So we'll likely
limit automated polls to once every 10 seconds or longer.
For NSD (which you did not mention), this would be a problem, and you
would need to upgrade to the latest version to get a repeated-fork-fix
that stops (Linux-)system performance degrade after millions of fork
operations.
Thanks for the heads up! We're not currently running NSD, but it's stuff
like that I was worried about.
