Does a Dedicated CPU or High Memory plan improve disk I/O performance?
I'm trying to improve my database's performance, but I'm encountering a few issues:
- My database is not performing up to task, and I'm looking to move it to a standalone database server Linode, perhaps running a dedicated CPU or High Memory plan.
- Transferring this database information between two Linodes using a Block Storage volume is giving me unacceptably slow write speeds.
Will a Dedicated CPU or High Memory plan improve these performance metrics at all? If so, how?
Block Storage Performance
Our Block Storage volumes generally achieve a throughput of 150 MB/s and 5,000 I/O operation per second (IOPS), though these performance figures may vary significantly based on your workload. In most cases, the SSD storage associated with your Linode plan will achieve better performance than our Block Storage volumes. Using your Linode's own SSD also has the benefit of being eligible for our Backup Service should you choose to enroll your Linode into this service.
Block Storage is most often used as a cost-effective means of expanding a Linode's storage capacity without needing to upsize the Linode plan itself. You may read more about Block Storage and some of its common use cases in this page and category from our Documentation:
Nevertheless, you are welcome to test the actual disk speed of your Linode using some of the recommendations described on this page:
Another option worth considering for transferring data between two Linodes in the same DC is to assign private IP addresses to your Linodes, create a pair of SSH keys between these Linodes, then to use a utility such as
rsync to transfer this data between your Linode. This arrangement will allow you to leverage our intranet's throughput to transfer the data between your Linodes.
Dedicated CPU, High Memory Linode Plans, and databases
A Dedicated CPU plan differs from our regular Linode plans by reserving the virtual CPUs assigned to your Linode for exclusive use by your Linode. Our standard plans share CPU resources amongst each other and accordingly may be susceptible to CPU resource contention, while our Dedicated CPU plans do not share CPU resources with other Linodes and thus will never need to worry about competing with other Linodes on the same host for CPU resources. Dedicated CPU plans are otherwise identical to regular Linode plans, receiving a pre-defined portion of the host's disk and memory resources and sharing access with other Linodes for these resources.
We have an article describing some use cases for Dedicated CPU plans, which mentions that "Big Data" is one area where having a Dedicated CPU plan can make a significant difference in performance versus a regular plan. Depending on the size of your database, you may find a Dedicated CPU plan markedly improves your database's performance.
Our High Memory plans provide a larger-than-normal allotment of RAM to your Linode. They are otherwise exactly the same a regular Linode plan. In particular, they do not come with dedicated CPU cores. This plan may be a good option for you should you want to store a significant amount of your database in RAM as opposed to on the Linode's SSD.
One last detail I'd like to mention about these plans is that you are capable of temporarily enhancing a regular Linode plan to a Dedicated CPU or High Memory plan, then reverting it back when you no longer need these additional resources. Your Linode will most likely be billed at the hourly rate for these plans while they are active on your account.
When performing such a temporary enhancement, you may want to avoid resizing your disk to make it easier to revert your Linode to its previous plan. Resizing a Linode does require a certain amount of downtime as our systems migrate your Linode to a host which has the resources for your newly selected plan available. You may read more about Linode resizes from this page in our Documentation:
Dedicated CPU and High Memory plans offer a number of advantages when compared to standard Linode plans. Although both plans still involve shared I/O throughput, a database application may benefit from a Dedicated CPU plan by never needing to wait for CPU resources for its I/O operations, or a High Memory plan by having a large reservoir of random-access memory for buffering database operations. These enhancements may make the difference between sluggish database operations and smooth database performance.
In the earlier post, Andrew mentions the following performance expectations:
Our Block Storage volumes generally achieve a throughput of 150 MB/s and 5,000 I/O operation per second (IOPS), though these performance figures may vary significantly based on your workload.
I wanted to clarify some aspects of those benchmarks. We have recently put measures in place to handle performance issues related to the abusive use of our Block Storage infrastructure. As a result, the overall performance of Block Storage should be more consistent.
The updated benchmarks are:
For short I/O bursts of less than 60 seconds, customers can expect to see 1500 IOPS. For longer running I/O bursts, you should expect to see lower IOPS.
This will affect customers with long-running I/O requests. Should you think your performance is being affected, please feel free to open a Support ticket and we can ensure that Block Storage is working as expected.