[systemd-devel] High CPU usage of journald

[Lennart Poettering]

On Mon, 18.02.13 08:00, Holger Freyther (holger at freyther.de) wrote:

> Cristian Rodríguez <crrodriguez <at> opensuse.org> writes:
> 
> Good Morning Cristian,
> 
> > Why should systemd stop using standard IO functions to please some 
> > obscure, out of the ordinary need?
> 
> Could you please clarify obscure? So any embedded device that prints
> a couple of log messages on start of an application is obscure in your
> opinion? It is obvious from the perf output I posted that journald's

Well, to be fair: if an app just prints a "couple of log messages", then
the functions you point out should hardly matter... Optimize inner
loops, not just the stuff that happens to be called a "couple of"
times...

> performance is determined by the malloc operations. If the maintainers
> think that the main purpose of journald is to allocate memory then I am
> happy to continue to use the busybox syslogd.

No, the purpose of journald is not to allocate memory. It's primary
purpose is actually to collect sarcastic comments by people. We thrive
on that...

> > If libc behaves in a way you dont like or want, you will have to send 
> > your complains to libc developers..
> 
> Well, there are various things a libc implementation needs to do that
> should not matter to systemd (e.g. thread safety, io cancellation,
> re-entrancy, locking, ...). From the backtraces I posted only a fraction
> of the allocations are coming from libc.

To clarify this: I can totally see value reducing the malloc()s in an
inner loop call such as dispatch_message_real(). 

Does this mean I will now optimize them all away for you? No, not
really, I don't even have the appropriate hardware to profile this. Does
this mean I will merge good patches that optimize this? Hell, yes!

(BTW, it might delight you to know that the client side of all this --
which is similar in style generally --, in journal-send.c actually
avoids malloc()s almost completely -- there's only one left, since I
couldn't come up with any nice way to avoid it. I carefully made sure
of that -- but not really because for performance reasons but simply to
avoid that we'd have to deal with OOM, and so that the OOM message
itself would still be printable...)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.