Databases Reference
In-Depth Information
This is why we said you should strive for an
acceptable
cache miss rate, not a zero cache
miss rate. There's no single number you should target, because what's considered “ac-
ceptable” will depend on your application and your workload. Some applications might
do very well with a 1% cache miss rate, while others really need a rate as low as 0.01%
to perform well. (A “good cache miss rate” is a fuzzy concept, and the fact that there
are many ways to count the miss rate further complicates matters.)
The best memory-to-disk ratio also depends on other components in your system.
Suppose you have a system with 16 GB of memory, 20 GB of data, and lots of unused
disk space. The system is performing nicely at 80% CPU usage. If you wish to place
twice as much data on this system and maintain the same level of performance, you
might think you can just double the number of CPUs and the amount of memory.
However, even if every component in the system scaled perfectly with the increased
load (an unrealistic assumption), this probably wouldn't work. The system with 20 GB
of data is likely to be using more than 50% of some component's capacity—for exam-
ple, it might already be performing 80% of its maximum number of I/O operations per
second. And queueing inside the system is nonlinear, too. The server won't be able to
handle twice as much load. Thus, the best memory-to-disk ratio depends on the sys-
tem's weakest component.
Choosing Hard Disks
If you can't fit enough data in memory—for example, if you estimate you would need
500 GB of memory to fully load your CPUs with your current I/O system—you should
consider a more powerful I/O subsystem, sometimes even at the expense of memory.
And you should design your application to handle I/O wait.
This might seem counterintuitive. After all, we just said that more memory can ease
the pressure on your I/O subsystem and reduce I/O waits. Why would you want to
beef up the I/O subsystem if adding memory could solve the problem? The answer lies
in the balance between the factors involved, such as the number of reads versus writes,
the size of each I/O operation, and how many such operations happen every second.
For example, if you need fast log writes, you can't shield the disk from these writes by
increasing the amount of available memory. In this case, it might be a better idea to
invest in a high-performance I/O system with a battery-backed write cache, or solid-
state storage.
As a brief refresher, reading data from a conventional hard disk is a three-step process:
1. Move the read head to the right position on the disk's surface.
2. Wait for the disk to rotate, so the desired data is under the read head.
3. Wait for the disk to rotate all the desired data past the read head.
How quickly the disk can perform these operations can be condensed to two numbers:
access time
(steps 1 and 2 combined) and
transfer speed
. These two numbers also de-
termine
latency
and
throughput
. Whether you need fast access times or fast transfer
