I have noticed that my home server is strangely using lots of swap (~5 GB), despite having only a few lightweight processes running and loads of RAM installed (32 GB).
Upon configuring Grafana + Prometheus, I noticed a trend where cache + buffer will progressively increase until swap starts to be used. My system and services combined will use ~8 GB RAM. Upon rebooting, the cache + buffer will start anywhere from 3--10 GB, progressively ramp up to ~25 GB in 1--2h, where swap will start to be needed (~3 GB). See the image attached for reference.
My swap filesystem is on an expensive (to me) SSD, and I would like to reduce its wear by as much as possible. I understand that swap can introduce only minimal wear on SSDs depending on its nature and that it can be harmless, but I am still not sure what is causing this behavior (and why) and whether I should worry about it or not. So I figured I should investigate what is happening here.
My main question is, how can I figure out what is causing this behavior? Is it expected? I am looking for guidance from others who are more experienced than me in the topic.
A little bit about my system:
I am running Debian 12 on an NVMe SSD containing the root partition (btrfs) and docker services. I also have two HDDs, one with persistent data (ext4), and the other with backups (ext4). This is majoritarily a single-user machine. I tried using the following kernel parameters, but it hasn't helped:
vm.swappiness=10
vm.vfs_cache_pressure=200
My docker services are:
- *arr stack
- jellyfin
- nextcloud
- immich
- open-webui + ollama
- pi-hole
- invidious
- romm
- nginx proxy manager
- grafana + prometheus
- other minor services that I don't think are doing much (uptime-kuma, stirlingpdf, vaultwarden, etc)
I would like to keep it to torrents, since it doesn't hurt to improve my setup's resilience (after all, why not, right?). But at the same time I suspect that usenet might improve my experience, according to what I have been reading online when trying to debug this problem I'm facing.
You are right about the crack in my investigation. It seems like I have to dig deeper, and this is another indicator that maybe the usenet solution would be my best bet here, since I have already added plenty of indexers. You raise a good point about the filters configured in the *arr stack perhaps being "too aggressive" and sleeping on what would be a "good match". I will look into that.
I do have a specific example of content my setup isn't finding. I will give it a look later to find a specific season/episode that matches the criteria and report back. I appreciate your willingness to help!