Last week, I came across a tutorial about tweaking a specific parameter in the Linux virtual memory subsystem. So I figured that I would share all of the optimizations that I usually go through in a new installation of Linux.
Adjusting swap parameters
As the tutorial highlighted, minimizing the
vm.swappiness value is a good start. Realistically I do not understand why it defaults to 60. The lesser the value, the more memory is used before swapping processes to disk begins. That is, 0 will use all memory before swapping begins. Nowadays, most PCs come with more than enough memory, so why the need to swap so early. Setting a value such as 10 on a system that contains 1GB or more of RAM, should be fairly reasonable. I can only imagine the performance hit of write operations to SSDs. Just the amount of time to modify each block of each page with the read-modify-erase-rewrite mechanism SSDs utilize when writing data to NAND cells. Swapping can really bring down the performance of such a high-speed technology while also hurting the limited cell life, despite modern algorithms for wear-leveling.
While the highlighted article will pretty much state the same thing, you just need to modify the
/etc/sysctl.conf file and append
vm.swappiness=10. On reboot it will take affect when
sysctl is launched during
init; but you can quickly apply it by typing the following at the command line:
$ sudo sysctl -q -p
Another thing I usually do for personal computing PCs is that I mount all file systems (that support it), with atime disabled. Atime is a file’s last accessed time. In most cases this is an unnecessary update to the metadata associated with a recently accessed file. Again, this is a benefit to SSD accessibility as it is less data that needs to be written to the storage device. Here is a good example of how my
/etc/fstab file looks like (I do apologize for the misalignment):
UUID=5bc12928-9e8f-4413-9f20-6d5bcd107881 / ext4 errors=remount-ro,noatime 0 1
/dev/sda1 /boot ext4 noatime 0 2
UUID=50f38470-810a-4145-ab0a-5e3152ced335 /usr ext4 noatime 0 2
Under options I know that I do not care about access time, so there is never a need to constantly update that metadata for each file touched which would normal result in increased hard drive usage or SSD cell wear.
Caching applications to RAM
One last optimization I like to configure is caching what I can to RAM. A great example can be seen with Firefox. I use
tmpfs for this.
$ sudo mkdir /mnt/rdsk
$ sudo mount -t tmpfs -o size=96m tmpfs /mnt/rdsk/
This command creates a directory named
/mnt/rdsk and in turn use 96 MBytes of RAM for volatile disk space. The reason why I say volatile is that as soon as the file system is unmounted or the PC is rebooted or powered down, all contents disappear. The data will remain intact as long as the file system is active. Although who is to stop you from routinely backing the data up with either
rsync or some or archiving mechanism and in turn restore it when the system is back up and running?
Now why would you want to use something like this? Faster performance as you do not have to rely on slower disk device. Also in some cases there is added security. For instance, if Firefox caches its data to this RAM based file system and I shut down the PC, all of that cache which may include confidential or private information will disappear. To set something like this up you will need to modify your
/etc/fstab file and append the following line:
tmpfs /mnt/rdsk tmpfs size=96m,nr_inodes=10k,mode=777 0 0
Please reference the man page for the
mount command to know what these options mean for tmpfs. With this, everytime you reboot the PC, a 96 MBytes of tmpfs space will be mounted to
If you want to cache Firefox to this tmpfs space, then open up the web browser at type
about:config in the URL (BE CAREFUL HERE) and add a new string type of
browser.cache.disk.parent_directory with a value of
/mnt/rdsk. Restart the browser and you will notice a performance boost.
Note that using tmpfs and ramfs does not have to be limited to Firefox caching. There are numerous applications which can take advantage of this. It is just up to you to identify and decide.
One way to think of all these optimization is that they can also reduce power consumption. With less power spent to routinely spin up/down magnetic disk drives, it would make sense limit access to these devices.