[systemd-devel] systemd-journald process footprint
Lennart Poettering
lennart at poettering.net
Fri May 25 08:42:11 PDT 2012
On Thu, 24.05.12 19:25, Sergey Lapin (slapinid at gmail.com) wrote:
Servus!
> I run Linux embedded system with quite tight resources. We
> successfully use systemd for some time, but with introduction of
> journald we get show-stopper problems, preventing us from upgrade to
> newer systemd, to get functionality we need and bugs fixed.
>
> A problem is that journald is most resource-consuming process on
> device, it eats most of RAM and most of CPU. For comparison if we run
> rsyslogd on journald's pipe, its footprint is 10 times smaller, than
> journald's.
I think this is mostly a misunderstanding.
How precisely did you measure memory usage of journald?
The journal files are mmap'ed into the address space of journald, but
journald keeps very little heap of its own around. This basically means
that the address space usage of journald is very large while the actual
heap used is very small. However, address space costs virtually nothing,
only actual memory usage does.
Confusion about actual memory usage vs. address space usage is quite
common in the Linux world, so please make sure not to misunderstand
this.
Regarding CPU consumption: journald doesn't do much stuff really,
nothing that should be CPU intensive, unless you use XZ compression and
artificially lowered the object size threshold for this.
How did you profile this?
> So questions are:
> 1. is it possible to run systemd the "old way", so without journald,
> with all logging to normal syslog()?
> If it is not possible as is, how hard is to patch systemd to work like
> this, any pointers?
No, this is not supported, but we will probably introduce a mode where
you can turn off logging to the file system in favour to a direct
forwarding to kmsg only. But again, I am pretty sure this is mostly just
confusion of address space footprint vs. actual memory footprint.
Lennart
--
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel
mailing list