[systemd-devel] Fwd: CPU time of journal

[Shuang Liu]

Hello developers,

Merry Xmas and happy new year.
I would like to disturb you little bit about the journal behavior.

We are doing some embedded systems with high boot performance requirement.
First, thanks to systemd the startup configuration is no more a
sophisticated job.

Still, we faced some problems with journald in our work.
We found the CPU latency for each log is a bit higher than we expected,
especially when we have thousands of logs during startup, which in fact
delays our early applications during the startup.

In a test, we were continuous logging information using different methods
which journald support, for example syslog.
We found that more than half of the total CPU cycles (from the flame graph
we got) are used by function cg_pid_get_path_shifted(). I am not sure why
this function is little bit too heavy.

This function seems to be used from two places:

The first is to test the journal rate limit. In my understanding, if we
turn off the limit, ie. set it to zero. The function is not needed to be
called. In fact the check whether it is disabled comes later, which makes
the function cg_pid_get_path_shifted() still being called. Maybe just by
preponing the check we could economize CPU cycles.

The second is to collect the metadata, especially the cgroup information.
We've tried to bypass the function in this part of source code and are able
to accelerate the startup.

One effect is that we lost some metadata in the journal, like _COMM= _EXE=
_CMDLINE= _SYSTEMD_CGROUP= _SYSTEMD_UNIT= _SYSTEMD_SLICE=
These information are not critical in our project setting thus we can
accept the loss of these data.

I would like to get advice from you, If there are any other risks, from
which we may get into trouble.

And maybe it is an option if we could have an option in the runtime
configuration to select which kind of metadata are required to avoid
unnecessary latency.

Thanks for any hints.

Regards
Шуангистан
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20161220/d95a36c8/attachment.html>