[systemd-devel] Improving the results shown with systemd-analyze blame

[Lennart Poettering]

On Sun, 24.11.13 12:44, Umut Tezduyar Lindskog (umut.tezduyar at axis.com) wrote:

> Hi,
> 
> I think we can make the output of systemd-analyze blame more useful with cpu accounting information.
> 
> The output of systemd-analyze blame is not making so much sense when
> lots of programs are tried to be started at the same time since it is
> not known which program actually uses the cpu at any time. My propose
> is saving the cpuacct (if it is enabled of course) information
> throughout service activation and presenting the cpu usage information
> in systemd-analyze blame. We could even present the time it takes to
> activate a service / cpu time that is used to have information about
> overall cpu utilization.
> 
> Thoughts?

What to do about accounting of cgroups is a big open question. In the
long run thre should probably be some infrastructure that allows
integration with RRD tools in one way or another.

In the short-term it probably makes sense to expose some of cgroup
accounting parameters in some minimal way on the bus, and possibly take
a snapshot of them automatically at appropriate times (i.e. when the
state of a unit changes), and all that in a somewhat atomic way.

Maybe something like this could work:

For each Unit with cgroups add four new properties and one new
method. The props are:

    a{sv} InactiveExitAccounting
    a{sv} ActiveEnterAccounting
    a{sv} ActiveExitAccounting
    a{sv} InactiveEnterAccounting

The methods is:

    a{sv} GetCurrentAccounting()

The returned dictionaries would contain the names of a selected few
accounting parameters plus their values. Which ones are included depends
on the existing CPUAccounting, MemoryAccounting, BlockIOAccounting
fields. We'd only include values that according to Tejun are here to
stay.

The properties would reflect the accounting data of the four timestamps
we already take. All values would be normalized, and relative to the
data from InactiveExitTimestamp.

Hope that makes some sense? Would be happy to take a patch!

Lennart

-- 
Lennart Poettering, Red Hat