very low disk transfer rates

Alex Vengerovsky 0 Reputation points
2026-08-05T16:02:04.5866667+00:00

On my vm (AlexVM)I I observe disk transfer rates during regular SQL Server insert operation between 12 and 6 MB/s which is extremely low even for standard disks. Please advise.

SQL Server on Azure Virtual Machines
0 comments

2 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-08-05T16:02:26.5233333+00:00

    For SQL Server on Azure VMs, 6–12 MB/s during inserts usually points to either I/O throttling or latency without throttling.

    Start with the Storage pane of the SQL virtual machine resource in Azure portal. That view is designed to identify whether the issue is:

    • VM level I/O throttling
    • Disk level I/O throttling
    • Latency without throttling

    A practical check path is:

    1. In Azure portal, open the SQL virtual machine resource for AlexVM.
    2. Go to Storage and review the I/O Analysis results from the last 24 hours.
    3. Check whether any of these VM metrics are near 100%:
      • VM Cached IOPS Consumed Percentage
      • VM Cached Bandwidth Consumed Percentage
      • VM Uncached IOPS Consumed Percentage
      • VM Uncached Bandwidth Consumed Percentage
    4. Check whether disk metrics show saturation, especially:
      • Data Disk IOPS Consumed Percentage
      • Data Disk Bandwidth Consumed Percentage

    If disk IOPS is the bottleneck, common causes include:

    • Small disk size, which limits available IOPS
    • Lower-performance disk type
    • Temporary workload spikes
    • Unoptimized disk stripe size

    Supported mitigations are:

    • Optimize SQL queries and database design to reduce unnecessary I/O
    • Use a disk type that matches the workload, such as Standard SSD or Premium SSD
    • Use larger disk sizes to increase available IOPS
    • Distribute I/O across multiple data disks using RAID configurations

    If disk bandwidth is the bottleneck, common causes include:

    • Large data transfers
    • Bulk loads, updates, or imports
    • Reporting, analytics, or ETL activity
    • Backup/restore activity
    • Parallel query execution
    • Elevated network traffic affecting data disk bandwidth availability
    • Concurrent data-intensive operations on the same disk

    Supported mitigations are:

    • Minimize unnecessary data movement
    • Consider higher-performance disks such as Premium SSD or Premium SSD v2
    • Distribute data across multiple disks
    • Optimize and parallelize queries and data processing to reduce data movement
    • Use compression and efficient storage mechanisms
    • Monitor metrics and scale storage as needed

    If the portal shows high disk latency without throttling, investigate VM-side resource pressure instead of disk limits. Documented causes include:

    • High CPU utilization
    • Insufficient VM memory
    • Background processes such as antivirus, backups, maintenance tasks, or Windows Update
    • Missing antivirus exclusions for SQL Server workloads

    Also note that long I/O warnings in SQL Server indicate the underlying I/O system should be investigated rather than SQL Server itself. Heavy sequential operations such as backup/restore, table scans, sorting, index creation, bulk loads, and zeroing files can aggravate long I/O behavior.

    For SQL Server workloads, the documented guidance is to choose an appropriate VM size because IOPS and throughput can also be throttled at the VM level. Memory-optimized series such as Ebdsv5, M, and Mv2 are called out as generally recommended for SQL Server workloads.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Peram Venkateswara Reddy 260 Reputation points Microsoft External Staff Moderator
    2026-08-07T07:53:05.1433333+00:00

    Hi Alex,

    Before troubleshooting, one thing worth checking: 6–12 MB/s may well be normal for an insert workload, and MB/s is probably the wrong metric to be watching.

    SQL Server writes in 8 KB pages, and log writes during inserts are small and synchronous. Azure enforces two independent ceilings — IOPS and throughput — and small-block workloads hit the IOPS ceiling long before the MB/s number on the datasheet. At 8 KB per I/O, 1,000 IOPS is 8 MB/s. You could be 100% throttled and still see exactly the figure you're reporting. So track IOPS, disk latency, and WRITELOG wait time, not transfer rate.

    Start here — it's built for this exact question

    Open the SQL virtual machines resource for AlexVM in the portal → Storage → I/O Analysis. It analyzes the last 24 hours and returns one of three verdicts: no throttling, VM level I/O throttling, or disk level I/O throttling. That single screen tells you which branch below applies.

    Thresholds, so you don't chase spikes

    Metric Problematic condition
    Disk latency > 500 ms over a consecutive 5-min period
    -------- --------
    Disk latency > 500 ms over a consecutive 5-min period
    VM Cached IOPS / Bandwidth Consumed % ≥ 95% over a consecutive 5-min period
    VM Uncached IOPS / Bandwidth Consumed % ≥ 95% over a consecutive 5-min period
    Data Disk IOPS / Bandwidth Consumed % ≥ 95% over a consecutive 5-min period

    Metrics are sampled every 30 seconds and aggregated to the minute. Important caveat: "Some throttling is expected, and is ignored unless there's also disk latency." A brief 100% spike is not a problem — sustained saturation with latency is.

    If it says disk-level throttling: disk IOPS scale with provisioned size, so a small disk caps you regardless of type. Options are a larger disk, a faster type (Premium SSD v2 lets you provision IOPS and throughput independently of size), or striping across multiple data disks. Enable read caching on the data disk if available. Note that changing IOPS/throughput on Premium SSD v1 requires building a new storage pool — worth planning rather than iterating.

    If it says VM-level throttling: the VM caps aggregate I/O regardless of how fast your disks are. Resizing within a series is the easy lever. Memory-optimized series — Ebdsv5, M, Mv2 — are the ones recommended for SQL Server. One constraint: you can't downsize to a VM whose max data disk count is lower than the number you have attached.

    If it says no throttling — this is the branch most people skip. High latency without throttling means the bottleneck is on the VM, not the disks. Documented causes:

    • High CPU utilization
    • Insufficient VM memory
    • Background processes — antivirus, backups, maintenance jobs, Windows Update
    • Missing antivirus exclusions for SQL Server files — very common, and often the whole answer

    Also check SQL Server's error log for long I/O warnings; those point at the storage subsystem rather than SQL itself, and are aggravated by sequential operations like backup/restore, scans, sorts, index builds, and bulk loads.

    Config worth confirming while you're in there

    • Data, log, and tempdb on separate disks — never on the OS disk
    • Read-only host caching on data disks, None on log disks
    • If this is a Marketplace SQL image, the Storage pane also flags best-practice deviations directly

    To narrow this down, could you share:

    1. VM size for AlexVM
    2. Disk type, size, and count for data and log (and current caching setting on each)
    3. What I/O Analysis reports — throttling or no throttling
    4. Whether the inserts are row-by-row or batched/bulk

    A single-row insert loop is latency-bound and will look "slow" in MB/s on any storage tier, including local NVMe — so that last one matters a lot.

    References

    Kind Regards,
    Microsoft Support Team.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.