Thanks for your suggestions. It doesn't look as if it is a journalctl storage issue. journalctl is using a bit over 3Gb of storage (with a default limit of 4 Gb), but about 40% of the space on my 32 Gb SD card is still free. top shows no zombie processes. The next time I am 'expecting' the system to start bogging down will be later this week, so I will look at some of the other things again then. It does look as if 'avail mem' as shown by top may be slowly decreasing over time, but it isn't clear what is causing this - none of the processes listed by top are using increasing or unusual amounts of memory..I know almost nothing about the systemd journal but it's possible it might be the cause of the sluggishness persisting when all your services are bounced. ie: the journal could be have been spammed by some sluggish/failing service. 'journalctl --disk-usage' is a command I've just noticed exists. It's also possible (/etc/systemd/journald.conf) to tweek how it behaves but read the manual (https://manpages.debian.org/bookworm/sy ... .5.en.html carefully first. I also noticed https://www.debugpoint.com/systemd-journald-clean/ but noted caveats on a quick glance. I'd maybe look to constraining the journal to a 24 hour period to see what effect that has.
'lsof' may be useful but the manpage is huge and complex. If you've an idea of the process then /proc/<pid>/maps but I'd only choose that route if you suspect a defunct/zombie process which 'top' should show (and ironically systemd journalctl). I'm too rusty on even 'lsof' to give examples off the top of my head!
Statistics: Posted by pfletch101 — Mon May 12, 2025 6:48 pm