Performance Bottlenecks with iSCSI Loopback Targets Under Heavy Database Workloads

Question

Hi guys

We are running a high-performance database workload that relies on locally hosted iSCSI loopback targets to present virtual disks to the operating system. During periods of sustained random-write activity, storage performance degrades significantly, and we are seeing signs of queue saturation along with increased I/O latency.

Initial analysis suggests that the iSCSI loopback component may be exhausting available system worker threads, causing requests to back up under load.

My question is : Are there any supported methods to increase thread scalability, tune queue handling, or optimize the iSCSI loopback configuration to better support intensive database workloads ?

Answer 1

Hello,

your analysis is correct: the iSCSI loopback initiator/target stack in Windows is not designed for extremely heavy random‑write workloads, and under sustained pressure it can exhaust system worker threads and saturate queues. This is because the loopback path still traverses the full TCP/IP stack and kernel networking components, so every I/O request is subject to thread pool scheduling and queue depth limits.

There are supported methods to improve scalability, but they are limited. The first lever is the system thread pool configuration. By default, iSCSI uses kernel worker threads that scale with CPU count, but you can increase concurrency by tuning the registry values under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters and HKLM\SYSTEM\CurrentControlSet\Services\iScsiPrt\Parameters. In particular, the MaxPendingRequests and MaxRequestHoldTime keys can be adjusted to allow more outstanding requests before the initiator throttles. Microsoft documents these parameters for iSCSI initiator tuning, and they are safe to modify within supported ranges.

Second, queue handling can be influenced by adjusting the iSCSI service’s MaxConnectionsPerSession and MaxTransferLength values. These control how many concurrent operations can be outstanding per target session and how large each transfer can be. For database workloads with small random writes, lowering MaxTransferLength can reduce latency spikes, while increasing MaxConnectionsPerSession allows more parallelism.

Third, you should verify that the loopback target is configured with sufficient outstanding I/O depth. The Microsoft iSCSI Software Target has parameters for OutstandingRequests that can be tuned. If you are using the built‑in Windows iSCSI Target, check HKLM\SYSTEM\CurrentControlSet\Services\WinTarget\Parameters. Raising the outstanding request limit helps prevent queue saturation.

That said, Microsoft generally does not recommend iSCSI loopback for high‑performance database workloads. The supported best practice is to use native VHDX files or Storage Spaces Direct volumes rather than presenting local disks back to the OS via iSCSI. Loopback adds unnecessary protocol overhead. If you must continue with iSCSI loopback, the safe path is to tune the registry parameters mentioned above, monitor with Performance Monitor counters (MSiSCSI Request Queue Length, Avg. Disk sec/Write), and ensure that the system has sufficient CPU cores to handle the additional thread load.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo.