I've done my best to make sure that the information I present here is both accurate and will actually improve performance but all I can truthfully say is that this is what has worked for me and so I take no responsibility if reading this guide unleashes the song which ends all worlds, but it really shouldn't do that so if it does please let me know.
If you are perhaps wondering why disk performance matters, consider for a moment that the hard drive in your computer is actually a mechanical device with real moving parts, and unlike the chips and boards in your computer the disk relies upon physical movement to do its job. The speed difference between a physical device and and electronic device is like the speed difference between throwing a baseball and sticking your face in a particle accelerator.
Now if you happen to be a 2D or 3D artist, which if you're reading my blog is a very small and unlikely possibility, then Hard Drive performance is likely very important for you because digital art often involves very many large files. So here, dear artist, are my tips for you:
1.) RAID5 - No, not the bug spray. (Yes, that joke is older than the internet.)
Redundant Array of Inexpensive Drives: type 5, those words become truer every year, particularly the inexpensive part. I know that a lot of people are jumping on the SSD bandwagon lately and perhaps SSD truly is the wave of the future but for the time being a RAID5 array of three ordinary 7200rpm SATA2 HD's will be faster, cheaper, and offers at least 5 times (probably 10x) more space than the average SSD of today's market. Lets also not forget that SATA3 is just around the corner. SATA3 claims to double the theoretical maximum output of SATA2 and thus reach up to 6 Gbit/s transfer rates.
Now if RAID5 only offered performance gains over a regular drive I might say that perhaps it is not worth the hassle, but the fact that you also get strong data protection through "redundancy" completely closes the deal. In short: If you aren't using Raid you're lazy and stupid. And there goes my last reader, good riddance!
I'd like to also add a meta-tip (a tip about a tip!) for RAID5 and that is to set your chunks lower than default. In many RAID5 guides that I've seen the "--chunk" flag is often completely ignored which means that your chunks will default to 512K which is quite large. One of the funny things about RAID5 is that if you are working with large files, as graphic artists often do, then you actually want to have a small chunk size, I go with 64K which is about the middle of the road. You may hear people (stupid people) say that chunk size does not matter because of slowish disk seek time, but in my case that was just not true at all, and so my thoughts are that if you've got relatively new drives with relatively fast seeks then a properly tuned file-system and the right chunk size will get you a measurable performance increase over default.
It's not rocket science, three disks, three partitions, boom, you've got a Raid5 partition:
mdadm --create /dev/md0 --chunk=64 --level=5 --raid-devices=3 /dev/sda3 /dev/sdb3 /dev/sdc3You can check your current Raid5 chunk size by doing this:
mdadm --detail /dev/md0 | grep ChunkOne more meta-tip, don't bother with hardware raid-controllers unless you plan to spend a large amount of money and like being disappointed anyway. Software Raid is fantastic and free.
2.) Regarding Raid5, set the "stride" and "stripe-width" options on the ext4 partition
This coincides with the chunk size of your RAID5 array. Whatever number you decide to use for your chunk size then your stripe-width will be half of that, and your stride number will again be half of the stripe-width.
So with a 64k raid chunk your ext4 stripe-width will be 32 and stride will be 16.
mkfs.ext4 -E stride=16,stripe-width=32 /dev/md0Read the ext4 section of the mke2fs man page to explain what this means, and if anyone tells you this doesn't matter slap them in the face with a fish.
You can check your current stride and stripe-width by running:
dumpe2fs -h /dev/md0 | grep RAIDIf you get no output it is because the file-system is not on a Raid5 partition.
3.) Double your journal size when making ext4 partitions, then double it again
The default journal size for an ext4 partition is 128mb, and for small partitions the journal will be even tinier.
Today 500GB disks are quite common, and when you get three of them together in a RAID5 array then combined you're going to be looking at about a 1 terabyte partition, so a 128mb journal just isn't going to cut it.
The benefits of increasing the journal size become smaller and smaller as the size of the journal goes up until it reaches around 1GB but since there is no drawback at all for increasing the journal to 1GB (other than losing that 1GB of space to the journal) that is what I always do.
If you don't want to lose an whole whopping entire gigabyte to the journal then the best bang for your buck is probably going to be around the 256mb mark, but as I said there is no drawback for using an entire gig and bigger is definitely better, and of course the size of the partition itself will also have some bearing on the matter, a general rule of thumb I use is 1% of the partition or 1GB whichever is smaller.
mkfs.ext4 -j -J size=1024 /dev/md0You can check your current ext4 journal size by running:
dumpe2fs -h /dev/md0 | grep 'Journal size:'
4.) Set max_user_watches to a reasonable (low) amount.
I have seen sites, particularly Linux audio sites, where people regularly recommend that max_user_watches be set to over 500k. Why on earth you would ever want it set that high I don't know and frankly I don't care.
This variable relates to the Linux inotify system and sets the max number of files which the kernel will watch for changes. That it even can be set to 500k without griding your hard drive to ash is absolutely mind boggling to me, but hey I like to boggle... Anyway, 16k is probably more than enough, but if you're feeling really paranoid and happen to like really big numbers then go ahead and crank it up to 32k, but 500k is just stupid.
On my sytem the variable is stored in the file /etc/sysctl.conf and all that needs to be done is to add or modify a line so that it looks like this "fs.inotify.max_user_watches = 32768"
You can check what it is currently set to on your system by doing "cat /proc/sys/fs/inotify/max_user_watches"
If you see that your current max_user_watches is much lower than 32k, some systems it is 8k, but you are having no problems then there is no benefit to be had by increasing it further.
Some examples of applications that use inotify are beagle, and dropbox, and a whole host of others, basically anything on a modern Linux system that monitors files uses inotify.
5). Lower your "swappiness" value to forestall swapping
The best hard drive performance is no hard drive performance, so this really isn't much of a disk tip other than to say that while swap is definitely a part of the disk you probably don't want to use it until you aboslutely have no choice, and lowering your swappiness value will help in that regard.
Again on my system this value is kept in the file /etc/sysctl.conf so either add or modify the line so that it looks like this "vm.swappiness = 10" the default on most systems is 60, and the range is from 0 to 100.
You can check the current value by doing "cat /proc/sys/vm/swappiness"
6). Use the "noatime" option
"noatime" is an option flag which when present tells the kernel not to update the "last read" time for files or directories. I know for some it might come as a shock that it includes directories, but it does, so there is no need to also include the "nodiratime" option flag.
Just add "noatime" to the appropriate line in your /etc/fstab file.
Something like this:
/dev/md0 / ext4 defaults,noatime 0 1
Bonus: Check out the "irq balance" package (Links are at the bottom)
In today's world of multi-core computers it is not uncommon for several devices to share an irq which in turn is assigned to a particular core to handle. In the old days all irq interupts were handled by a single core, so we know that it works just fine doing it that way but if you've got multiple cores then why not have the interupts spread out among the cores as evenly as possible? This is the issue that irq_balance tries to address.
The system already tries to do this automatically on bootup, but unfortunately when the system is left on its own it is often stupid and usually just one core will get the majority of the interupts assigned to it. While this isn't technically a problem since the system can run fine that way it does result in one core being busier than the others.
I'm sure you can imagine that if just one core is assigned to handle the interupts for the sound card, the video card, the hard drives, and the network card, that this isn't as optimal as it would be if each core handled just one of them.
Take a look at the file /proc/interupts to see what your current irq situation is like.
While you're at it, it is also a good idea to check your BIOS and turn off any devices you aren't using. Nobody uses the serial port or the parallel port anymore, turning them off in the BIOS will free up the irq for something else. The less devices that are forced to share an irq the better which means the less devices your computer is aware of the better.
Well I hope you have enjoyed this little tweaker tutorial, but if you can hear distant discordant tunes it may already be too late.
For next week I've decided I'm going to model a helmed Elven head.
Here is the basic concept to wet your appetite.
Darthvader meets Lord of the Rings.
Links for further edification:
Installing with Software RAID or LVM (wiki.archlinux.org)
Watching filesystem events with inotify (lwn.net)
What / Why / How? (irqbalance.org)