Intermittent connection pool exhaustion symptoms during high TCP concurrency on Windows 11

An imbalance in Receive Side Scaling (RSS) queue distribution can produce symptoms that resemble intermittent connection pool exhaustion, but it does not physically exhaust the TCP port range or the application's configured pool size. Instead, skewed RSS distribution can saturate specific CPU cores with network interrupt processing, delaying TCP handshake completion and ACK generation. When request threads stall waiting for network I/O, the application pool appears exhausted even though system-wide resources remain available.

RSS Counter Patterns That Indicate Imbalance

During a load event, collect these counters without changing adapter state, and sample them alongside your connection-pool metrics:

• Processor\% Interrupt Time per core: A single core (often Core 0 or a queue-affinitized core) shows sustained high interrupt time while other logical processors remain idle.
• Processor\% Processor Queue Length per core: A high queue length on the same cores indicates that packet processing is serialized rather than parallelized.
• Network Interface\Packets Received broken down by RSS queue ID, where the driver supports it: Significant variance across queues means the 4-tuple hash is not distributing flows evenly.

If per-core interrupt time or queue length spikes align temporally with pool-acquisition timeouts, the imbalance is a plausible contributor. If pool metrics degrade while interrupt counters stay flat, the cause is more likely pool sizing or connection leaks.

NumberOfReceiveQueues vs. Logical Processor Count

The relationship between the driver-reported NumberOfReceiveQueues and the total logical processor count determines how much parallel receive processing is possible:

• Under-provisioned queues: If NumberOfReceiveQueues is significantly lower than the logical processor count, interrupt handling is concentrated on too few cores. Under sustained high TCP concurrency, those cores become bottlenecks, delaying the TCP state machine and causing application-level timeouts.
• Restricted affinity: If RSS queues are affinitized to a subset of cores, those cores saturate before the rest of the system is utilized, producing the same stall pattern.
• Driver override: The NIC driver's reported queue count can override Windows 11 settings, so software-level configuration may not change the active queue count.

Verification Without Changing Adapter State

Run these read-only checks in an administrative PowerShell session:

Get-NetAdapterRss
netsh int tcp show global

Compare NumberOfReceiveQueues from Get-NetAdapterRss against the logical processor count. Also verify that TCP Chimney Offload or NetDMA is not interfering with RSS behavior, since these features can mask the root cause. Note that not all drivers expose per-queue counters in Performance Monitor; consult the NIC vendor's diagnostics if the queue-level view is unavailable.

One Diagnostic Detail That Changes the Recommendation

Are the observed failures immediate timeouts during connection establishment (suggesting interrupt-processing latency), or are they 'no available slots' errors only during sustained peak load (suggesting a genuine pool-sizing or connection-leak issue)?