[systemd-devel] Excessive (virtual) memory usage of journald
Holger Hans Peter Freyther
holger at freyther.de
Wed Jun 26 12:58:36 PDT 2013
On Fri, Jun 21, 2013 at 06:01:08PM +0200, Holger Hans Peter Freyther wrote:
> Do you have an idea on how this could be done?
first of all the MMAP cache is not why journald is slow but that is
for another mail/benchmark. I was just curious if the mmap cache is
premature optimization or if it brings a speed up.
So what I did was to patch journal-file.c, mmap_cache.c and record
the calls made to posix_fallocate, fstat and mmap_cache_get and write
the parameters to a file.
I created a small tool to replay these operations. This way I can
play with the mmap_cache.c and see if my changes make a difference. I
am attaching my hacked together patch as a reference. The journald will
exit when it would normally rotate the log file.
This was tested on a TI Davinci DM644x. The ARM core runs at 405 Mhz
and the system has 256 mib DRAM. It is running Linux 3.2.40, the userspace
is post Poky 9.0.0 (glibc 2.17, gcc 4.7..)
I was using the following to generate log messages as my example
workload. This resulted in a 19MB file with commands.
(for i in `seq 1 100`;
do echo "Log message... $RANDOM";
done) | logger;
Baseline replay with just iterating over the commands:
root at sysmobts-v2:~# time ./replay-mmap-cache-no-work
Replay with WINDOWS_MIN 64 (just the best, lowest)
root at sysmobts-v2:~# time ./replay-mmap-cache-min-64
Replay with WINDOWS_MIN 0 (just the slowest)
root at sysmobts-v2:~# time ./replay-mmap-cache-min-0
So unless there is an issue with my recording/replay I think that
besides my opinion that mapping a < 4MB file 65 times is ugly, it
also appears to be slower for the above workload in journald.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 9591 bytes
Desc: not available
More information about the systemd-devel