SQL Server Performance Tuning

[Case Study] How to Size Azure Managed Instance & Avoid Overspending

Updated October 29, 20252 min read

Written byMark Varnas

Problem Summary

One of the biggest challenges in migrating to Azure Managed Instance is determining the resource limits.

We successfully used Microsoft SQL Server Distributed Replay feature to assess a SQL Server migration and choose the right service tier. Which allowed us to size it properly and not overspend on the instance.

Test

Server 1 – Current Production (or Source Server)

  • 48 CPU cores;
  • 200GB RAM Memory;
  • SQL Server 2008 R2 (SP1) – Enterprise Edition

Server 2 – Azure Managed Instance (or Target Server)

  • Gen 5, 4 vCores;
  • 20GB RAM Memory;
  • A SQL Managed Instances always run the latest stable SQL engine version, equal to or higher than the latest available RTM version of SQL Server.

Test Workload Used in Replay

  • Collector: Profiler
  • Duration: 8 hours
  • #of commands: 1,981
  • #of executions: 10,741,98

We executed a workload that was captured on Server1. We replayed the workload every 30 minutes, each session lasting 10 to 15 minutes.

Waits Observed During Replay on Server2 (or a Target Server)

Table 1 – Distributed replay wait types on target.

67% of SQL Server waits are due to insufficient memory for caching.

Given that the current production server (Server1) has 200GB of RAM and the Azure Managed Instance (Server2) only has 20GB, the poor CPU and duration performance makes sense.

The Azure Managed Instance requires more memory and CPU to match the performance of the current production server.

Replay Results on Server2 (or a Target Server)

Duration
(ms)
CPU
(ms)
Disk
(8k page reads)
ProdNewProdNewProdNew
Overall4012,891623,7221,108,22083,002,89851,446,643
AVG4002,891623,7221,108,22083,002,89851,446,643
Table 2 – Azure Managed Instance Distributed Replay results on Server2 (or a Target Server).

CPU usage

623,722 (ms)
Prod
1,108,220 (ms)
New

Overall duration

401 (ms)
Prod
2,891 (ms)
New

Disk

83,002,898 (8k page reads)
Prod
51,446,643 (8k page reads)
New

Before drawing any conclusions, remember we are comparing a server with 48 cores and 200GB RAM to an Azure Managed Instance with only 4 cores and 20GB RAM.

As shown in the table above, the new server had worse CPU performance and longer duration despite having better reads. The improved reads are due to a decade of query engine advancements compared to the current production version.

The poor CPU performance and longer query durations are expected due to the Azure Managed Instance having significantly fewer hardware resources.

Conclusion

The replay test was crucial for identifying the main bottlenecks were and identifying new server hardware sizing.

After additional DReplay testing, we chose to go with Azure Managed Instance tier of 16 vCores and 82GB of RAM. This configuration allowed us to achieve the same performance on the new server without overspending on hardware resources as on Server1 (Source server).

Discover More

Discover what clients are saying about Red9

Red9 has incredible expertise both in SQL migration and performance tuning.

The biggest benefit has been performance gains and tuning associated with migrating to AWS and a newer version of SQL Server with Always On clustering. Red9 was integral to this process. The deep knowledge of MSSQL and combined experience of Red9 have been a huge asset during a difficult migration. Red9 found inefficient indexes and performance bottlenecks that improved latency by over 400%.

Rich StaatsRich StaatsCloud EngineerMetalToad
See more testimonials