Lennart's Look At Systemd This Year, What's Going To Happen In 2017

[unixfan2001]

there is a reason why I can't reason with people who ride the bandwagon, their first response is to ignore the obvious issue of authority, and the other is the rapacious use of the strawman fallacy.

look in the mirror, you are really calling yourself stupid by mischaracterizing my statement.

It's really not as obvious as you might think it is.
I for one don't know what the heck you're talking about.

[starshipeleven]

their first response is to ignore the obvious issue of authority,

Because there is none, and this is a political reason, not a technical reason.

and the other is the rapacious use of the strawman fallacy.

I didn't strawman.
You said (and confirmed) that you are against systemd for political reasons (that "authority" thing isn't a technical but a political reason, while also bullshit).

Then you say "stupidity can be found everywhere" and sorry but no, it's obvious that you mean "those that don't oppose the power/systemd are stupid", don't try to weasel out and say you were saying it as a general remark towards stupidity in general because it would be blatant bullshit.

look in the mirror, you are really calling yourself stupid by mischaracterizing my statement.

This is calling people stupid when they just mirror what you said. gg.

Really, stop giving a bad rep to honest people that dislike systemd for valid reasons, as "fight the power" is a bullshit reason in general, even more when applied to an opensource thing in an opensource world.

[cj.wijtmans]

on a 999MB VPS systemd-journald uses 3% memory... how to fix?

[interested]

on a 999MB VPS systemd-journald uses 3% memory... how to fix?

First, most of the memory is probably just mapped, not in actual use (memory usage in Linux isn't very intuitive). Try "pmap -d "systemd-journald PID" to so how much is used, shared or just mapped.


There is a relationship between the size of the systemd "journald" on disk and memory use, so take a look in "man journald.conf" on to reduce the journal size.

[cj.wijtmans]

First, most of the memory is probably just mapped, not in actual use (memory usage in Linux isn't very intuitive). Try "pmap -d "systemd-journald PID" to so how much is used, shared or just mapped.


There is a relationship between the size of the systemd "journald" on disk and memory use, so take a look in "man journald.conf" on to reduce the journal size.

I already put everything to 1M. Also i dont care if its mapped or not, it needs to be directly available. This is such a nonargument.

[interested]

I already put everything to 1M. Also i dont care if its mapped or not, it needs to be directly available. This is such a nonargument.

That wasn't an argument for or against systemd, but at technical description. You want something like log files to be mapped rather than taking up the cache, something it would do otherwise. So this is exactly what you want on a memory restricted system. And please notice that mapped memory isn't actually physical memory, but only allocated virtual memory, so unless used it doesn't really take up physical memory. Think of as semi-reserved memory that can be used by other parts of the system, until some process actually claims its reservation. As said, Linux memory usage isn't straightforward to understand at all.

Another suggestion is to set SplitMode=none and clean the /var/log/journald/../ for all files except "system.journal". Use a "killall systemd-journald" restart the journald with the new settings.

[F.Ultra]

Just noticed how all the Unix/Posix-loving crowd who hates systemd because it somehow in their minds do not follow the Unix/Posix design all have problem recognizing where the d in systemd comes from and all write is as a separate thing with either a capital D or as -D and so on even though suffixing a system daemon with d have been used in Unix/Posix for ages.

[cj.wijtmans]

That wasn't an argument for or against systemd, but at technical description. You want something like log files to be mapped rather than taking up the cache, something it would do otherwise. So this is exactly what you want on a memory restricted system. And please notice that mapped memory isn't actually physical memory, but only allocated virtual memory, so unless used it doesn't really take up physical memory. Think of as semi-reserved memory that can be used by other parts of the system, until some process actually claims its reservation. As said, Linux memory usage isn't straightforward to understand at all.

Another suggestion is to set SplitMode=none and clean the /var/log/journald/../ for all files except "system.journal". Use a "killall systemd-journald" restart the journald with the new settings.

it still uses 3% memory. it is unacceptable.

# pmap -d 73
73:   /usr/lib/systemd/systemd-journald
Address           Kbytes Mode  Offset           Device    Mapping
000055cda276c000     332 r-x-- 0000000000000000 0fe:00004 systemd-journald
000055cda27bf000       8 r---- 0000000000052000 0fe:00004 systemd-journald
000055cda27c1000       4 rw--- 0000000000054000 0fe:00004 systemd-journald
000055cda3962000     180 rw--- 0000000000000000 000:00000   [ anon ]
00007fa9209ef000    8192 rw-s- 0000000000000000 0fe:00004 user-1000.journal
00007fa9211ef000    8192 rw-s- 0000000000ec7000 0fe:00004 system.journal
00007fa9219ef000    8192 rw-s- 0000000001f25000 0fe:00004 system.journal
00007fa9221ef000    8192 rw-s- 00000000016e1000 0fe:00004 system.journal
00007fa9229ef000    8192 rw-s- 0000000002426000 0fe:00004 system.journal
00007fa9231ef000    8192 rw-s- 0000000001b40000 0fe:00004 system.journal
00007fa9239ef000    8192 rw-s- 00000000012d0000 0fe:00004 system.journal
00007fa9241ef000    8192 rw-s- 00000000005d0000 0fe:00004 system.journal
00007fa9249ef000    8192 rw-s- 0000000000a87000 0fe:00004 system.journal
00007fa9251ef000    7156 rw-s- 0000000002903000 0fe:00004 system.journal
00007fa925cec000    8192 rw-s- 0000000000000000 0fe:00004 system.journal
00007fa9268ec000      16 r-x-- 0000000000000000 0fe:00004 libattr.so.1.1.0
00007fa9268f0000    2044 ----- 0000000000004000 0fe:00004 libattr.so.1.1.0
00007fa926aef000       4 r---- 0000000000003000 0fe:00004 libattr.so.1.1.0
00007fa926af0000       4 rw--- 0000000000004000 0fe:00004 libattr.so.1.1.0
00007fa926af1000    1612 r-x-- 0000000000000000 0fe:00004 libc-2.22.so
00007fa926c84000    2048 ----- 0000000000193000 0fe:00004 libc-2.22.so
00007fa926e84000      16 r---- 0000000000193000 0fe:00004 libc-2.22.so
00007fa926e88000       8 rw--- 0000000000197000 0fe:00004 libc-2.22.so
00007fa926e8a000      16 rw--- 0000000000000000 000:00000   [ anon ]
00007fa926e8e000      92 r-x-- 0000000000000000 0fe:00004 libpthread-2.22.so
00007fa926ea5000    2044 ----- 0000000000017000 0fe:00004 libpthread-2.22.so
00007fa9270a4000       4 r---- 0000000000016000 0fe:00004 libpthread-2.22.so
00007fa9270a5000       4 rw--- 0000000000017000 0fe:00004 libpthread-2.22.so
00007fa9270a6000      16 rw--- 0000000000000000 000:00000   [ anon ]
00007fa9270aa000      32 r-x-- 0000000000000000 0fe:00004 libacl.so.1.1.0
00007fa9270b2000    2044 ----- 0000000000008000 0fe:00004 libacl.so.1.1.0
00007fa9272b1000       4 r---- 0000000000007000 0fe:00004 libacl.so.1.1.0
00007fa9272b2000       4 rw--- 0000000000008000 0fe:00004 libacl.so.1.1.0
00007fa9272b3000      72 r-x-- 0000000000000000 0fe:00004 liblz4.so.1.7.1
00007fa9272c5000    2044 ----- 0000000000012000 0fe:00004 liblz4.so.1.7.1
00007fa9274c4000       4 r---- 0000000000011000 0fe:00004 liblz4.so.1.7.1
00007fa9274c5000       4 rw--- 0000000000012000 0fe:00004 liblz4.so.1.7.1
00007fa9274c6000      24 r-x-- 0000000000000000 0fe:00004 librt-2.22.so
00007fa9274cc000    2048 ----- 0000000000006000 0fe:00004 librt-2.22.so
00007fa9276cc000       4 r---- 0000000000006000 0fe:00004 librt-2.22.so
00007fa9276cd000       4 rw--- 0000000000007000 0fe:00004 librt-2.22.so
00007fa9276ce000     136 r-x-- 0000000000000000 0fe:00004 ld-2.22.so
00007fa9278e4000      20 rw--- 0000000000000000 000:00000   [ anon ]
00007fa9278ed000       4 rw-s- 0000000000000000 000:0000f kernel-seqnum
00007fa9278ee000       4 rw--- 0000000000000000 000:00000   [ anon ]
00007fa9278ef000       4 r---- 0000000000021000 0fe:00004 ld-2.22.so
00007fa9278f0000       4 rw--- 0000000000022000 0fe:00004 ld-2.22.so
00007fa9278f1000       4 rw--- 0000000000000000 000:00000   [ anon ]
00007ffe58e2a000     132 rw--- 0000000000000000 000:00000   [ stack ]
00007ffe58f6d000       8 r---- 0000000000000000 000:00000   [ anon ]
00007ffe58f6f000       8 r-x-- 0000000000000000 000:00000   [ anon ]
mapped: 104140K    writeable/private: 408K    shared: 89080K

[interested]

00007fa9209ef000 8192 rw-s- 0000000000000000 0fe:00004 user-1000.journal

Did you remember to restart journald after setting splitmode to none? The low PID number and the fact that UID1000 shows up makes me suspect that if you tried at "killall" then it didn't succeed.

Also, notice that the only private memory used is around 408K which is the only memory journald consumes for it self. Much of rest is shared memory: stuff like "libc-2.22.so" may appear in journald's memory map, but it is shared with every other program using "glibc" (many) so even if journald was turned off, this part of the memory wouldn't shrink away since other c-programs would use that shared library.

So the real memory use of journald is much smaller than it would appear at first glance. And remember, most of the memory is just "allocated/mapped" virtual memory, it may not be in actual use. "pmap -x (PID#) " will show you the RSS (resident mem) and "Dirty" pages columns that are much closer than most other parameters to show actual, in-use memory.

Memory usage in Linux is dizzying difficult to understand for most people, and for which there is no single correct answer, just many "if seen from this perspective so much memory is used". From one point of view, it could be argued that your copy of journald only consumes less than 0.5 Megabyte of memory (the private non-shared mem) and even that number depends on its RSS size that are probably smaller than the mapped memory. Such a view is too narrow for most people, but it is just as right or wrong as to view that systemd uses all the memory that your pmap shows.

The above isn't an attempt to dismiss that you think that systemd uses too much memory, just an explanation that it might not use just as memory as you might think at first glance.

[cj.wijtmans]

Did you remember to restart journald after setting splitmode to none? The low PID number and the fact that UID1000 shows up makes me suspect that if you tried at "killall" then it didn't succeed.

Also, notice that the only private memory used is around 408K which is the only memory journald consumes for it self. Much of rest is shared memory: stuff like "libc-2.22.so" may appear in journald's memory map, but it is shared with every other program using "glibc" (many) so even if journald was turned off, this part of the memory wouldn't shrink away since other c-programs would use that shared library.

So the real memory use of journald is much smaller than it would appear at first glance. And remember, most of the memory is just "allocated/mapped" virtual memory, it may not be in actual use. "pmap -x (PID#) " will show you the RSS (resident mem) and "Dirty" pages columns that are much closer than most other parameters to show actual, in-use memory.

Memory usage in Linux is dizzying difficult to understand for most people, and for which there is no single correct answer, just many "if seen from this perspective so much memory is used". From one point of view, it could be argued that your copy of journald only consumes less than 0.5 Megabyte of memory (the private non-shared mem) and even that number depends on its RSS size that are probably smaller than the mapped memory. Such a view is too narrow for most people, but it is just as right or wrong as to view that systemd uses all the memory that your pmap shows.

The above isn't an attempt to dismiss that you think that systemd uses too much memory, just an explanation that it might not use just as memory as you might think at first glance.

This is more acceptable to me.(removed lz4 also)

# pmap -d 6146
6146:   /usr/lib/systemd/systemd-journald
Address           Kbytes Mode  Offset           Device    Mapping
00005648c5977000     328 r-x-- 0000000000000000 0fe:00004 systemd-journald
00005648c59ca000       8 r---- 0000000000052000 0fe:00004 systemd-journald
00005648c59cc000       4 rw--- 0000000000054000 0fe:00004 systemd-journald
00005648c64fb000     132 rw--- 0000000000000000 000:00000   [ anon ]
00007f771b769000    4096 rw-s- 0000000000000000 0fe:00004 system.journal
00007f771bb69000      16 r-x-- 0000000000000000 0fe:00004 libattr.so.1.1.0
00007f771bb6d000    2044 ----- 0000000000004000 0fe:00004 libattr.so.1.1.0
00007f771bd6c000       4 r---- 0000000000003000 0fe:00004 libattr.so.1.1.0
00007f771bd6d000       4 rw--- 0000000000004000 0fe:00004 libattr.so.1.1.0
00007f771bd6e000    1612 r-x-- 0000000000000000 0fe:00004 libc-2.22.so
00007f771bf01000    2048 ----- 0000000000193000 0fe:00004 libc-2.22.so
00007f771c101000      16 r---- 0000000000193000 0fe:00004 libc-2.22.so
00007f771c105000       8 rw--- 0000000000197000 0fe:00004 libc-2.22.so
00007f771c107000      16 rw--- 0000000000000000 000:00000   [ anon ]
00007f771c10b000      92 r-x-- 0000000000000000 0fe:00004 libpthread-2.22.so
00007f771c122000    2044 ----- 0000000000017000 0fe:00004 libpthread-2.22.so
00007f771c321000       4 r---- 0000000000016000 0fe:00004 libpthread-2.22.so
00007f771c322000       4 rw--- 0000000000017000 0fe:00004 libpthread-2.22.so
00007f771c323000      16 rw--- 0000000000000000 000:00000   [ anon ]
00007f771c327000      32 r-x-- 0000000000000000 0fe:00004 libacl.so.1.1.0
00007f771c32f000    2044 ----- 0000000000008000 0fe:00004 libacl.so.1.1.0
00007f771c52e000       4 r---- 0000000000007000 0fe:00004 libacl.so.1.1.0
00007f771c52f000       4 rw--- 0000000000008000 0fe:00004 libacl.so.1.1.0
00007f771c530000      24 r-x-- 0000000000000000 0fe:00004 librt-2.22.so
00007f771c536000    2048 ----- 0000000000006000 0fe:00004 librt-2.22.so
00007f771c736000       4 r---- 0000000000006000 0fe:00004 librt-2.22.so
00007f771c737000       4 rw--- 0000000000007000 0fe:00004 librt-2.22.so
00007f771c738000     136 r-x-- 0000000000000000 0fe:00004 ld-2.22.so
00007f771c94f000      16 rw--- 0000000000000000 000:00000   [ anon ]
00007f771c956000       4 rw-s- 0000000000000000 0fe:00004 system.journal
00007f771c957000       4 rw-s- 0000000000000000 000:0000f kernel-seqnum
00007f771c958000       4 rw--- 0000000000000000 000:00000   [ anon ]
00007f771c959000       4 r---- 0000000000021000 0fe:00004 ld-2.22.so
00007f771c95a000       4 rw--- 0000000000022000 0fe:00004 ld-2.22.so
00007f771c95b000       4 rw--- 0000000000000000 000:00000   [ anon ]
00007ffca15c2000     132 rw--- 0000000000000000 000:00000   [ stack ]
00007ffca15e6000       8 r---- 0000000000000000 000:00000   [ anon ]
00007ffca15e8000       8 r-x-- 0000000000000000 000:00000   [ anon ]
mapped: 16984K    writeable/private: 352K    shared: 4104K

SplitMode=none
SystemMaxUse=256K
SystemMaxFileSize=256K
RuntimeMaxUse=256K
RuntimeMaxFileSize=256K