Optimize IO disk performance for your Azure storage

In some cases, people need to migrate their application farms and database servers to Microsoft Azure in specific region. While they may propose to install SQL Server with SQL AlwaysOn enabled in Azure VM under Azure Standard storage, there is always a concern that should be paid more attention- the performance.


While some companies may feel the performance is not satisfactory,  we may help apply an efficient and effective approach with Microsoft backend support, to find out the optimal number of disks (IOPS) and disk latency by measuring how their workloads utilize disk I/O. By do it so, not only could we determine how many Azure data disks should be used, but we also found out that IOPS might not be the only factor to  the cloud storage performance.

 

Understanding storage IOPS and disk latency

When you install SQL Server AlwaysOn on Microsoft Azure VM, most of Azure users know that increasing numbers of data disk, optimizing your application and getting higher IOPS and throughput, will affect the latency of your applications. Meanwhile, if we use more striped disks, it will take time to split IO to each single disk and the latency would become higher.

No. of  disks

IOPS

Maximum Throughput

Latency

Higher

No. of  disks

IOPS

Maximum Throughput

Latency

Lower

According to the Azure Standard storage limitation, the maximum IOPS for each data disk is 500. If you attach 4 disks and combine those in a storage pool, the whole virtual disk will has 2000 IOPS. Seriously you will say that disk performance should not be enough for SQL server I/O operation.  Probably you will try to increase more disks say 16 disks to maximize the total IOPS to 8000. By doing so, the network latency will becomes higher.

 

To leverage the number of disks (IOPS) and disk latency, we can use DiskSpd to measure how your workload utilize disk I/O so as to determine how many Azure data disks should be used.

  1. Download tools from https://aka.ms/DiskSpd
  2. Close all your applications to prevent any obstruction in your results
  3. Open Command Prompt and execute command to simulate high I/O traffic

 

If storage pool contains 12 data disks with maximum 6000 IOPS, trying 30% Write and 70% Read, Command Line:

C:\temp\Diskspd.exe -b8K -d60 -h -L -o32 -t4 -r -w30 -c10240M E:\io.dat

 

Example results:

Input parameters:
        timespan:   1
        -------------
        duration: 60s
        warm up time: 5s
        cool down time: 0s
        measuring latency
        random seed: 0
        path: 'E:\io.dat'
                        think time: 0ms
                        burst size: 0
                        software and hardware write cache disabled
                        performing mix test (write/read ratio: 30/100)
                        block size: 8192
                        using random I/O (alignment: 8192)
                        number of outstanding I/O operations: 32
                        thread stride size: 0
                        threads per file: 4
                        using I/O Completion Ports
                        IO priority: normal

Results for timespan 1:
****************************************************************
actual test time:           60.00s
thread count:               4
proc count:                   8

CPU |  Usage |  User  |  Kernel |  Idle
-------------------------------------------
   0|   8.44%|   1.41%|    7.03%|  91.56%
   1|  10.34%|   2.58%|    7.76%|  89.66%
   2|  14.30%|   1.61%|   12.68%|  85.70%
   3|   7.97%|   1.48%|    6.48%|  92.03%
   4|  21.54%|   2.76%|   18.78%|  78.46%
   5|  27.13%|   2.81%|   24.32%|  72.86%
   6|  43.25%|   1.77%|   41.48%|  56.74%
   7|  13.80%|   1.33%|   12.47%|  86.20%
-------------------------------------------
avg.|  18.35%|   1.97%|   16.38%|  81.65%

Total IO
thread | bytes     |     I/Os     |  MB/s  |  I/O per s |  AvgLat  | LatStdDev |  file
------------------------------------------------------------------------
0 |     565190656 |     68993 |    8.98 |    1149.86 |   25.595 |   174.231 | E:\io.dat (10240MB)
1 |     567754752 |     69306 |    9.02 |    1155.08 |   25.517 |   173.493 | E:\io.dat (10240MB)
2 |     560799744 |     68457 |    8.91 |    1140.93 |   25.803 |   178.334 | E:\io.dat (10240MB)
3 |     576176128 |     70334 |    9.16 |    1172.21 |   25.187 |   173.603 | E:\io.dat (10240MB)
------------------------------------------------------------------------
total:  2269921280 |    277090 |   36.08 |    4618.08 |   25.523 |   174.912

Read IO
thread |   bytes   |  I/Os     | MB/s  | I/O per s |  AvgLat  | LatStdDev |  file
------------------------------------------------------------------------
0 |    396009472 |   48341 |     6.29 |  805.67  |   24.447 |   178.984 | E:\io.dat (10240MB)
1 |    398966784 |   48702 |     6.34 |  811.68  |   24.473 |   182.232 | E:\io.dat (10240MB)
2 |    393478144 |   48032 |     6.25 |  800.52  |   24.303 |   180.230 | E:\io.dat (10240MB)
3 |    401424384 |   49002 |     6.38 |  816.68  |   23.196 |   166.347 | E:\io.dat (10240MB)
------------------------------------------------------------------------
total:1589878784| 194077 | 25.27 | 3234.55 |   24.102 |   177.028

Write IO
thread |  bytes    |     I/Os   | MB/s  |  I/O per s |  AvgLat  | LatStdDev |  file
------------------------------------------------------------------------
0 |     169181184 |   20652 |    2.69 |     344.19 |   28.281 |   162.534 | E:\io.dat (10240MB)
1 |     168787968 |   20604 |    2.68 |     343.39 |   27.983 |   150.808 | E:\io.dat (10240MB)
2 |     167321600 |   20425 |    2.66 |     340.41 |   29.331 |   173.742 | E:\io.dat (10240MB)
3 |     174751744 |   21332 |    2.78 |     355.53 |   29.760 |   189.142 | E:\io.dat (10240MB)
-----------------------------------------------------------------------
total: 680042496 |   83013 |  10.81 |  1383.52 |   28.846 |   169.817

  %-ile |  Read (ms) | Write (ms) | Total (ms)
----------------------------------------------
    min |      3.744 |      4.636 |      3.744
   25th |      4.865 |      6.204 |      5.102
   50th |      5.482 |      7.094 |      6.002
   75th |      6.878 |     13.560 |      8.224
   90th |     42.896 |     61.722 |     49.937
   95th |    118.578 |    130.949 |    122.245
   99th |    205.580 |    223.833 |    212.317
3-nines |    641.242 |    654.790 |    644.091
4-nines |   6711.376 |   6706.785 |   6709.961
5-nines |   8614.824 |   7154.982 |   8524.186
6-nines |   8638.330 |   7154.982 |   8638.330
7-nines |   8638.330 |   7154.982 |   8638.330
8-nines |   8638.330 |   7154.982 |   8638.330
    max |   8638.330 |   7154.982 |   8638.330

Summary

By using DiskSpd , you can allocate a suitable number of disks to optimize disk latency by measuring the total I/O per second and average latency for Azure VM under your Azure subscription and region, and identifying the best approach to achieve your cloud storage performance.
Microsoft reference

Advertisements

One thought on “Optimize IO disk performance for your Azure storage

  1. Pingback: Part 1- How Azure Network Security Group helps architect your Azure networking | KBQuest Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s