On Fri, 12.10.12 20:55, Michael Olbrich ([email protected]) 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@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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
