Before reading this article, I highly suggest to get familiar with all the concepts of the previous article regarding IO tuning.
Your IO please, sir
How is your IO characterized? Yes, this question has to be asked yet again. It’s a big difference when tuning for random access reads vs. sequential reads.
How is your application doing in that matter? – You should know better than me.
My main approach when optimizing for read IO is to access the disks as little as possible. Disks are slow, really slow, comparing to CPU and RAM – if we can – we avoid them.
Write some proper code
Have a look at a use case of reading large chunks from your HDs and serving them via the network for various users.
Obviously reading the file on demand will save memory, however, it will increase your latency and cause a bad user experience. The secret is here is to:
- Prefetch some more
- Try to expect what should be prefetched
Prefetching (or buffering) the actual data you are going to serve can offload your HDs by reading the data just once and serving it multiple times.
However, when your IO is random and you can’t really expect what’s going to be fetched – you can still statistically optimize your cache hits by buffering as much as data as you can in memory.
Unfortunately for random IO, in the end of the day, expect your HDs to work and also expect the extra delay.
Ah and of course – if the “disk grinding” application is actually a database, then obviously avoiding full table scans and adding proper indexes where needed are the key for better performance in that matter.
Linux for the rescue?
I talked about IO schedulers in the previous article, together with filesystems, they affect your performance not only when writing, but also while reading.
What I did want to mention here, is that Linux does a pretty good job with its buffer cache – ever wondered how come you never have any free memory under Linux? – That is because Linux is doing an awesome job for you – caching disk IO for you without even asking you. So if you didn’t implement proper caches in your application, then Linux might take care of it for you.
TMPFS and RAMFS are, for some reason, only rarely used. These are in-memory filesystems. They can be great for caching files and making sure they stay in your RAM for ultra-fast access.
This is yet another countermeasure we can undertake in order to avoid the slowness of HDs.
Yet another tuneable
For some awkward reason, the ‘noatime’ and ‘nodiratime’ attributes are not on by default on Linux filesystems.
You should switch them on, as it’ll trigger a filesystem metadata write every time you access a file or directory – yes, also for reading. If I disabled it on my humble netbook (actually for battery saving concerns – have the HD spin less) – you must disable it also on your server.
I encourage you to do it now – also on your desktop:
# vim /etc/fstab
Just add ‘noatime’ and ‘nodiratime’ for any non-swap filesystem.
If you have a lot of memory in your system – then use it.
Many are the times I’ve seen people struggle with a database in the size of 10GB which has either multiple reads or writes or both of them together.
The simple solution is just to have the whole DB in-memory on a proper machine with more than 10GB or memory. Trust me – no matter what HD setup you have below – if you have 100% of your databases in-memory – HDs will never slow you down.
Consider it also for databases larger than 10GB. Unfortunately during my work experience I’ve seen what happened with a fairly optimized DB in the size of 100GB. It had gazillion (OK, maybe I’m exaggerating here) of updates and queries per minute. Jumping from 8GB of RAM to 64GB made the huge difference between a system that didn’t work to a system that actually copes with the load.
In most cases, if your system is that much loaded and you justify these huge amounts of memory – you are also probably making enough money to actually afford it.
Choosing a proper RAID controller can yield a very nice IO boost in terms of read performance. And I’m going to delve a bit into RAID1 here, in order to explain this concept.
RAID1 simply mirrors your data over 2 (or more) HDs, usually to provide redundancy. Say one of your HDs is broken – your system can continue to operate from the other.
RAID1 is usually considered “wasteful” because you don’t get extra storage for every HD you add. However, with RAID1 and a proper RAID controller, you can get tremendous read performance boosts.
How come? Imagine you have 10 read IO requests and one HD to serve them – they might get ordered sequentially and served optimally, however, only one HD will serve them.
Lets imagine you now have 10 HDs in a RAID1 and the same 10 read IO requests – you now have 10 HDs to serve them!! Theoretically speaking it’ll be 10 times faster than one HD.
That is with an exception of having a proper RAID controller – some cheaper controllers wouldn’t provide you the desired behavior of reading from multiple disks at the same time.
Be cautious when building a RAID1 configuration – the write speed of the array will be the write speed of the slowest HD in the array – it will decrease write performance noticeably if you have slower disks in the array.
Another word about RAID1 vs. RAID10 – RAID1 can be easily expanded – whenever you notice a performance problem – just chuck another HD in the RAID array and you’re good to go with some more performance!
Hands up, don’t move!
SSDs can yield a big performance boost if you care mainly about reading.
They are, however, 10 times more expensive – but also 10 times or more faster when talking about random access of data.
How come? – there’s nothing turning over there, nothing is moving – all of your stored data is “in the same distance” from you. While on traditional mechanical magnetic HDs you have to actually wait for a head to move to the correct location in order to retrieve any data.
It is a sort of a last resort optimization in my opinion, as it can easily double or triple your expenses.
One last dirty trick
Mechanical disks turn, some at 7.2K RPM, some at 10K and some even at 15K.
In addition to turning, they have a head, pointing to the location with the desired data.
For a given HD, the angular velocity of the head on the HD plate is constant, be it 7.2K, 10K or 15K RPM.
However, going further out on the HD plate, the absolute velocity of the head increases – as the plate radius is bigger and the angular velocity stays the same. This is simple physics.
For a more thorough explanation I suggest reading this brilliant article.
What does it mean for us? Well, in order to squeeze the best out of our HDs, we can use just the outer parts of its plate. Usually the outermost tracks of a HD are in the beginning of it, regarding partition creation.
The bag of tools I published in the previous article are also just as good over here.
Among them are obviously Monitis and iostat.
Examining your application in the applicative level is highly recommended as well. Provide yourself verbose logs and see where you hit the caches and where you miss them. Your task, obviously, is to minimize the cache misses to a bare minimum.
That’s all folks
Truly these two IO tuning articles are not a mere grocery-store tick list you can just perform and gain an extra boost – these articles were meant to give you tools to think, plan, design and eventually carry out successful architectures. Good luck!