Page 2 of 2

Re: To swappiness or not to swappiness, that is the question...

Posted: Mon Sep 14, 2020 12:07 pm
by pbear
Pjotr wrote:
Mon Sep 14, 2020 4:57 am
Therefore I've decided to change my recommendation for swappiness to 20 in all cases (both for SSD's and for spinners).
That's a reasonable compromise. Indeed, it's what I've been doing for a while. I sometimes wonder, though, whether it's actually doing anything.

Re: To swappiness or not to swappiness, that is the question...

Posted: Mon Sep 14, 2020 12:25 pm
by Pjotr
pbear wrote:
Mon Sep 14, 2020 12:07 pm
Pjotr wrote:
Mon Sep 14, 2020 4:57 am
Therefore I've decided to change my recommendation for swappiness to 20 in all cases (both for SSD's and for spinners).
That's a reasonable compromise. Indeed, it's what I've been doing for a while. I sometimes wonder, though, whether it's actually doing anything.
I intend to monitor the swap usage more closely with Conky. On my machines with much RAM I expect to see no difference.

But on my machines with relatively low RAM, the impact of the swappiness increase should be noticeable. As should the impact on general system responsivity....

Re: To swappiness or not to swappiness, that is the question...

Posted: Mon Sep 14, 2020 12:41 pm
by cliffcoggin
Being a lazy bugger I take the easy way out and don't interfere with what I don't understand. So far, that has been a very successful policy. Linux Mint is good to me like that.

Re: To swappiness or not to swappiness, that is the question...

Posted: Mon Sep 14, 2020 10:29 pm
by pbear
cliffcoggin wrote:
Mon Sep 14, 2020 12:41 pm
Being a lazy bugger I take the easy way out and don't interfere with what I don't understand. So far, that has been a very successful policy. Linux Mint is good to me like that.
+1. Excellent policy. Newbies, in particular, get into a lot of trouble following advice because it "sounds good," but they don't actually understand it.

Re: To swappiness or not to swappiness, that is the question...

Posted: Mon Sep 14, 2020 10:44 pm
by trytip
LanceM wrote:
Mon Sep 14, 2020 11:14 am
Maybe that's so for modern SSD's. But if you're aiming for extreme "mileage" and reliability, it makes sense to reduce wear and tear anyway, just to be on the safe side.
Then I suggest you promote the use of profile-sync daemon
then why only a browser daemon? why not for all the .thumbnails and .cache that regenerate on your SSD everytime you click on something in the OS like file manager or changing themes, there is always caching going on, right?
i was going to try the profile-sync daemon but that just sounds like it's always in access with the SSD drive.
my SSD was 2 years used before i got hold of it, still going good. i haven't changed anything besides this last week in testing these swapiness. i use my SSD for dual boot with /root /swap/ /home and windows 10 they always write things over no matter what you do in a mixed system like dual boot with SSD.
but then if you start writing to your RAM will that not have the same consequence as an SSD? so either you replace your SSD or RAM.

Re: To swappiness or not to swappiness, that is the question...

Posted: Mon Sep 14, 2020 11:58 pm
by LanceM
RAM will that not have the same consequence as an SSD?
RAM is incredibly durable, you can research that vs flash memory as used in an SSD. Why use PSD? It's tiny, easy to configure. Browsers write several GB of data a day if used a lot. PSD cuts it in about half. Is it necessary? No, because an SSD will take it for years. I mainly commented, that anyone wanting to curb SSD writes should try PSD. I use PSD because it's small, easy, and works. There is a bit to setting it up, but nothing complicated.

Re: To swappiness or not to swappiness, that is the question...

Posted: Tue Sep 15, 2020 5:13 am
by Pjotr
LanceM wrote:
Mon Sep 14, 2020 11:58 pm
Why use PSD? It's tiny, easy to configure. Browsers write several GB of data a day if used a lot. PSD cuts it in about half. Is it necessary? No, because an SSD will take it for years. I mainly commented, that anyone wanting to curb SSD writes should try PSD. I use PSD because it's small, easy, and works. There is a bit to setting it up, but nothing complicated.
Interesting. I've been looking into profile-sync-daemon (PSD) a bit (didn't know about it before you mentioned it).

First of all, it's a good idea to keep web browser activity as much as possible in the RAM. PSD seems to do that. Preferably not with the addition of overlayfs though, because that appears to create undesirable opportunities for privilege escalation: you don't want to give a rogue website the opportunity to acquire root permissions on your system....

However, I'm not convinced that the entire web browser profile needs to be put into the RAM. The main source of disk activity by the web browser is probably cache use, and in Firefox that can also be tackled by a simple tweak of its settings:
https://easylinuxtipsproject.blogspot.c ... d.html#ID9
(item 9)

So for Firefox, PSD seems to be superfluous.

Unfortunately it looks like Chrome is less tweakable in that respect. The only thing I currently apply for Chrome in order to restrict its disk writes, is disabling the preloading of pages:
https://easylinuxtipsproject.blogspot.c ... .html#ID10
(item 10)

But I intend to research Chrome a bit further in this respect. Perhaps there are more opportunities for reducing its disk writes without the help of third-party applications.

Re: To swappiness or not to swappiness, that is the question...

Posted: Tue Sep 15, 2020 5:55 am
by bob466
I have 16GB of Ram...so Swappiness on my 500GB SSD is set at "1". If I had less Ram...then I would set it higher to say "10" / "20" or "60" the default. :D

