Database Server Hosting

Database servers frequently read and write data to your hard drives. So increasing the speed at which data can be written and retrieved has a big effect on performance. Many people recommend SSD (Solid State Drives) for databases with high I/O requirements, as data can be written and read faster. However SSD comes at a higher price than SATA.

Whatever your choice, it is generally recommended that you split server elements across several drives on your dedicated server. This might mean a separate disk for your operating system, data files, log files, and databases. Finally, each element may be better suited to a particular RAID, to improve redundancy and performance.

Both of these decisions are informed by CPU usage, itself determined by the frequency and nature of database queries (and not the size of your database). The best way to make CPU decisions is to analyze actual CPU usage. By understanding and benchmarking current usage and performance, you can assess the need for additional processing power, and measure improvements.

If CPU utilization is greater than 75-80%, this indicates CPU pressure. CPU pressure is also considered to be present when at any given moment at least one user task has waited for CPU resource. When you see CPU pressure, you have two options, add additional CPUs or upgrade to faster CPUs.

Upgrading to a faster CPU will nearly always improve performance. Adding additional CPUs will only help a database job run faster if that job can take advantage of an additional CPU. For example, if CPU usage is at 100%, but nobody waited for CPU during the workload, adding an additional CPU will not help.

You can analyze CPU usage in the iWeb Control Center, or ask one of our experts for help determining your requirements. If you have no current data, make sure you can increase the speed or number of CPUs in your server once you have more data to work with, or as your situation changes.

The more Random Access Memory (RAM) you have, the more data can be cached (reside in memory), and the more data a single read can extract from your storage disk. The fewer reads to the hard disk necessary to complete the database query, the faster the query. If all of the data to be queried fits in the RAM, only one read will be required, “swapping/paging” is avoided, and the query is run as fast as possible.

As most databases use indexes to speed up queries, RAM requirement is more closely related to the size of your indexes than to the size of your entire database. A common rule of thumb is to keep the size of your indexes “in RAM”, in order to avoid paging (although this is not a hard and fast rule for all indexes and all database server programs). Similarly, if your entire data fits in RAM, indexes may be unnecessary.

The best way to determine RAM requirements is to look at actual usage data and performance, and establish benchmarks. If you do not have existing data, consider the amount of memory required for the most intensive transaction, and estimate the amount of free RAM you need to avoid swapping/paging.

The maximum supported memory size on a 32bit system is 4GB. In many cases, a database server on a 32bit OS will work best with the maximum 4GB RAM. If you find that running your database requires more memory than the 4GB of RAM a 32-bit environment can provide, you will need a 64-bit OS.

Remember that not all of your dedicated server’s RAM will be available for your database server to use, as some is required for the OS and system. One way to maximize the RAM available to your database is to split your database and web/application servers in a clustered architecture (see next tab).

If you have large databases with a lot of Inbound/Outbound (I/O) traffic and high CPU and RAM requirements, you may need a completely separate database server in order to achieve and maintain your desired level of performance (as opposed to combining a web and database server on a single dedicated server). Separating your database server from your web/application servers allows the database to use all of the CPU and RAM on the dedicated server hardware, improving performance.

If hedging against downtime is paramount, you can reduce both planned and unplanned downtime by replicating your database across a cluster consisting of an active database server and a hot-copy failover database server. Just make sure that your active and passive databases are synchronized!

You can also add backup into your architecture in a number of ways:

1. On a dedicated back up server (best)
2. With web-based data protection
3. On a separate drive on your server

Even if your hardware can handle the required frequency and size of transactions, the bandwidth provided by your hosting provider needs to be adequate for the traffic flow. This includes both local traffic (LAN) and traffic to and from the wider web (WAN). Your hosting package will also need to be priced in a way that minimizes data transfer charges, for example an unmetered LAN or WAN.

iWeb offers unmetered local and public traffic. That means there is no penalty for sending data back and forth between servers, or for high database usage. You may not require unmetered traffic, but do calculate the estimated monthly price for your hosting based on expected data transfer if it is charged by the GB.

Before resorting to any hardware and memory upgrades to improve your database’s performance, consider if your database server has been fully optimized to make use of the existing resources. And if you do need to upgrade, remember that there is no one-size-fits-all solution.

If you do not have a Database Admin (DBA) or you need support managing your databases, talk to an iWeb database expert about analyzing and optimizing your database before you invest in more hardware.