Stop journald from burning your CPU when log volume spikes

Technical Briefing | 8/13/2026

You probably noticed your system load creeping up during a massive app crash. You assume it is the app, but often it is just journald trying to parse a mountain of incoming strings. I have seen this happen where the log daemon consumes more CPU cycles than the actual service it is supposed to be recording. It is a feedback loop that kills performance exactly when you need your server to stay responsive.

Why journald turns into a resource hog

When a process spews error messages at high frequency, journald does not just append lines to a file. It is busy indexing those logs into a binary format, checking filesystem capacity, and processing metadata. If you are forwarding these logs to a socket or processing them through external filters, the context switching overhead becomes visible. The kernel is doing the heavy lifting here, but the userspace daemon is the one paying the bill in latency.

systemd-analyze blame | grep systemd-journald

Stopping the noise before it hits the disk

• Cap RateLimitBurst and RateLimitIntervalSec in journald.conf to throttle ingestion
• Switch to volatile storage if you do not need persistence to save on write IOPS
• Use drop-in configuration files in /etc/systemd/journald.conf.d instead of modifying defaults

If you really need to understand what is flooding the bus, skip the standard logs and use bpftrace to track the syscalls triggering the write volume. You might find a single runaway thread writing garbage to stderr, which is something log rotation policies will never fix for you. Catching the source at the syscall level saves you from having to debug the journal daemon itself later.

Tuning these settings takes ten minutes, but it prevents the kind of midnight page that happens when your log daemon decides to throttle your entire production workflow. Keep an eye on your journal health; your future self will thank you when the disk isn’t melting under a mountain of stack traces.