1

I run typically 7 to 10 active tabs during the day.

I can see that starting from a low value, my swap space usage increases bit by bit all day, until eventually when it has got to about 1GB (out of a max 6GB), maybe over a day or two, system problems. Firefox is the only user application running.

There had been a similar issue on Ubuntu 18.04 LTS, using the same configuration and daily tabs, but this seemed to be solved, so that swap usage was stable and low.

vm.swappiness is set to 10.

What has happened here?

Joe
  • 309
  • 1
    How much RAM are you using? Swappiness shouldn't be a problem if you have enough RAM. If you don't have enough RAM, then you need to set your swappiness higher than 10 (like 60 or 70 if you only have 4GB of RAM for example). This way, the system will swap out before it is low on RAM and not trying to fervently swap out while the system RAM is maxing out at the same time. – mchid Mar 23 '23 at 21:18
  • Related: https://askubuntu.com/a/184221/167115 – mchid Mar 23 '23 at 23:03
  • I guess the point is that everything was fine before - so I'm not particularly impressed by the need more RAM argument. I'm running 4GB, and generally see about 75% RAM in use, with about 1.4GB of that as cache. I'm happy with web applications responsiveness - it's the ramp up of what may well be some form of leakage into swap that is the concern. – Joe Mar 24 '23 at 09:17
  • There is one thing you can check and there was a bug filed about it. On 18.04, watermark_boost_factor was disabled and you can check to see if it's disabled on 22.04 by running: cat /proc/sys/vm/watermark_boost_factor and it should say 0. If it is not zero, then run echo 0 | sudo tee /proc/sys/vm/watermark_boost_factor and to make it permanent, edit /etc/sysctl.conf and make sure the following is set to vm.watermark_boost_factor=0 – mchid Mar 24 '23 at 14:17
  • There's more information about the bug here and they also disabled I915_SHRINK_WRITEBACK somehow (related to intel) but this was supposed to be fixed on newer versions. – mchid Mar 24 '23 at 14:32
  • There's also some discussion here where increasing swappiness to 60 alone did not fix the issue but increasing swappiness to 60 and setting watermark_boost_factor to 0 did solve the problem. – mchid Mar 24 '23 at 14:41
  • 1
    Thanks for all the input. vm.watermark_boost_factor was set to 15000. Per recommendation, I set this to 0, and this seems to have stabilised the swap. I also changed the swappiness value up to 60, but had the slight impression of lag, so reverted to 10. So far so good. I'll give it a few working days to be sure, and then mark the question as answered. – Joe Mar 24 '23 at 19:03

1 Answers1

1

On 18.04, watermark_boost_factor was disabled and you can check to see if it's disabled on 22.04 by running:

cat /proc/sys/vm/watermark_boost_factor

and it should say 0. If it is not zero, then run:

echo 0 | sudo tee /proc/sys/vm/watermark_boost_factor

and to make it permanent, edit /etc/sysctl.conf and make sure the following is set to vm.watermark_boost_factor=0

Although the bug is technically fixed, you can read more information about the change here and here.

The second link indicates that setting swappiness to 60 did not fix the issue but setting watermark_boost_factor to 0 along with swappiness at 60 did help although the swappiness setting may not be necessary if you're not using RAM intensive processes (they described +96% RAM in use).

mchid
  • 43,546
  • 8
  • 97
  • 150
  • 1
    Marked as answered as I think this stabilised the swap. However, swap still climbing, though not at the same rate as previously (now about 400MB over the day, roughly half what it was). – Joe Mar 27 '23 at 19:53