OK, dropping mem.slabinfo.objects.total from the kernel/summary-linux
group reduces the daily log size on my desktop (with a 15sec logging
interval, so 4 times the default) to 19 Mbytes, 11 of which are still
the kernel/summary-linux group.
Looks like the mem.util.* group is the next candidate for a diet ... is
there a subset of the 50 metrics in there that are _really_ useful in
your production environment?
Also in the filesys/summary group we're logging
filesys.full
filesys.used
filesys.free
filesys.avail # for Linux
which seems a bit over the top ... I'd guess that the only information
really worth logging in a summary group ("on" for everyone by default)
would be filesys.full ... so we can either trim the filesys/summary
group, or change it to be available rather than enabled, and add
filesys.full to the kernel/summary-* groups (I'm inclined to vote for
the latter approach).
I'd be keen to hear from anyone else with a view on what information we
should be including in the default "on" set of metrics if one was to use
pmlogconf to generate the pmlogger config file.
On Mon, 2010-06-21 at 11:37 +1000, Nathan Scott wrote:
> ----- "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx> wrote:
>
> > I think this is me done.
> >
> > Nathan, is the slabinfo metric spec you sent me correct? I do not see
> > a dentry_cache instance ...
> >
> > pminfo -f mem.slabinfo.objects.total | grep dentry
> > inst [63 or "dentry"] value 114660
>
> Its correct for the kernels in RHEL4 and RHEL5 ... (which are up to
> 2.6.18+rhel-patchfest). Looks like that cache was renamed in some
> kernel since then though.
>
> > If we turn on the kernel/summary-linux group (as is done at the
> > moment
> > in this commit) there are 64 metrics here, and on my lame laptop this
> > group dominates the daily archive size with 12 Mbytes ... I think
> > that
> > may be too big for something that is going to be enabled by default.
>
> *nod*. Theres scope for trimming there (all slab info would be a start,
> side-stepping the dentry cache name issue)
>
> > Check the pmda directories and the pmlogconf man page to see how new
> > components can plug into this new infrastructure.
> >
> > This is all new, and so there is a lot of guessing going on here ...
> > please let me know if you have suggestions for improving the metric
> > coverage, the probe predicates or the default state assignments.
>
> Great, thanks Ken!
>
> cheers.
>
|