Linux Optimizations. Performance Boosting.
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
Disabling atime
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 /mnt/rdsk.
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.
Summary
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.
Thanks for referring to my article
its just as easy to symlink to /dev/shm for cache, many reasons not to, but it does work
Vrroom,
It was my pleasure. It is what inspired this article.
George,
You are correct and you can always redefine the size of the tmpfs mount located at /dev/shm, even dynamically with the remount option of the mount command.
$ sudo mount -o remount,size=1G /dev/shm
Intel processors:
How to enable prelink:
1. Activate Ubuntu universe sources. The procedure is well-documented by Ubuntu.
2. use apt-get or synaptic to install prelink.
3. Open /etc/default/prelink with your favorite editor, as sudo/root.
4. Change PRELINKING=unknown from unknown to yes.
5. Adjust the other options if you know what the heck you’re doing. Defaults work well.
6. To start the first prelink (the longest one!), run sudo /etc/cron.daily/prelink
In the future, prelink performs a quick prelink (a less-than-1-minute procedure on most systems) daily, usually at midnight. Every 14 days, or whatever you changed it to be, a full prelink will run.
If you just did a major apt-get upgrade that changed systemwide libraries (i.e. libc6, glibc, major gnome/X libs, etc etc etc) and experience cryptic errors about libs, rerun step 6.
To undo prelink, change step 4 from yes to no, then rerun step 6.
SSD Optimization
Perform the following if you’re using an SSD. If you’re using a hard drive you can skip this section.
Create Ramdisks to Store Frequently Written Areas
1. Edit your /etc/fstab file. Add the following lines.
tmpfs /var/log tmpfs defaults 0 0
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0
Disable Access Time Attributes
1. Edit your /etc/fstab. Modify the root partitions settings. Add noatime and nodiratime to defaults.
/dev/sda2 / ext4 defaults,noatime,nodiratime 0 0
Optimizing the Kernel
1. Add the following to your /etc/rc.local file.
# Economize the SSD
sysctl -w vm.swappiness=1 # Strongly discourage swapping
sysctl -w vm.vfs_cache_pressure=50 # Don’t shrink the inode cache aggressively
# As in the rc.last.ctrl of Linpus
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo ondemand > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate_max > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
echo 20 > /proc/sys/vm/dirty_ratio
echo 10 > /proc/sys/vm/dirty_background_ratio
echo 1 > /sys/devices/system/cpu/sched_smt_power_savings
echo 10 > /sys/module/snd_hda_intel/parameters/power_save
echo 5 > /proc/sys/vm/laptop_mode
#Decrease power usage of USB while idle
[ -w /sys/bus/usb/devices/1-5/power/level ] && echo auto > /sys/bus/usb/devices/1-5/power/level
[ -w /sys/bus/usb/devices/5-5/power/level ] && echo auto > /sys/bus/usb/devices/5-5/power/level
/sbin/setpci -d 197b:2381 AE=47
/sbin/modprobe pciehp
/sbin/modprobe sdhci
Change the I/O Scheduler
1. Edit the /etc/grub.conf file. Add “elevator=noop” to the kernel line.
kernel /vmlinuz-2.6.27.5-117.fc10.i686 ro root=/dev/sda
George,
Wow. Thank you for the additional tuning tips!
Boot Speed and Application Startup Time:
Preload
What Preload does is preload frequently used applications in memory before use, so before you even run your frequently used application it is already loaded.
sudo apt-get install preload
Once installed, Preload will start, and no further action is necessary, the default configuration should be left alone, most likely you will notice a degrade in system performance editing the config.
If you would like to modify the configuration:
gksudo gedit /etc/preload.conf
Cache model (system) settings
model.cycle 20 [seconds]
How often Preload will query your system to update it’s model about programs and libraries to cache.
model.halflife 168 [hours]
How often Preload will begin to “forget” about old data; for each halflife, the statistical relevance of the current model loses 50% of its importance.
model.minsize 2000000 [bytes]
The minimum amount of system calls an application makes for it to be considered by Preload. A smaller number will mean Preload caches smaller applications, while to make Preload cache only larger applications, increase this number.
Memory settings
The forumula used to determine the maximum available memory available to Preload is:
(Total RAM x model.memtotal) + (RAM available at start x model.memfree) + (Cached memory x model.memcached)
model.memtotal -10%
model.memfree 100%
model.memcached 30%
Monitoring:
sudo tail -f /var/log/preload.log
Information about the specific files preloaded:
sudo less /var/lib/preload/preload.state
Preload will take a while to learn your habits.
@George: tmpfs /var/log tmpfs defaults 0 0
How does one save the logs between boots?
Bob T.,
Although I do not know what George would come back with but one tool that may prove to be useful in such a case would be rsync. You can actually create a script that runs in all appropriate run levels of your distribution, define the start and stop procedures and throw them into the /etc/rc.d/ path in their respective subdirectories. That way, you do not have to worry about manually invoking the script and allow init or startup do its work. Using rsync (reference man page to see all available options) you can enable rsync to restore data (including logs) from a directory it was synchronized before the shutdown, otherwise if nothing exists, it can skip the entire process. And if the unit powers down, rsync could do an incremental backup of the log data to that same persistent location.
$ sudo rsync -av /var/log /mnt/backup
Using the same command string with the source and destination directories swapped can restore the data back into the tmpfs mounted directory. Just a thought.
Very nice post!