%3CLINGO-SUB%20id%3D%22lingo-sub-1148901%22%20slang%3D%22en-US%22%3ECompute-optimized%20Fsv2%20hardware%20in%20Azure%20SQL%20Database%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1148901%22%20slang%3D%22en-US%22%3E%3CH2%20id%3D%22toc-hId--1412525128%22%20id%3D%22toc-hId--1412525128%22%3EExecutive%20summary%3C%2FH2%3E%0A%3CP%3EFor%20CPU-bound%20workloads%2C%20Fsv2%20can%20improve%20query%20response%20time%20and%20workload%20throughput%20by%2020-40%25%2C%20compared%20to%20Gen5%20hardware.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CH2%20id%3D%22toc-hId-1074987705%22%20id%3D%22toc-hId-1074987705%22%3EWhat%20is%20Fsv2-series%20hardware%3F%3C%2FH2%3E%0A%3CP%3EAt%20the%20Ignite%20conference%20in%20November%202019%2C%20we%20%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fazure-sql-database%2Fnew-memory-and-compute-optimized-hardware-options-in-azure-sql%2Fba-p%2F966830%22%20target%3D%22_blank%22%20rel%3D%22noopener%22%3Eintroduced%3C%2FA%3E%20the%20preview%20of%20two%20new%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fazure%2Fsql-database%2Fsql-database-service-tiers-vcore%3Ftabs%3Dazure-portal%23hardware-generations%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehardware%20generations%3C%2FA%3E%20in%20Azure%20SQL%20Database%2C%20M-series%20and%20Fsv2-series.%20In%20a%20previous%20blog%20%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fazure-sql-database%2Fscaling-up-an-iot-workload-using-an-m-series-azure-sql-database%2Fba-p%2F1106271%22%20target%3D%22_blank%22%20rel%3D%22noopener%22%3Epost%3C%2FA%3E%2C%20we%20described%20a%20workload%20that%20achieved%203x%20scalability%20using%20M-series%20hardware.%20In%20this%20post%2C%20we%20will%20take%20a%20closer%20look%20at%20the%20Fsv2-series%20hardware%2C%20now%20Generally%20Available%20for%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fazure%2Fsql-database%2Fsql-database-vcore-resource-limits-single-databases%23general-purpose---provisioned-compute---fsv2-series%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3Esingle%20databases%3C%2FA%3E%20and%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fazure%2Fsql-database%2Fsql-database-vcore-resource-limits-elastic-pools%23general-purpose---provisioned-compute---fsv2-series%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3Eelastic%20pools%3C%2FA%3E%20in%20the%20General%20Purpose%20service%20tier.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThe%20most%20notable%20feature%20of%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fazure%2Fvirtual-machines%2Fwindows%2Fsizes-compute%23fsv2-series-1%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3EFsv2%3C%2FA%3E%20virtual%20machines%20in%20Azure%20is%20high%20CPU%20clock%20speed.%20The%20base%20processor%20frequency%20in%20these%20machines%20is%202.7%20GHz%2C%20compared%20to%202.3%20GHz%20in%20the%20widely%20used%20Gen5%20hardware.%20However%2C%20unlike%20Gen5%2C%20all%20Fsv2%20cores%20in%20a%20machine%20can%20simultaneously%20increase%20processor%20frequency%20up%20to%203.4%20GHz%20in%20response%20to%20increased%20load.%20A%20single%20core%20can%20further%20burst%20to%203.7%20GHz.%3C%2FP%3E%0A%3CP%3EThis%20makes%20Fsv2%20hardware%20very%20attractive%20for%20running%20compute-intensive%20database%20workloads%2C%20such%20as%20OLTP%20workloads%20dominated%20by%20many%20small%20queries.%20Higher%20clock%20speed%20on%20Fsv2%20results%20in%20faster%20response%20time%20for%20individual%20queries%2C%20and%20in%20a%20significant%20cumulative%20gain%20in%20workload%20throughput.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CH2%20id%3D%22toc-hId--732466758%22%20id%3D%22toc-hId--732466758%22%3EComparing%20performance%20between%20Gen5%20and%20Fsv2%20hardware%3C%2FH2%3E%0A%3CP%3EHow%20does%20Fsv2%20compare%20to%20existing%20Gen5%20hardware%20that%20is%20broadly%20used%20in%20Azure%20SQL%20Database%20today%3F%20To%20see%20the%20difference%20in%20performance%20between%20Gen5%20and%20Fsv2%20for%20a%20typical%20OLTP%20workload%2C%20we%20ran%20a%20%3CA%20href%3D%22https%3A%2F%2Fwww.hammerdb.com%2F%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3EHammerDB%3C%2FA%3E%20test%20with%2060%20virtual%20users%20against%20two%20copies%20of%20the%20same%2050%20GB%20database%2C%20one%20using%20Gen5%20hardware%2C%20and%20one%20using%20Fsv2%20hardware.%20Since%20during%20preview%20Fsv2%20databases%20were%20available%20only%20with%2072%20cores%2C%20we%20used%20an%2080-core%20Gen5%20database%20as%20the%20closest%20match.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EPerformance%20metrics%20for%20the%20two%20tests%20were%20visualized%20on%20a%20Grafana%20%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fazure-sql-database%2Fmonitoring-azure-sql-database-with-telegraf%2Fba-p%2F882790%22%20target%3D%22_blank%22%20rel%3D%22noopener%22%3Edashboard%3C%2FA%3E.%20Here%20is%20a%20screenshot%20of%20the%20dashboard%20for%20the%20Gen5%20database%20during%20the%20test%3A%3C%2FP%3E%0A%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-center%22%20image-alt%3D%22Gen5-HammerDB-2.png%22%20style%3D%22width%3A%20999px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Fgxcuf89792.i.lithium.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F168734i817755EE01F9AA86%2Fimage-size%2Flarge%3Fv%3D1.0%26amp%3Bpx%3D999%22%20title%3D%22Gen5-HammerDB-2.png%22%20alt%3D%22Gen5-HammerDB-2.png%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EAnd%20here%20is%20the%20same%20dashboard%20for%20the%20Fsv2%20database%3A%3C%2FP%3E%0A%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22Fsv2-HammerDB-2.png%22%20style%3D%22width%3A%20999px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Fgxcuf89792.i.lithium.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F168735iE9DAA0402BB7BB88%2Fimage-size%2Flarge%3Fv%3D1.0%26amp%3Bpx%3D999%22%20title%3D%22Fsv2-HammerDB-2.png%22%20alt%3D%22Fsv2-HammerDB-2.png%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3EIn%20these%20tests%2C%20Fsv2%20achieved%205%2C571%20batch%20requests%2Fsecond%20on%20average%20during%20a%20representative%20time%20interval%2C%20while%20Gen5%20achieved%204%2C596%20batch%20requests%2Fsecond%20in%20a%20similar%20time%20interval.%20In%20other%20words%2C%20Fsv2%20overperformed%20Gen5%20by%2019%25%2C%20even%20though%20Gen5%20had%208%20more%20cores.%20Normalizing%20throughput%20by%20core%2C%20and%20compensating%20for%20the%20difference%20in%20the%20number%20of%20cores%2C%20%3CSTRONG%3EFsv2%20overperformed%20Gen5%20by%2030%25%3C%2FSTRONG%3E%20for%20this%20OLTP%20workload.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EDoes%20higher%20clock%20speed%20of%20Fsv2%20help%20workloads%20other%20than%20OLTP%3F%20By%20how%20much%20could%20it%20improve%20analytical%20queries%3F%20To%20find%20out%2C%20we%20wrote%20a%20typical%20aggregation%20query%2C%20and%20ran%20it%20against%20the%20same%20two%20databases.%20We%20used%20both%20serial%20and%20parallel%20query%20execution%20to%20see%20the%20performance%20impact%20of%20query%20parallelism%20on%20different%20hardware.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-sql%22%3E%3CCODE%3ESELECT%20o.o_w_id%2C%0A%20%20%20%20%20%20%20SUM(ol.ol_amount)%20AS%20w_amount%2C%0A%20%20%20%20%20%20%20COUNT_BIG(ol.ol_quantity)%20AS%20w_quantity%0AFROM%20dbo.orders%20AS%20o%0AINNER%20JOIN%20dbo.order_line%20AS%20ol%0AON%20o.o_id%20%3D%20ol.ol_o_id%0AGROUP%20BY%20o.o_w_id%0AORDER%20BY%20o.o_w_id%0AOPTION%20(MAXDOP%20N)%3B%0A%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EQuery%20duration%20was%20as%20follows%3A%3C%2FP%3E%0A%3CTABLE%20style%3D%22height%3A%2090px%3B%20border-style%3A%20none%3B%22%3E%0A%3CTBODY%3E%0A%3CTR%20style%3D%22height%3A%2030px%3B%22%3E%0A%3CTD%20style%3D%22width%3A%20216px%3B%20height%3A%2030px%3B%22%3E%0A%3CP%3E%3CSTRONG%3E%26nbsp%3B%3C%2FSTRONG%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20style%3D%22width%3A%20214px%3B%20height%3A%2030px%3B%22%3E%0A%3CP%3E%3CSTRONG%3EMAXDOP%201%3C%2FSTRONG%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20style%3D%22width%3A%20193px%3B%20height%3A%2030px%3B%22%3E%0A%3CP%3E%3CSTRONG%3EMAXDOP%208%3C%2FSTRONG%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3C%2FTR%3E%0A%3CTR%20style%3D%22height%3A%2030px%3B%22%3E%0A%3CTD%20style%3D%22width%3A%20216px%3B%20height%3A%2030px%3B%22%3E%0A%3CP%3E%3CSTRONG%3EGen5%3C%2FSTRONG%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20style%3D%22width%3A%20214px%3B%20height%3A%2030px%3B%22%3E%0A%3CP%3E126%20seconds%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20style%3D%22width%3A%20193px%3B%20height%3A%2030px%3B%22%3E%0A%3CP%3E17%20seconds%3C%2FP%3E%0A%3C%2FTD%3E%0A%3C%2FTR%3E%0A%3CTR%20style%3D%22height%3A%2030px%3B%22%3E%0A%3CTD%20style%3D%22width%3A%20216px%3B%20height%3A%2030px%3B%22%3E%0A%3CP%3E%3CSTRONG%3EFsv2%3C%2FSTRONG%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20style%3D%22width%3A%20214px%3B%20height%3A%2030px%3B%22%3E%0A%3CP%3E97%20seconds%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20style%3D%22width%3A%20193px%3B%20height%3A%2030px%3B%22%3E%0A%3CP%3E11%20seconds%3C%2FP%3E%0A%3C%2FTD%3E%0A%3C%2FTR%3E%0A%3C%2FTBODY%3E%0A%3C%2FTABLE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EFor%20this%20analytical%20query%2C%20Fsv2%20again%3CSTRONG%3E%20overperformed%20Gen5%20by%2026%25%20%3C%2FSTRONG%3Eat%20MAXDOP%201%2C%20and%3CSTRONG%3E%20by%2043%25%20%3C%2FSTRONG%3Eat%20MAXDOP%208.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CH2%20id%3D%22toc-hId-1755046075%22%20id%3D%22toc-hId-1755046075%22%3EChoosing%20between%20Fsv2%20and%20other%20hardware%20generations%3C%2FH2%3E%0A%3CP%3EHow%20should%20you%20choose%20between%20Fsv2%20and%20other%20hardware%20in%20Azure%20SQL%20Database%2C%20such%20as%20Gen5%20or%20M-series%3F%20Not%20surprisingly%2C%20the%20answer%20largely%20depends%20on%20workload%20characteristics.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EAs%20we%20have%20just%20shown%2C%20faster%20clock%20speed%20clearly%20has%20a%20big%20advantage%20for%20OLTP%20and%20analytical%20workloads%20dominated%20by%20CPU-bound%20queries.%20However%2C%20Fsv2%20has%20less%20memory%20per%20core%20than%20Gen5%20(1.89%20GB%2Fcore%20vs.%205.1%20GB%2Fcore)%2C%20so%20for%20IO-intensive%20workloads%20that%20require%20more%20memory%20for%20the%20buffer%20pool%20(data%20cache)%2C%20the%20benefits%20of%20higher%20clock%20speed%20may%20be%20offset%20by%20higher%20cumulative%20storage%20IO%20waits%20due%20to%20more%20frequent%20reads%20from%20storage.%20Similarly%2C%20analytical%20queries%20that%20require%20large%20memory%20grants%20may%20have%20to%20wait%20for%20other%20queries%20to%20complete%20and%20release%20memory%2C%20before%20they%20can%20acquire%20a%20grant.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThe%20%E2%80%9Csweet%20spot%E2%80%9D%20for%20Fsv2%20are%20CPU-bound%20workloads%20that%20do%20not%20require%20a%20large%20buffer%20pool%2C%20or%20many%20large%20memory%20grants.%20The%20workload%20should%20also%20have%20low%20to%20moderate%20%3CI%3Etempdb%3C%2FI%3E%20space%20usage%2C%20because%20Fsv2%20has%20less%20local%20SSD%20storage%20for%20the%20%3CI%3Etempdb%3C%2FI%3E%20database.%20IO-bound%20workloads%20that%20require%20more%20memory%20for%20the%20buffer%20pool%2C%20or%20workloads%20requiring%20a%20large%20%3CI%3Etempdb%3C%2FI%3E%20database%2C%20will%20likely%20work%20better%20on%20Gen5%20or%20M-series%20hardware.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ESince%20local%20SSD%20storage%20space%20is%20limited%20on%20Fsv2%2C%20this%20hardware%20is%20only%20available%20in%20the%20-ERR%3AREF-NOT-FOUND-General%20Purpose%20service%20tier%20that%20uses%20remote%20Azure%20Premium%20storage.%20Workloads%20that%20require%20low%20latency%20local%20SSD%20storage%2C%20or%20higher%20availability%20provided%20by%20fast%20failovers%2C%20will%20work%20better%20on%20Gen5%20or%20M-series%20hardware%20in%20the%20-ERR%3AREF-NOT-FOUND-Business%20Critical%20service%20tier.%20Workloads%20that%20use%20very%20large%20databases%20(up%20to%20100%20TB)%2C%20and%2For%20need%20multiple%20readable%20replicas%2C%20fast%20scaling%2C%20and%20fast%20database%20restore%2C%20will%20work%20best%20in%20the%20-ERR%3AREF-NOT-FOUND-Hyperscale%20service%20tier.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ERegardless%20of%20hardware%20used%2C%20tuning%20a%20workload%20to%20reduce%20unnecessary%20data%20IO%20improves%20performance%2C%20often%20changing%20a%20workload%20from%20being%20IO-bound%20to%20being%20CPU-bound%2C%20and%20thus%20able%20to%20benefit%20from%20higher%20CPU%20clock%20speed%20of%20Fsv2.%20The%20-ERR%3AREF-NOT-FOUND-Automatic%20tuning%20features%20of%20Azure%20SQL%20Database%20help%20you%20reduce%20data%20IO%20by%20using%20optimal%20indexes%20and%20avoiding%20query%20plan%20regressions.%20Additional%20improvements%20can%20be%20achieved%20via%20-ERR%3AREF-NOT-FOUND-manual%20query%20performance%20tuning.%20For%20well-tuned%20workloads%20that%20are%20primarily%20limited%20by%20CPU%20clock%20speed%2C%20Fsv2%20is%20an%20excellent%20hardware%20choice%20that%20will%20improve%20query%20response%20time%20and%20workload%20throughput.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CH2%20id%3D%22toc-hId--52408388%22%20id%3D%22toc-hId--52408388%22%3EConclusion%3C%2FH2%3E%0A%3CP%3EFsv2-series%20is%20a%20new%20hardware%20option%20in%20Azure%20SQL%20Database%20that%20complements%20existing%20Gen5%20and%20M-series%20hardware%20and%20is%20targeted%20toward%20CPU-intensive%20workloads%2C%20where%20it%20can%20%3CSTRONG%3Eimprove%20query%20response%20time%20and%20workload%20throughput%20by%2020-40%25%3C%2FSTRONG%3E%20compared%20to%20Gen5%20hardware.%20While%20during%20preview%20only%20the%20largest%20Fsv2%20databases%20with%2072%20cores%20were%20available%2C%20smaller%20SKUs%20are%20now%20available%20with%20General%20Availability%20of%20Fsv2%20hardware%2C%20letting%20a%20broad%20range%20of%20customers%20evaluate%20Fsv2-series%20for%20their%20new%20and%20existing%20Azure%20SQL%20Database%20workloads%2C%20and%20take%20advantage%20of%20performance%20improvements%20provided%20by%20fast%20CPUs%20of%20Fsv2%20hardware.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-TEASER%20id%3D%22lingo-teaser-1148901%22%20slang%3D%22en-US%22%3E%3CP%3EFor%20CPU-bound%20workloads%2C%20Fsv2%20can%20improve%20query%20response%20time%20and%20workload%20throughput%20by%2020-40%25%2C%20compared%20to%20Gen5%20hardware.%3C%2FP%3E%3C%2FLINGO-TEASER%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1148901%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EPerformance%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
Microsoft

Executive summary

For CPU-bound workloads, Fsv2 can improve query response time and workload throughput by 20-40%, compared to Gen5 hardware.

 

What is Fsv2-series hardware?

At the Ignite conference in November 2019, we introduced the preview of two new hardware generations in Azure SQL Database, M-series and Fsv2-series. In a previous blog post, we described a workload that achieved 3x scalability using M-series hardware. In this post, we will take a closer look at the Fsv2-series hardware, now Generally Available for single databases and elastic pools in the General Purpose service tier.

 

The most notable feature of Fsv2 virtual machines in Azure is high CPU clock speed. The base processor frequency in these machines is 2.7 GHz, compared to 2.3 GHz in the widely used Gen5 hardware. However, unlike Gen5, all Fsv2 cores in a machine can simultaneously increase processor frequency up to 3.4 GHz in response to increased load. A single core can further burst to 3.7 GHz.

This makes Fsv2 hardware very attractive for running compute-intensive database workloads, such as OLTP workloads dominated by many small queries. Higher clock speed on Fsv2 results in faster response time for individual queries, and in a significant cumulative gain in workload throughput.

 

Comparing performance between Gen5 and Fsv2 hardware

How does Fsv2 compare to existing Gen5 hardware that is broadly used in Azure SQL Database today? To see the difference in performance between Gen5 and Fsv2 for a typical OLTP workload, we ran a HammerDB test with 60 virtual users against two copies of the same 50 GB database, one using Gen5 hardware, and one using Fsv2 hardware. Since during preview Fsv2 databases were available only with 72 cores, we used an 80-core Gen5 database as the closest match.

 

