Dedicated Server Reviews

Late last week, we brought you some feedback from the exhibitors and attendees we met in Houston from cPanel's third annual partner conference, gaining some insight into their thoughts about attending the event and the value they found in being there.

We also sat down with Eric Gregory, "The Swiss Army Knife" of cPanel and discussed how he thought the third conference turned out . Naturally, I had to question him about the unique job description I assumed would be associated with that title.

After a good chuckle, Gregory explained that he's responsible for performing such a wide variety of tasks at cPanel, that the best possible job title for him is that of "The Swiss Army Knife." And considering he was the man behind the scenes responsible for organizing most of the event - while taking care of marketing and communications, amongst other things, on a normal day-to-day basis - this man certainly seems like a "tool" of ultimate utility :)

As a webmaster, you know the importance of a good spam blocking and virus protection program, and maybe you have learned from our dedicated server tutorials how to set con jobs for scheduled tasks, how to protect your system or administer backups, but did you know that there may be things you are unaware of trying to hack your server?

One of these necessary evils of dedicated server hosting is called a rootkit. A rootkit is simply a program usually designed by hackers who attempt to take control of your dedicated server without authorization. They can gain complete access to your system or install themselves as drivers, kernel modules, or other malware. They often go undetected and can seize control of your operating system and obscure the presence of potentially harmful viruses, commands, or Trojans.

Oftentimes, once a rootkit has hidden utility programs in your system, they open a backdoor to your server at any time of the day and can thus be severely harmful to the health of your dedicated server.

If your dedicated web host has a Managed Hosting option, you should look into it, as they often perform rootkit checks to ensure the security of your dedicated server. Remember, a good dedicated web hosting provider doesn’t want your server brought down either and will do everything in their power to keep you a happy customer.

If you run a fairly busy and/or badly configured MySQL server, you may receive something like this when attempting to connect:

# mysql
ERROR 1040: Too many connections

MySQL is telling you that it is handling the maximum connections that you have configured it to handle. By default, MySQL will handle 100 connections simultaneously. This is very similar to the situation when Apache reaches the MaxClients setting. You won’t even be able to connect to MySQL to find out what is causing the connections to be used up, so you will be forced to restart the MySQL daemon to troubleshoot the issue.

What causes MySQL to run out of connections? Here’s a list of reasons that may cause MySQL to run out of available connections, listed in order of what you should check:

Bad MySQL configuration
Verify that you have set MySQL’s buffers and caches to appropriate levels for the type of data you’re storing and the types of queries that you are running. One quick way to check this information is via MySQLTuner. The script will tell you how well your server is performing along with the corrections you should make. Running the script only takes a few moments and it doesn’t require a DBA to decipher the results.

Data storage techniques
Remember that MySQL works best when moving vertically, not horizontally. If you have a table with 20 columns, breaking it into two tables with 10 columns each will improve performance. Even if you need to join the two tables together to get your data, it will still perform at a higher level. Also, use the right data types for the right data. If you’re storing an integer only, don’t use a CHAR or VARCHAR data type. If your integer will be small, then use something like a TINYINT or SMALLINT rather than INT. This means MySQL will use less memory, pull less data from the disk, and have higher performing joins.

Slow queries
These are generally pretty easy to fix. If you have queries that don’t use indexes, or if queries run slowly with indexes in place, you need to rethink how you’re pulling your data. Should your data be split into multiple tables? Are you pulling more data than you need? Keep these questions in mind, enable the slow query log, and re-work your queries to find where the bottlenecks occur.

Division of labor
Most people who use MySQL have a dynamic site written in a scripting language, like PHP, Perl or Python. It’s obvious that your server will need to do some work to parse the scripts, send data back to the client, and communicate with MySQL. If you find that your server is overworked, consider moving MySQL to its own dedicated hardware. Among many other things, this will reduce your disk I/O, allow you to better utilize memory, and it will help you when you need to scale even further. Be sure to keep your MySQL server close to your web servers, however, as increased latency will only make your performance problem first.

Right hardware
Do you have the right hardware for the job? Depending on your budget, you may need to make the move for hardware that gives you better I/O throughput and more useable cores. MySQL is a multi-threaded application, so it can utilize multiple cores to serve data quickly. Also, writing logs, reading tables, and adjusting indexes are disk-intensive tasks that need fast drives to perform well. When you look for a dedicated server for MySQL, be sure to choose multiple-core machines with low latency RAM, fast drives (SCSI/SAS), and a reliable network interface.

By reviewing these bottlenecks, you can reduce the load on your MySQL server without increasing your maximum connections. Simply increasing the maximum connections is a very bad idea. This can cause MySQL to consume unnecessary resources on your server and it may lead to an unstable system (crash!).