[systemd-devel] journald leaking maps?

[Lennart Poettering]

On Fri, 12.10.12 20:55, Michael Olbrich (m.olbrich at pengutronix.de) wrote:

> > Well perhaps, but with systemd 189 (I think, perhaps a bit earlier) I
> > certainly didn't see this kind of memory usage. I'm certainly hitting
> > OOMs much more regularly now unless I restart systemd occasionally.
> > 
> > Also, that explanation doesn't really explain:
> > 
> > 
> > [root at jimmy ~]# cat /proc/$(pidof systemd-journald)/status | grep Vm
> > VmPeak:	 6611116 kB
> > VmSize:	 6611112 kB
> 
> I've tried to flood the journal with messages for a while now. VmPeak is
> stable and VmSize grows until it reaches VmPeak and the drops
> significantly.
> This looks like some limit is reached and then journald releases most of
> its memory.

Internally mmap-cache.c will maintain up to 64 maps in total. If that
limit is reached, or if mmap() returns ENOMEM we'll free some maps, and
try again. 

> What I think happens for you is the following:
> For some reason, journald is not releasing old mappings. It still rotates
> files in /run/log/journal/, so "du -sh /run/log/" seems correct. However,
> the old mappings mean, that even though the file is deleted, its content is
> still there. So the mappings are for files in /run/log/journal/, they just
> don't show up because there is no directory entry for them any more.

If this is the case they'd show up in /proc/$PID/maps but the file names
would have the " (deleted)" suffix. Do you see that?

> I guess the algorithm that decides when to release old mappings is broken
> for you.

Yes, it appears mmap-cache.c is doing something wrong.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.