Performance metrics for the two tests were visualized on a Grafana dashboard. Here is a screenshot of the dashboard for the Gen5 database during the test:

Gen5-HammerDB-2.png

 

And here is the same dashboard for the Fsv2 database:

Fsv2-HammerDB-2.png

In these tests, Fsv2 achieved 5,571 batch requests/second on average during a representative time interval, while Gen5 achieved 4,596 batch requests/second in a similar time interval. In other words, Fsv2 overperformed Gen5 by 19%, even though Gen5 had 8 more cores. Normalizing throughput by core, and compensating for the difference in the number of cores, Fsv2 overperformed Gen5 by 30% for this OLTP workload.

 

Does higher clock speed of Fsv2 help workloads other than OLTP? By how much could it improve analytical queries? To find out, we wrote a typical aggregation query, and ran it against the same two databases. We used both serial and parallel query execution to see the performance impact of query parallelism on different hardware.

 

SELECT o.o_w_id,
       SUM(ol.ol_amount) AS w_amount,
       COUNT_BIG(ol.ol_quantity) AS w_quantity
FROM dbo.orders AS o
INNER JOIN dbo.order_line AS ol
ON o.o_id = ol.ol_o_id
GROUP BY o.o_w_id
ORDER BY o.o_w_id
OPTION (MAXDOP N);

 

