Database Reference
In-Depth Information
Testing I/O Concurrency
A great way to tune for reads and writes at the same time is to run a quick test with
iostat (*nix only). In a terminal window, start iostat running with extended
disk information and have it refresh roughly every three seconds: iostat -x 3 .
Now open up two other terminal windows. In one of those windows, start a long
write process using the dd command (see Listing 6.4 ).
Listing 6.4 Use dd to Measure Sequential Write Performance
Click here to view code image
dd if=/dev/urandom of=/data/cassandra/test_outfile
count=512 bs=1024k
In the other terminal window, start a long sequential read process (see Listing
6.5 ).
Listing 6.5 Use dd to Measure Sequential Read Performance
Click here to view code image
dd if=/data/cassandra/test_outfile of=/dev/null
bs=4096k
Now look back at the iostat output, which is still continuing to run on the
first terminal window that you opened. Did either the read or write time drop sig-
nificantly? If the answer is yes, you may want to think about better separation. If
you have already decided to separate the CommitLog data directory and the data
directories onto different disks, you are on the right track.
Extending this idea a little further, building a more performant Cassandra node
from the I/O perspective can easily be accomplished with some planning. It is
common to put Cassandra data directories on a RAID drive. This isn't a bad idea
as RAID provides redundancy and a little bit of extra speed, depending on which
RAID level you use. But Cassandra offers a feature called JBoD (just a bunch of
disks).
This example is a little contrived, as it is not indicative of regular system per-
formance. The idea here is just to get a feel for what happens to response times
when the disks are under load. It also gives you the ability to tune your current
setup when there is an existing simultaneous read and write load. Again, even
 
 
Search WWH ::




Custom Search