I did read a few articles on Swappiness when I first installed my SSD 17 month ago...so it's a matter of personal choice as to what is the best for every user as not everyone has the same amount of Ram. Image

Re: To swappiness or not to swappiness, that is the question...

Posted: Tue Sep 15, 2020 6:31 am
by antikythera
Pjotr wrote:
Tue Sep 15, 2020 5:13 am
But I intend to research Chrome a bit further in this respect. Perhaps there are more opportunities for reducing its disk writes without the help of third-party applications.
If you have tmpfs enabled, you can make Chrome use that as browser cache instead of writing the the SSD. I've done it with manjaro as that has tmpfs enabled by default, I've not tried this yet with Linux Mint but it should be possible.

I guess you'd need to add a tmpfs entry to /etc/fstab with Linux Mint to get it working though (400MB in the example on the Arch wiki chromium page linked below is a bit too small for my liking - the default is usually half the installed RAM amount and this happens when you don't specify a size). If you set it as /tmp then not only chromium benefits from this. tmpfs uses RAM on the fly, if it isn't needed then the RAM is not occupied.

You can also do the same with your Chrome profile.

These two things should work in all chromium based browsers. Of course you need a decent amount of RAM installed for it to be worth bothering. I wouldn't attempt it with less than 8GB (6GB after any GPU share takes it's chunk) personally.

It does work reliably once set up. The drive activity light stays dormant when these tweaks are used on my systems.

A little reading material - https://wiki.archlinux.org/index.php/Ch ... e_in_tmpfs
https://wiki.archlinux.org/index.php/Tmpfs

Re: To swappiness or not to swappiness, that is the question...

Posted: Tue Sep 15, 2020 9:33 am
by Pjotr
antikythera wrote:
Tue Sep 15, 2020 6:31 am
Pjotr wrote:
Tue Sep 15, 2020 5:13 am
But I intend to research Chrome a bit further in this respect. Perhaps there are more opportunities for reducing its disk writes without the help of third-party applications.
If you have tmpfs enabled, you can make Chrome use that as browser cache instead of writing the the SSD. I've done it with manjaro as that has tmpfs enabled by default, I've not tried this yet with Linux Mint but it should be possible.

I guess you'd need to add a tmpfs entry to /etc/fstab with Linux Mint to get it working though (400MB in the example on the Arch wiki chromium page linked below is a bit too small for my liking - the default is usually half the installed RAM amount and this happens when you don't specify a size). If you set it as /tmp then not only chromium benefits from this. tmpfs uses RAM on the fly, if it isn't needed then the RAM is not occupied.

You can also do the same with your Chrome profile.

These two things should work in all chromium based browsers. Of course you need a decent amount of RAM installed for it to be worth bothering. I wouldn't attempt it with less than 8GB (6GB after any GPU share takes it's chunk) personally.

It does work reliably once set up. The drive activity light stays dormant when these tweaks are used on my systems.

A little reading material - https://wiki.archlinux.org/index.php/Ch ... e_in_tmpfs
https://wiki.archlinux.org/index.php/Tmpfs
Not quite what I'm looking for, but thanks anyway. By the way: the Arch wiki is, as always, a true goldmine. I've been using it for years. :)

Re: To swappiness or not to swappiness, that is the question...

Posted: Tue Sep 15, 2020 9:58 am
by trytip
i know i can try it out for myself but haven't yet. is firejail in conflict with PSD if installed? good question if you firejail your system. i only firejail browsers and torrent clients so far

Re: To swappiness or not to swappiness, that is the question...

Posted: Tue Sep 15, 2020 11:33 am
by LanceM
Preferably not with the addition of overlayfs though, because that appears to create undesirable opportunities for privilege escalation: you don't want to give a rogue website the opportunity to acquire root permissions on your system....
Without overlayfs it doesn't work nearly as well. PSD interacts with RAM and at intervals writes back to disk. That way when you shut down the cache is there instead of lost. Alternitavely you can not use overlayfs and cache entirely to RAM by modifying /etc/fstab. The downside is cache is lost at shutdown and you have to rebuild it at startup. With a fast internet connection it works good, but with a slow one it is a bit sluggish. Hence, I use overlayfs. To move cache to RAM edit the /etc/fstab file and at the end put:
tmpfs /home/lance/.cache tmpfs noatime,nodev,nosuid,size=400M 0 0
to uninstall, just remove the edit above and restart computer.

Re: To swappiness or not to swappiness, that is the question...

Posted: Tue Sep 15, 2020 12:46 pm
by antikythera
Pjotr wrote:
Tue Sep 15, 2020 9:33 am
Not quite what I'm looking for, but thanks anyway. By the way: the Arch wiki is, as always, a true goldmine. I've been using it for years. :)
I don't think there is another way with Chromium browsers. If there was, I'd be all over it like a rash :lol:

I relied heavily on the Arch wiki when I was using Manjaro KDE. I still refer to it now because it is indeed a goldmine and most of the tips are transferable across distributions. Some of the path names differ but apart from that it's normally plain sailing.

Re: To swappiness or not to swappiness, that is the question...

Posted: Wed Sep 16, 2020 12:31 am
by Portreve
I don't generally care for adding a bunch of stuff to my system for "enhancement" purposes because, in my experience, those sort of things just get in the way. I prefer to keep things clean, and make system-level adjustments (Pjotr's suggestions, for example) and leave it at that. To quote Scotty from Star Trek III (and not for the first time), “The more they over-think the plumbing, the easier it is to stop up the drain.”