Query duration was as follows:

 

MAXDOP 1

MAXDOP 8

Gen5

126 seconds

17 seconds

Fsv2

97 seconds

11 seconds

 

For this analytical query, Fsv2 again overperformed Gen5 by 26% at MAXDOP 1, and by 43% at MAXDOP 8.

 

Choosing between Fsv2 and other hardware generations

How should you choose between Fsv2 and other hardware in Azure SQL Database, such as Gen5 or M-series? Not surprisingly, the answer largely depends on workload characteristics.

 

As we have just shown, faster clock speed clearly has a big advantage for OLTP and analytical workloads dominated by CPU-bound queries. However, Fsv2 has less memory per core than Gen5 (1.89 GB/core vs. 5.1 GB/core), so for IO-intensive workloads that require more memory for the buffer pool (data cache), the benefits of higher clock speed may be offset by higher cumulative storage IO waits due to more frequent reads from storage. Similarly, analytical queries that require large memory grants may have to wait for other queries to complete and release memory, before they can acquire a grant.

 

The “sweet spot” for Fsv2 are CPU-bound workloads that do not require a large buffer pool, or many large memory grants. The workload should also have low to moderate tempdb space usage, because Fsv2 has less local SSD storage for the tempdb database. IO-bound workloads that require more memory for the buffer pool, or workloads requiring a large tempdb database, will likely work better on Gen5 or M-series hardware.

 

