![]() ![]() ![]() Buying a server was a big deal – we only had one shot to buy a server and get it right the first time. They weren’t going to pay a lot for this muffler server. They’re a small company with no full time DBA and no glut of servers laying around. They wanted to put the pedal to the metal and make an order-of-magnitude improvement in their processing speeds with as few code changes as possible. Slow performance was not acceptable during normal production. This meant we could avoid the complexity of a failover cluster and shared storage. In the event of an outage, they didn’t mind manually failing over to a secondary server. The server was important, but not mission-critical. In the event of a failure, 15-30 minutes of downtime were acceptable. In practice, there are some situations – like this one – where it doesn’t make sense. Theoretically, virtualization makes for easier high availability and disaster recovery. Why We Switched from VMware to Bare Metal Both of those suggestions were a little controversial at the client, but the results were amazing. We recommended two things: first, switch to a standalone bare metal SQL Server (instead of a virtual machine), and second, switch to cheap commodity-grade local solid state storage. We could put some more memory in it to cache more data, preventing the read problem, but we would still get bottlenecked trying to write lots of data quickly to the shared storage. They were using a virtual server backed by an iSCSI SAN, and they were getting bottlenecked on reads and writes. They were frustrated with slow performance on the batch jobs, and after we performed our SQL Critical Care® with ’em, it was really clear that their hardware was the bottleneck. We’ve got a client that does big batch jobs every day, loading hundreds of gigabytes of data or more in short bursts. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |