So, i have 8GB RAM but notice paging starts before hitting 5GB used memory. I tried lowering vm.swappiness but this did not change the symptoms and caused other issues.
The next candidate is tmpfs which is set to 50% RAM by default.
1 - One question would be does this prevent full usability of RAM by applications?
Googling on how to change default size:
2 - https://tr.opensuse.org/SDB:Setting_the_Size_of_tmpfs_and_shmfs seems incorrect, i do not have file /etc/sysconfig/kernel on my system.
3 - looking for other avenues, i tried in fstab
tmpfs /dev/shm tmpfs defaults,size=35% 0 0
but this leaves the other tmpfs drives unchanged, i tried the same for e.g. /run and /sys/fs/cgroup but this would not work
so i have monitored swap from system monitor. i just did an experiment by opening multiple (ram hogging) gmail tabs from a cold boot and RAM utilisation no longer seems as bad as passive observation would suggest.
#free -h
total used free shared buff/cache available
Mem: 7.7G 6.1G 153M 1.2G 1.4G 147M
Swap: 8.0G 1.5G 6.5G
my frustrations/investigations started with a (assumed) kernel update that caused very long e.g. 10 to 15min near freezing when using swap i.e. when using virtual box etc. looking at the results from a cold boot perhaps there’s nothing to improve.
to try and answer your questions
1 - no real dedicated apps. I usually have a LOT of chrome tabs open, okular with MANY pdfs, and rarely use virtual box + minor apps.
2 - (im on plasma) lower than typical use i.e. right now
total used free shared buff/cache available
Mem: 7.7G 2.4G 3.4G 1.1G 1.9G 3.9G
Swap: 8.0G 1.4G 6.6G
The freezing issue occurred maybe ~6 times over say ~3 weeks (hasnt happened now for more than a week). Everything would freeze with only the mouse cursor moving with intermittent jerky motions etc.
i didnt get very far in finding a smoking gun for the freezes, i managed to get system monitor into the foreground a few times and noted disk activity processes (if i remember kswapd0 process).
3 - i set vm.swapiness in /etc/sysctl.conf starting at 10 and incremented back up to 60. The problem was specific to gradio (and i think the onset of swap). If gradio was playing when the freeze occurred it would continue to play and the freeze would continue without recovery. moving swapiness back to 60 fixed the problem.
they sound very similar and may be be interconnected but the swapiness/gradio freeze if i remember could be initiated very reliably near the onset of swapping.
sorry if i cant be more specific (it was a bad month, i also had extended freezing from ABP crashing in chrome). I can test the gradio/swapiness crash if you like to see if it has resolved?*