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

Chat about Linux in general
pbear
Level 15
Level 15
Posts: 5664
Joined: Wed Jun 21, 2017 12:25 pm
Location: San Francisco

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

Post 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.
User avatar
Pjotr
Level 22
Level 22
Posts: 15912
Joined: Mon Mar 07, 2011 10:18 am
Location: The Netherlands (Holland)
Contact:

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

Post 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....
Last edited by Pjotr on Mon Sep 14, 2020 2:33 pm, edited 1 time in total.
Tip: 10 things to do after installing Linux Mint 20 Ulyana
Keep your Linux Mint healthy: Avoid these 10 fatal mistakes
Twitter: twitter.com/easylinuxtips
All in all, horse sense simply makes sense.
cliffcoggin
Level 6
Level 6
Posts: 1235
Joined: Sat Sep 17, 2016 6:40 pm
Location: England

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

Post 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.
Cliff Coggin
pbear
Level 15
Level 15
Posts: 5664
Joined: Wed Jun 21, 2017 12:25 pm
Location: San Francisco

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

Post 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.
User avatar
trytip
Level 13
Level 13
Posts: 4928
Joined: Tue Jul 05, 2016 1:20 pm

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

Post 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.
Image
User avatar
LanceM
Level 10
Level 10
Posts: 3289
Joined: Sun Jul 08, 2018 11:50 pm

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

Post 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.
To mark this issue solved, go to your original 1st post and click the edit pencil and add [Solved] at the beginning of the title and click Submit.
Mint accepts donations: https://linuxmint.com/donors.php
User avatar
Pjotr
Level 22
Level 22
Posts: 15912
Joined: Mon Mar 07, 2011 10:18 am
Location: The Netherlands (Holland)
Contact:

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

Post 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.
Tip: 10 things to do after installing Linux Mint 20 Ulyana
Keep your Linux Mint healthy: Avoid these 10 fatal mistakes
Twitter: twitter.com/easylinuxtips
All in all, horse sense simply makes sense.
User avatar
bob466
Level 6
Level 6
Posts: 1156
Joined: Mon May 15, 2017 5:23 am
Location: Australia

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

Post 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
Linux For Ever...Windoze Never. Image
The Freedom To Choose Your Own Avatar Without Victimisation.
User avatar
antikythera
Level 9
Level 9
Posts: 2675
Joined: Thu Jul 02, 2020 12:52 pm

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

Post 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
Don't take life so seriously, nobody gets out alive anyway!
AMSTRAD CPC6128 - 128KB RAM, 3" Hitachi Floppy Diskette Drive, External Sony Cassette Recorder, Locomotive BASIC 1.1, CTM-644 Monitor
User avatar
Pjotr
Level 22
Level 22
Posts: 15912
Joined: Mon Mar 07, 2011 10:18 am
Location: The Netherlands (Holland)
Contact:

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

Post 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. :)
Tip: 10 things to do after installing Linux Mint 20 Ulyana
Keep your Linux Mint healthy: Avoid these 10 fatal mistakes
Twitter: twitter.com/easylinuxtips
All in all, horse sense simply makes sense.
User avatar
trytip
Level 13
Level 13
Posts: 4928
Joined: Tue Jul 05, 2016 1:20 pm

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

Post 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
Image
User avatar
LanceM
Level 10
Level 10
Posts: 3289
Joined: Sun Jul 08, 2018 11:50 pm

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

Post 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.
To mark this issue solved, go to your original 1st post and click the edit pencil and add [Solved] at the beginning of the title and click Submit.
Mint accepts donations: https://linuxmint.com/donors.php
User avatar
antikythera
Level 9
Level 9
Posts: 2675
Joined: Thu Jul 02, 2020 12:52 pm

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

Post 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.
Don't take life so seriously, nobody gets out alive anyway!
AMSTRAD CPC6128 - 128KB RAM, 3" Hitachi Floppy Diskette Drive, External Sony Cassette Recorder, Locomotive BASIC 1.1, CTM-644 Monitor
User avatar
Portreve
Level 10
Level 10
Posts: 3391
Joined: Mon Apr 18, 2011 12:03 am
Location: Florida

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

Post 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.”
Your humble Portreve.

Running Linux Mint Cinnamon 20.0

Problem solved? Mark your thread [SOLVED] | There’s no place like ::1
I used to be a natural people person, then people ruined it.

Recommended Keyboard Layout: English (intl., with AltGR dead keys)
User avatar
LanceM
Level 10
Level 10
Posts: 3289
Joined: Sun Jul 08, 2018 11:50 pm

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

Post by LanceM »

Once again, I've been investigating noatime being added to / with both Ext4 and Btrfs and have discovered it does reduce writes to the SSD for updates by about 25% to 30%. Above I posted it did not, but I was wrong. I added it to my main installs.
To mark this issue solved, go to your original 1st post and click the edit pencil and add [Solved] at the beginning of the title and click Submit.
Mint accepts donations: https://linuxmint.com/donors.php
User avatar
Kadaitcha Man
Level 11
Level 11
Posts: 3605
Joined: Mon Aug 27, 2012 10:17 pm

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

Post by Kadaitcha Man »

LanceM wrote:
Thu Oct 15, 2020 5:12 pm
Once again, I've been investigating noatime being added to / with both Ext4 and Btrfs and have discovered it does reduce writes to the SSD for updates by about 25% to 30%. Above I posted it did not, but I was wrong. I added it to my main installs.
I haven't bothered to check if writes are reduced, but I ritually add noatime to all my mounts because modifying the access time has to have a cost.
Coming to a thread near you: Lots of bragging about my AMD 5950X. Currently delayed due to high demand.
It's pronounced kad-eye-cha, not kada-itcha.
User avatar
LanceM
Level 10
Level 10
Posts: 3289
Joined: Sun Jul 08, 2018 11:50 pm

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

Post by LanceM »

Not satisfied with just testing noatime for a single kernel update, I did a much more extensive test this morning.
This is my test:
I installed a fresh copy of Mint 20 Cinnamon, using Btrfs onto a Crucial BX500 SSD. I updated the system with 397MB of updates.
I used Micron Storage Executive (for Linux) to measure the writes.
I repeated the experiment with another fresh install using Btrfs and added noatime (only to root in etc/fstab)
The end result was, using noatime, the GB written to the SSD was 2.38GB less, and they installed 37 seconds faster.
The same experiment with Ext4 (default install) with and without noatime, made no difference. From this test, I concluded for Btrfs, noatime reduces SSD writes by a statistically significant amount., whereas for Ext4, it does not.
The actual results:
Btrfs BX500 (without noatime)
Ready to update 3259.21GB
Updated 3272.23GB
This equals 13.11GB of new writes to the BX500

Btrfs BX500 (noatime added)
Ready to update 3282.58GB
Updated 6904205868 3293.31GB
This equals 10.73GB of new writes

Ext4 BX500 (without noatime)
Ready to update 3237.31GB
Updated 3242.32GB
This equals 5.01GB of new writes

Ext4 BX500 with (noatime added)
Ready to update 3303.48GB
Updated 3308.53GB
This equals 5.05GB
As to why on my previous experiment, yesterday, noatime reduced writes on Ext4 by about 25%, just doing a kernel update, I don't know.
To mark this issue solved, go to your original 1st post and click the edit pencil and add [Solved] at the beginning of the title and click Submit.
Mint accepts donations: https://linuxmint.com/donors.php
Post Reply

Return to “Chat about Linux”