Database Hardware Optimization Strategies to Reduce Hosting Costs

What to consider when sizing your CPU, memory, and storage hardware to best optimize RavenDB’s performance for your needs

After deciding on an availability strategy, choosing the right hardware configuration for your RavenDB workload is critical to maintain expected performance SLAs and keep your database healthy. In this article, we’ll cover what to consider when sizing your CPU, memory, and storage hardware to best optimize RavenDB’s performance for your needs.

We have published recommended system requirements, OS configuration, network/firewall settings, and storage hardware requirements to achieve peak efficiency with RavenDB. These should be referenced for choosing the performance tier of your hardware.

How RavenDB Uses Resources

RavenDB is semi-unique amongst other database technologies because it offloads a lot of client processing through its indexes which run in the background and can run code to process documents. 

RavenDB is designed to run business logic on the server so that queries are fast and provide immediate responses. This means that CPU is an important consideration compared to other databases where there is less compute power needed.

Since RavenDB optimizes for fast reads, it keeps as much commonly accessed data as it can in memory. Since memory will eventually run out, it’s critical to ensure you are using high-speed storage.

Choose Faster Cores

With the way RavenDB divides up workloads, it’s better to choose faster cores instead of more cores.

Depending on how your indexes are designed, you may need more or less CPU power. For a database that is constantly indexing new documents, load may be more constant and a lot of CPU may be needed to keep up. For a database where indexing is happening less often, it may be more variable and less CPU is needed to handle the average load.

To see what your CPU load looks like, leverage the Studio to get insights into usage during your peak traffic. This is your upper bound. You can then size the hardware to meet this peak traffic. Under peak load, your CPU usage should stay under 80-85% to reduce thread starvation. It also leaves a little extra room in case you receive a short spike in load. Cloud providers sometimes provide “burstable CPUs” and RavenDB can handle those scenarios too.

Prefer Dedicated Workloads

Relative to CPU, memory is more important to RavenDB. RavenDB will use up all the memory on your server. It’s important to keep this in mind as sometimes you might be tempted to put an application container on the same server as your RavenDB instance. This is inadvisable. RavenDB performs best when it is not competing for resources against other services or applications. 

Once you right-size the CPU, choose the server in that performance tier that has “good enough” memory (8GB+ is recommended). RavenDB will store as much as it can within memory to keep things fast and only then will it rely on the disk to serve requests. This means most of your budget should be reserved for high-performance storage.

Use NVMe-Backed Storage

If you undersize the CPU, the database performs slower under load but can still operate. RavenDB will use all your available RAM to keep things as fast as it can. Your disk is the last stop for all your data, which has to be committed. RavenDB uses many tactics to make this as fast as possible but it’s still critical to use high-performance premium SSD storage, ideally with NVMe technology.

Use Automatic Disk Expansion

If your disk is full, RavenDB cannot write any more data and your app will come to a grinding halt. Disk space issues are 100% preventable. RavenDB will surface alerts in the Studio when disk space is low but you should also set up disk usage alerts outside of RavenDB to be notified when space is low. Cloud hosts make it simple to expand disks on-demand with little to no downtime but it is a manual process. If you are choosing RavenDB Cloud to host your database, storage is expanded automatically for you reducing potential for a failure due to low space.

Use Separate Drives for High-End Systems 

There is one advanced optimization you can achieve to get better storage performance by changing the location of the journal to a faster drive. For example, you could use two locally attached disks at different performance tiers and have the journal write to the faster drive.

Avoid Disk Bursting and Throttling

A common issue with hosting databases on the cloud is how providers throttle I/O throughput using disk bursting. With cloud providers like Azure and AWS, you do not get unlimited I/O. Instead, each disk tier has a “performance level.” When you exceed the rated performance level, you are allowed to “burst” which is meant to be temporary.

Bursting with RavenDB is likely to occur during heavy indexing load such as during index deployment. For this reason it’s recommended to use Premium solid-state drives (SSD), especially NVMe-backed drives.

If you find your disk is bursting often, it’s likely you will need to move up a performance tier to reduce the amount of exceeding your performance capacity.

Avoid Using Shared Disks

Many cloud providers offer the ability to use shared disks which can mitigate storage failures by providing built-in redundancy. This is made possible through a Storage Area Network (SAN) or Network Attached Storage (NAS). Sometimes you will hear this referred to by its standard, SCSI Persistent Reservations (SCSI PR).

A shared disk is presented as a locally attached disk to a server operating system. This means that two or more RavenDB nodes using a shared disk will write concurrently to the same underlying hardware, which will actually cause failures due to contention issues.

For this reason, you should not use SAN or NAS storage for clustered RavenDB nodes and instead use local disks for each cluster node.

Conclusion

If your database is slow to respond under heavy load, is running out of disk space, or is suffering slow writes to disk, these can lead to transient application failures. It’s critical to “right-size” your hardware for your RavenDB workload to ensure a smooth operation.