Acumatica Performance — Diagnosing Slow Disk I/O

Disk I/O problems on Acumatica present as generalized slowness across everything at once — every screen, every report, every batch job runs at half the normal speed simultaneously — which is exactly why they get misdiagnosed as "the ERP is slow" rather than traced to storage, the layer nobody thinks to check because it usually just works.

Which disk is actually the bottleneck

Acumatica-relevant I/O happens in three separate places, and only one of them is usually the real culprit: the SQL Server data files (.mdf/.ndf), the SQL Server transaction log file (.ldf), and the app server's local disk (mostly irrelevant unless file attachments are stored on local disk rather than blob storage, or the app pool's temp directories are under pressure). Transaction log I/O is the one that catches people off guard — it is write-heavy and latency-sensitive in a way data file reads are not, because every write transaction must be durably logged before it commits, full stop, no shortcuts.

SELECT
    DB_NAME(vfs.database_id) AS db_name,
    mf.physical_name,
    vfs.io_stall_read_ms, vfs.num_of_reads,
    vfs.io_stall_write_ms, vfs.num_of_writes,
    (vfs.io_stall_read_ms + vfs.io_stall_write_ms) AS total_stall_ms
FROM sys.dm_io_virtual_file_stats(NULL, NULL) vfs
JOIN sys.master_files mf ON mf.database_id = vfs.database_id
    AND mf.file_id = vfs.file_id
WHERE DB_NAME(vfs.database_id) = 'AcumaticaProd'
ORDER BY total_stall_ms DESC;

Divide stall time by read/write count to get average latency per operation. Data file reads averaging over roughly 10-20ms, or log writes averaging over 1-2ms, indicate the storage layer is the constraint — those thresholds are conservative rules of thumb for spinning or shared network storage; NVMe-backed storage should be an order of magnitude faster and any sustained latency near those numbers on flash storage points at contention, not raw hardware capability.

The transaction log specifically

• Log file not pre-sized, growing in small increments during peak load. Every autogrow event briefly stalls writes. Pre-size the log file generously and set growth increments in fixed MB, not a percentage, so growth events shrink over time rather than getting larger as the file grows.
• Wrong recovery model expectations. Full recovery model (the correct choice for a production ERP needing point-in-time restore) means the log only truncates on a log backup — infrequent log backups on a busy instance let the log grow unchecked and can force autogrow storms. Match log backup frequency to write volume, not a generic "nightly" default.
• Log and data files sharing the same physical volume as each other, or as other busy databases. Sequential log writes and random data file reads compete for the same disk queue, and I/O from an unrelated database on the same volume shows up as unexplained Acumatica latency. Separate volumes for data, log, and tempdb where the deployment topology allows it.

If you are on cloud-provisioned storage

Provisioned IOPS storage (Azure managed disks, AWS EBS, and similar) has a hard ceiling based on the disk tier you selected, not the instance size — you can have a large, fast VM attached to an undersized disk tier and never see the VM's own limits. Check the cloud provider's disk metrics for throttling, not just SQL Server's own DMVs, because SQL Server reports the latency it experiences without necessarily surfacing that the cause is a provisioned IOPS cap being hit.

Wrapping up

Confirm disk I/O is the actual bottleneck with sys.dm_io_virtual_file_stats before spending money on faster storage. Separate log, data, and tempdb I/O in your analysis since they have different characteristics and different fixes, pre-size files to avoid autogrow stalls, and check cloud provisioned-IOPS limits separately from what SQL Server itself reports.