Slow server after virtualization or moving to the cloud

There comes a time when you need to upgrade that old physical server to a new server. The most expensive is to purchase a new physical server and High availability of a second in a separate data centre. The cost of this solution can rapidly grow.

The cost will push you to a hosted solution, virtualisation, or the cloud. What could be simpler?

You have your choice, and you migrate to the new solution. The servers are up, and it's live, and you start getting users' reports that the applications are slow. You conclude the root cause is the new server.

Where did it all go wrong?

The best way to get to where you went wrong is to look at your old server. The highest-spec SQL servers would have four CPU sockets, and their memory architecture would have four dedicated paths for each CPU; this gives you optimal hardware performance. The server may be old, but its superior architecture needs to be matched or exceeded in your new solution. And it was dedicated to one application. In this case, SQL.

What did you select for your new solution?

You went with the hosted virtualization solution. The cost savings are from fully utilising the hardware with more servers on the same host. Most virtualized hosts are two socket-based CPUs with multiple cores.

Gotcha No1

Your new virtual server has been configured as four sockets and four cores per socket. This makes the server slow as the Host-only has two sockets. Easy fix: change to 2 sockets and eight cores.

Gotcha No2

The host has 2 sockets and 32 cores per socket (no hyper-threading; that's another rabbit hole). The host has over thirty virtual machines that share the same host. This makes the server slow. Easy fix: move Virtual machines to another host to get a 1:1 ratio for CPU and RAM utilization. You can add more Virtual Machines 1:3 ratio if the is no perfomance impact, recommend you start wit 1:1 ratio.

Gotcha No3

Storage is shared with other Virtual machines. It can't be avoided, so make it SSD ( no compromise on this point.

You may have gone with a Cloud solution.

Gotcha No1

This is always going to be slower than a physical server.

Gotcha No2

Selecting the correct server in the cloud is key. I have seen the cheap web server selected that gives you a burst of performance when your web server needs more CPU. If It is an SQL server with a running transaction, it will randomly fail. Easy fix: Choose the right to sever, accept the extra cost and pay someone to optimise that running traction that takes hours to run in minutes to reduce your cloud cost.

Gotcha No3

Storage is not SSD. Easy fix upgrade to SSD

Gotcha No4

SQL database is Terabytes in size; this can be expensive for SSD, making SSD unviable. Easy fix: Cloud is not the best option. Use a hosted data centre solution or archive data to bring the size down to a more reasonable cost for SSD storage.

The easiest way to represent over-consolidation is to purchase a laptop; you pay for what's on the label and open the box, and you get a lower-spec laptop. They look the same, but you are not getting what you paid for

Both of these are in the same shop, and it would be easy for the labels to get mixed up and for you to pay for the best and get the lower-spec laptop. You would be very unhappy.

It's the same with over-provisioned virtualized servers or poorly selected Cloud servers.

Q ) Why use laptops as an example of server hardware?

A) Your cloud or virtual server should outperform a laptop.

Users claiming that the server is slow is valid if it has a lower specification than the laptop or desktop they are using.