Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
Welcome back to this series. In the first two part of the series we discussed how to collect disk usage data, and how to read and analyze the collected data.
In this series, I will discuss how to use this information to choose which disks to use if your environment is deployed in Azure.
Azure provides several different disk types that offer different performance.
I will not go over basic disks but will focus on the premium storage.
Before we dig in, you need to keep in mind that disks must reside on a storage account, and that storage accounts have a limit in IOPS and throughput. For an individual machine those values are pretty high meaning you will not reach them with a single VM but if you have multiple disks from multiple VMs, that is something to take into account.
VMs themselves has max IOPS and Throughput limit which you cannot go over even if you toss more disks at them, so you should choose your VM series carefully to have a VM that can reach your needs. Again, those thresholds are typically pretty high and not the usual limiting factor, but you should still review this.
Let’s now review the different disks available.
Here is the data from the time of writing this blog.
Latest information can be found here as Azure is constantly evolving to bring more capacity and performance:
If you’ve followed part 2 of the series, you might remember that the sample data showed peak values (after which latency occurred) of 4300 IOPS, and about 200 MB/sec throughput, using blocking size on average of 56 KB.
Turns out the data from this machine was coming from Azure hosted machine that as using a single P30 disk.
Unsurprisingly the max performance reach corresponds with the disk specs: 200 MB/s
This is indeed what was being achieved. While the IOPS could have gone higher it did not because the throughput limit was reached. Had this machine used 2 P20, well probably we would have reached higher IOPS (2300*2 is 4600 IOPS limit) and better throughput (150*2 is 300 MB/s throughput). Realistically it would have capped shortly later, but still we can see that for this use case 2 P20s might have been slightly better (though probably still not enough).
Now just hold on there for a minute before you conclude that I recommend P20s for your SQL server for Dynamics. I don’t! It all depends on your usage pattern! In this very specific case it would have made sense. Is this always true? NO! Analyze first.
SQL has a lot of different block size patterns and from very small 2-8 KB to very big 256 KB and more. You will need to figure out when / if you are maxing your requirements throughout the daily process, and dive into that period to see what the block size is being used.
From this observation we can conclude that choosing the right type of disks is very important because the disks don’t have the same specs. Meaning 2 P20 while giving you the same capacity (1 TB) don’t provide you the same IOPS and throughput.
Let’s make some calculations. I will call this the “sweet spot” as in, what is the optimal block size for given disk type meaning at which block size do we hit the IOPS cap and the throughput cap simultaneously (meaning there is no “waste”).
As we can see depending on the disk type this sweet spot varies greatly.
If your observations show that you are doing mostly 64 KB operations (common value found in tempdb but don’t take my word for it, it varies from customer to customer), then you are probably better of stacking P20s until you reach your requirements as it will be more efficient than using P30s.
Let’s put that in perspective.
At 64 Kb blocks, the “max” you will reach is the following:
This favors 2 P20 overs 1 P30.
However, if your block sizes are more 32 KB or perhaps even lower then you get the following:
This favores 1 P30 over 2 P20.
Therefore, it’s extremely important to have a look not only at what your IOPS requirement, but also what is the size of those IO operations aka what is the throughput required to choose the best possible disks as it will determine which cap gets hit first. You should of course put this into perspective with your needs as measure in part 2 of the series.
In this concluding part of the series we’ve discussed the difference between the different Azure premium disks and how to use the data collected and analyzed in the previous parts of the series to choose the best disk options.
Hope you enjoyed reading this blog.
Premier Field Engineer
Business Applications communities