Anyone using log2ram? I do, or was.
I was getting high memory usage and my Pi would eventually grind to a halt, requiring a power recycle to reboot. The only thing I had changed relatively recently was to install log2ram (to hopefully extend SD card life) So I've removed it and we'll see what happens.
The other thing I noted was that log2ram uses rsync. Interestingly, I had a problem with some of my backup scripts (which use rsync) that ran on my Pi - they too ground the Pi to a halt, kdswap0 maxing out the CPU. I switched those scripts to another box (an old Packard Bell N1600 with Debian 12), and they run just fine on that.
I'm trying to figure what is/was grinding my Pi to a halt. Is there some kind of swappiness issue? Is there a PiHole log2ram issue? Is rsync involved?
My Pi is a 4b 2gb RAM running latest v6 PiHole. I run Lyrion media server on it too.
free -h
total used free shared buff/cache available
Mem: 1.8Gi 1.1Gi 277Mi 840Mi 1.2Gi 690Mi
Swap: 2.0Gi 303Mi 1.7Gi
Sorted. None of the above, basically a network issue. Basically (and forgive the non tech speak) the Pi was talking too fast for my NAS device. The Pi was connected directly to the router at 1000mbs, the NAS only talks at 100. That was creating a bottleneck I suppose. By connecting the Pi to a hub (and in so doing, throttling it to 100) I've sorted the problem. Obviously, I'd rather everything on my network could talk faster but it's not a problem in practice.
I know you marked this as solved already. But I came across this trying to find a good size for log2ram on a pihole lxc as mine was full.
I'm assuming that your NAS itself is only 100M, but the switch is all gigabit.
Instead of adding a hub into the mix, you can just force the pi to run at 100mbs and not auto-negotiate. Install ethtool if it's not already, and assuming your nic is eth0 just issue:
sudo ethtool -s eth0 speed 100 duplex full autoneg off
That will lock the nic to 100mbps, and not let it auto negotiate up to gigabit.
Assuming that was really the underlying issue in the first place. I'd assume mismatched MTUs or something before the individual device's link speeds.I'm pretty sure that rsync use TCP, which is going to handshake and negotiate a speed. You can also set a max speed for rysync directly using -bwlimit, assuming that your version supports it (I'm not sure that all do off the top of my head). It takes a speed in KBps, you should restrict it anyway so that it doesn't saturate try to your connection and interfere with dns queries anyway, in my opinion.
Thank you @Joe_Schubert , thank you for taking the time to reply. Points noted. For now, I'll leave as is (behind the hub) as it's not inconvenient. Though I have implemented the rsync option (rsync is a powerful tool, with lots of wonderful options!) just because it was a simple change.
I know little of networking, and nothing of mismatched MTUs, but I will research it - as much out of interest as anything.