Here were the key takeaways and comments from all the SQL MI tests:
- The DBaaS platform was flexible and simple to manage.
- Our TPM numbers increased faster when fewer SQL MIs were running the HammerDB workloads simultaneously.
- The best performance that we observed was the SQL MIs with four CPUs requested. This was true when running a mixed-use workload.
- All instances handled the TPC-C workloads efficiently, with minimal SQL Waits.
- Overall AKS-HCI worker node CPU utilization remained low across all test group executions. It was clear that there was an opportunity for greater SQL MI density.
- SQL MI memory was managed by the SQL-PAL (Platform Abstraction Layer) and throttled at 80 percent. We did not need to configure memory at the SQL instance layer.
- When deploying a SQL MI with a core limit that was less than the number of cores on the worker node, AKS-HCI limited the CPU as a percentage based on the configured SQL MI core limit. However, the CPU workload at the AKS-HCI worker node layer did spread across all node cores.
- We tested SQL MAXDOP by aligning MAXDOP to SQL MI requested core count. There was no measurable change in performance. We concluded that it is more advantageous to allow AKS-HCI to manage the requested CPU usage.