ZRAM/ZRAM-swap optimizations

[ChiefGyk3D]

While Swap is great for not having enough RAM, it should be discouraged. On my Odroid HC2 was found to be set at 100 as shown by
cat /proc/sys/vm/swappiness
I recommend lowering to 5 or 10 to discourage swapping but not disable it. Lower is better
sudo sh -c 'echo "" >> /etc/sysctl.conf' sudo sh -c 'echo "#Set Swappiness lower" >> /etc/sysctl.conf' sudo sh -c 'echo "vm.swappiness = 10" >> /etc/sysctl.conf'
I notice you are also using ZRAM which was another recommendation, may be wise to maybe see this documentation to set it up for Pi, looks to apply for Odroid/armbian as well for me.

[ChiefGyk3D]

I'm reading this documentation here on ZRAM, this may actually improve it, so I may have been wrong on the swappiness because of how ZRAM works but we can make some additional tweaks I will test out https://haydenjames.io/raspberry-pi-performance-add-zram-kernel-parameters/

[ChiefGyk3D]

It appears we can possibly use a script from this project to increase performance for our devices by utilizing zram more for swapping and compress it up to 3X and making swapping more efficient so our systems are more stable overall.
https://github.com/foundObjects/zram-swap

then adding four paramaters to the /etc/sysctl.conf
vm.vfs_cache_pressure=500
vm.swappiness=100
vm.dirty_background_ratio=1
vm.dirty_ratio=50

[shermand100]

The commit above was to the Armbian branch.

Doing a build on Pi4 at the moment and will check the behaviour of the systemctl commands behaves the same. I'm almost certain it will be. So then swappiness of 10% will be project wide.

As for ZRAM it's something I'd need to research more of to be able to implement myself. If you knock something together that survives the Monero build and optimises daily use then I'm all for testing and implementation.

I'm no expert in this field but my first impression is that it takes some RAM and segregates it off as compressible ZRAM. I'd want to double check the behaviour of a Monero build which is very RAM heavy normally. Would that fill and then bleed from ZRAM into RAM then maybe into swap? I can't imagine how it's page management is handled on a large compilation.

[ChiefGyk3D]

As for ZRAM it's something I'd need to research more of to be able to implement myself. If you knock something together that survives the Monero build and optimises daily use then I'm all for testing and implementation.

I'm no expert in this field but my first impression is that it takes some RAM and segregates it off as compressible ZRAM. I'd want to double check the behaviour of a Monero build which is very RAM heavy normally. Would that fill and then bleed from ZRAM into RAM then maybe into swap? I can't imagine how it's page management is handled on a large compilation.

Agreed on the testing part. I am having it build a brand new install on my second HC2 as we speak and will pipe in the ZRAM tweaks and then immediately test a new Monero build, then incorporate my Symlink setup of the HDD, and then test the manual block loading as well and compare results on system load. During a manual load I am noticing SIGNIFICANT lag when running things, the web server is sluggish as is even htop via SSH and that's with 8 CPU cores on a Samsung Exynos 5422 and 2GB of DDR3 on it. So even the Pi4 would take a little performance hit for the improvements I propose. But I feel it would add a serious advantage without pushing for 4GB Pi 4's so much.

Granted I personally plan everything to move to 4GB Pi 4's with 512GB SSD or larger over USB 3.0 because I want to get this all working with PoE for all my private nodes. I'm still going to continue on the armbian side regardless due to more powerful hardware available.

[shermand100]

Commit to change swappiness of Raspberry Pi systems to 10 (from 60) e883bbb

[ChiefGyk3D]

I tested this on an Odroid HC2 and built Monero in 3 hours with the system being FAR MORE responsive and reactive to other commands whilst in operation I.e. webui and htop. I highly recommend testing this on the Pi platforms as well

[shermand100]

Ok so the swappiness is to hardware globally as 10.
I imagine other Odroid specific optimisations will be found. Because of this I'm reluctant to force them to all users with other hardware.
How about a new system settings menu from the web terminal where a user selects their hardware from a list which runs a script making optimisations like this?
Are these sorts of changes big enough to perhaps make this selection of hardware before install?