Since local SSD storage space is limited on Fsv2, this hardware is only available in the General Purpose service tier that uses remote Azure Premium storage. Workloads that require low latency local SSD storage, or higher availability provided by fast failovers, will work better on Gen5 or M-series hardware in the Business Critical service tier. Workloads that use very large databases (up to 100 TB), and/or need multiple readable replicas, fast scaling, and fast database restore, will work best in the Hyperscale service tier.

 

Regardless of hardware used, tuning a workload to reduce unnecessary data IO improves performance, often changing a workload from being IO-bound to being CPU-bound, and thus able to benefit from higher CPU clock speed of Fsv2. The Automatic tuning features of Azure SQL Database help you reduce data IO by using optimal indexes and avoiding query plan regressions. Additional improvements can be achieved via manual query performance tuning. For well-tuned workloads that are primarily limited by CPU clock speed, Fsv2 is an excellent hardware choice that will improve query response time and workload throughput.

 

Conclusion

Fsv2-series is a new hardware option in Azure SQL Database that complements existing Gen5 and M-series hardware and is targeted toward CPU-intensive workloads, where it can improve query response time and workload throughput by 20-40% compared to Gen5 hardware. While during preview only the largest Fsv2 databases with 72 cores were available, smaller SKUs are now available with General Availability of Fsv2 hardware, letting a broad range of customers evaluate Fsv2-series for their new and existing Azure SQL Database workloads, and take advantage of performance improvements provided by fast CPUs of Fsv2 hardware.