[systemd-devel] systemd-journald may crash during memory pressure
hurikhan77 at gmail.com
Sat Feb 10 19:25:55 UTC 2018
Am Sat, 10 Feb 2018 09:39:35 -0800 schrieb vcaputo:
>> After some more research, I found that vm.watermark_scale_factor may be
>> the knob I am looking for. I'm going to watch behavior now with a
>> higher factor (default = 10, now 200).
> Have you reporteed this to the kernel maintainers? LKML?
No, not yet. I think they are aware of the issues as there's still on-
going work to memory allocations within kernel threads, and there's
perceivable improvement with every new kernel version. Especially, btrfs
has seen a few patches in this area.
> While this is interesting to read on systemd-devel, it's not right
> venue. What you describe sounds like a regression that probably should
> be improved upon.
I know it's mostly off-topic. But the problem is most visible in systemd-
journald and I think there are some users here which may have a better
understanding of the underlying problem, or maybe even found solutions to
One approach for me was using systemd specific slices. So it may be
interesting to other people.
> Also, out of curiosity, are you running dmcrypt in this scenario? If
> so, is swap on dmcrypt as well?
No, actually not. I'm using bcache for rootfs which may have similar
implications to memory allocations. Swap is just plain swap distributed
across 4 disks.
If I understand correctly, dmcrypt may expose this problem further
because it needs to "double buffer" memory while passing it further down
the storage layer.
I had zswap enabled previously which may expose this problem, too. I now
disabled it and later enabled THP again. THP now runs very well again.
Looks like zswap and THP don't play well together. OTOH, these options
were switched on and off during different kernel versions. So it may also
be an effect of fixes in newer kernels.
Replies to list-only preferred.
More information about the systemd-devel