Dell PowerVault ME5024 iSCSI Performance: High Latency Spikes and Low Sequential Throughput on PVE 9

Sep 10, 2026
4
0
1
Hi everyone,

I am experiencing severe latency spikes and sub-optimal bandwidth when running sequential read workloads over iSCSI from a Proxmox VE node to a Dell PowerVault ME5024 array.

During high I/O tests on Proxmox, the average throughput hovers around 265–300 MiB/s, but the response time spikes dramatically up to 6 seconds (99.9th percentile), causing IOPS to briefly collapse down to single digits before recovering.

For comparison, a VMware ESXi host connected to the exact same ME5024 array and storage network handles the same workload effortlessly, reaching over 1.2 GB/s with single-digit millisecond latency.

Environment Setup:​

  • Host: Proxmox VE 9.2
  • Storage: Dell PowerVault ME5024 (iSCSI, 8 active paths across 2 subnets/VLANs)
  • NICs: 2x Dedicated 10GbE interfaces for iSCSI traffic

Current Proxmox Stock Configuration:​

1. multipath.conf (Dell ME5 Vendor Defaults):
devices {
device {
vendor "DellEMC"
product "ME5"
path_grouping_policy "group_by_prio"
path_checker tur
path_selector "service-time 0"
prio "alua"
failback immediate
features "2 pg_init_retries 50"
no_path_retry 20
hardware_handler "1 alua"
fast_io_fail_tmo 15
dev_loss_tmo 60
}
}

Benchmark Comparison (1M Sequential Read fio):

​

Proxmox VE 9 Node Output:​


READ: bw=265MiB/s (278MB/s), 265MiB/s-265MiB/s (278MB/s-278MB/s), io=9159MiB (9604MB), run=34500-34500msec
clat (usec): min=1919, max=6043.6k, avg=240711.45, stdev=824047.11
clat percentiles (msec):
| 50.00th=[ 27], 70.00th=[ 31], 80.00th=[ 94], 90.00th=[ 393],
| 95.00th=[ 911], 99.00th=[ 5269], 99.90th=[ 6007]
bw (KiB/s) : min= 8192, max=1601536, avg=396810.34

VMware ESXi VM Output:

READ: bw=1220MiB/s (1279MB/s), 1220MiB/s-1220MiB/s (1279MB/s-1279MB/s), io=35.8GiB (38.4GB), run=30001-30001msec
clat (usec): min=512, max=18420, avg=5231.12, stdev=1102.40
clat percentiles (msec):
| 50.00th=[ 5], 70.00th=[ 5], 80.00th=[ 6], 90.00th=[ 7],
| 95.00th=[ 8], 99.00th=[ 11], 99.90th=[ 15]
bw (KiB/s) : min=1150000, max=1285000, avg=1249280.00



While Proxmox reaches transient peaks of ~1.5 GB/s (max=1601536 KiB/s), it cannot sustain high bandwidth without triggering massive latency penalties (6 seconds peak delay). VMware on the same fabric runs cleanly at line rate (~1.2 GB/s) with a flat 5ms average latency.

Has anyone fine-tuned DM-Multipath, iSCSI queue depths, or block layer settings for Dell PowerVault ME5 series on Proxmox to achieve near wire-speed throughput matching VMware without hitting these latency bottlenecks?

Any insights or recommended configurations would be greatly appreciated!
 
Last edited:
Yes, Jumbo Frames (MTU 9000) are fully enabled end-to-end across the entire path (PVE interfaces, switch ports, and ME5 iSCSI portals). Ping tests with -s 8972 -D complete with 0% packet loss.
I see dropped packets though:

Code:
root@PM8161:~# ip -s link show nic2
2: nic2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 5c:6f:69:30:1b:ee brd ff:ff:ff:ff:ff:ff
    RX:     bytes   packets errors dropped  missed    mcast
    2261403467364 712815938      0  798616     804 20883800
    TX:     bytes   packets errors dropped carrier  collsns
    3694595668428 615627480      0       0       0        0
    altname enp25s0f0np0
    altname enx5c6f69301bee
root@PM8161:~# ip -s link show nic3
5: nic3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 5c:6f:69:30:1b:ef brd ff:ff:ff:ff:ff:ff
    RX:     bytes   packets errors dropped  missed    mcast
    1417420835343 585235025      0  798618     480 20883834
    TX:     bytes   packets errors dropped carrier  collsns
    2159084852818 420805759      0       0       0        0
    altname enp25s0f1np1
    altname enx5c6f69301bef
root@PM8161:~#
 
Hey @infoplus,

Have run into a very similar bottleneck with PowerVault ME4/ME5 series over iSCSI on Linux kernels. A couple of things to check in your multipath and block layer configs:

1. What path_grouping_policy and path selector are you running in /etc/multipath.conf? For ME5 with ALUA, make sure you're using group_by_prio with alua prioritizer, and test service-time 0 instead of round-robin 0 if one controller is saturated or queueing differently.
2. Block queue scheduler: on PVE 8 (Debian 12 / kernel 6.5+ or 6.8), check cat /sys/block/sdX/queue/scheduler. Usually none or mq-deadline is fine for arrays, but verify nr_requests and read_ahead_kb. Raising read_ahead_kb (e.g. to 1024 or 2048) often helps sequential throughput drastically.
3. Also, are you testing I/O straight from the PVE host (raw multipath device) or inside a VM via virtio-scsi-single? If VM, make sure iothread=1 and aio=threads (or aio=io_uring) is enabled.

What does iostat -xz 1 or multipath -ll show during those 6-second latency spikes? Are specific paths erroring out or throttling?
 
hello Ali,
sorry my PVE version i 9.2, not 8 as mentioned before.
I'm testing the raw device from the node.
multipath -ll shows no change during the test, no failing paths
Code:
root@PM8161:/sys/block# cat /etc/multipath.conf
defaults {
    user_friendly_names yes
    find_multipaths yes
    polling_interval 5
}

blacklist {
    wwid "35000cca04ebd6b38"   # sda
    wwid "35000cca04ebbde64"   # sdb
    wwid "350026b768790bb69"   # sdc (Kingston)
    wwid "350026b76872ee45a"   # sdd (Kingston)
    wwid "350026b76872ee446"   # sde (Kingston)
}

devices {
    device {
        vendor "DellEMC"
        product "ME5"
        path_grouping_policy "group_by_prio"
        path_checker tur
        path_selector "service-time 0"
        prio "alua"
        failback immediate
        features "2 pg_init_retries 50"
        no_path_retry 20
        hardware_handler "1 alua"
        fast_io_fail_tmo 15
        dev_loss_tmo 60
    }
}
root@PM8161:/sys/block# multipath -ll
mpatha (3600c0ff000ffb51338e2f16801000000) dm-5 DellEMC,ME5
size=5.0T features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 16:0:0:2 sdk 8:160 active ready running
| |- 20:0:0:2 sdj 8:144 active ready running
| |- 21:0:0:2 sdm 8:192 active ready running
| `- 17:0:0:2 sdi 8:128 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 18:0:0:2 sdn 8:208 active ready running
  |- 15:0:0:2 sdh 8:112 active ready running
  |- 19:0:0:2 sdl 8:176 active ready running
  `- 22:0:0:2 sdo 8:224 active ready running
Code:
root@PM8161:~# fio --name=mpath_multi --filename=/dev/mapper/mpatha --ioengine=libaio --direct=1 --bs=1M --iodepth=16 --numjobs=4 --size=5G --rw=read --runtime=30 --time_based --group_reporting
mpath_multi: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=libaio, iodepth=16
...
fio-3.39
Starting 4 processes
Jobs: 4 (f=4): [R(4)][56.1%][eta 00m:25s]
mpath_multi: (groupid=0, jobs=4): err= 0: pid=3631773: Fri Sep 11 07:14:21 2026
  read: IOPS=387, BW=387MiB/s (406MB/s)(12.3GiB/32552msec)
    slat (usec): min=33, max=2374, avg=124.42, stdev=75.73
    clat (usec): min=1817, max=9593.8k, avg=164265.48, stdev=641345.95
     lat (usec): min=1917, max=9594.0k, avg=164389.90, stdev=641349.60
    clat percentiles (msec):
     |  1.00th=[    5],  5.00th=[    9], 10.00th=[   21], 20.00th=[   24],
     | 30.00th=[   26], 40.00th=[   27], 50.00th=[   27], 60.00th=[   28],
     | 70.00th=[   30], 80.00th=[  106], 90.00th=[  334], 95.00th=[  472],
     | 99.00th=[ 3104], 99.50th=[ 5201], 99.90th=[ 9060], 99.95th=[ 9597],
     | 99.99th=[ 9597]
   bw (  KiB/s): min= 8192, max=1626112, per=100.00%, avg=587755.43, stdev=103623.72, samples=175
   iops        : min=    8, max= 1588, avg=573.98, stdev=101.20, samples=175
  lat (msec)   : 2=0.01%, 4=0.48%, 10=5.01%, 20=4.43%, 50=64.66%
  lat (msec)   : 100=5.10%, 250=4.89%, 500=10.68%, 750=2.12%, 1000=0.63%
  lat (msec)   : 2000=0.25%, >=2000=1.74%
  cpu          : usr=0.10%, sys=1.32%, ctx=12286, majf=0, minf=16416
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.3%, 16=99.5%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=12607,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
   READ: bw=387MiB/s (406MB/s), 387MiB/s-387MiB/s (406MB/s-406MB/s), io=12.3GiB (13.2GB), run=32552-32552msec
root@PM8161:~#

Code:
root@PM8161:/sys/block# cat /sys/block/dm-5/queue/scheduler
none [mq-deadline]
root@PM8161:/sys/block# cat /sys/block/dm-5/queue/nr_requests
256
root@PM8161:/sys/block# cat /sys/block/dm-5/queue/read_ahead_kb
2048
root@PM8161:/sys/block#
 

UPDATE – Further investigation​

I performed a much more detailed investigation, including testing individual iSCSI paths directly and updating the ME5024 firmware.

Firmware​

The ME5024 was originally running:

  • ME5.1.2.1.5
I have now upgraded both controllers to:

  • ME5.1.2.2.1
  • Controller A: Operational / Health OK
  • Controller B: Operational / Health OK
  • Active-Active ULP
  • Redundancy: Redundant
  • System Ready: Ready
Unfortunately, the performance problem is unchanged after the firmware upgrade.

Network​

The iSCSI network is:

  • 2 dedicated 25GbE NICs
  • Two separate /24 subnets
  • MTU 9000 end-to-end
  • Jumbo ping with 8972-byte payload works with 0% packet loss
  • No significant TCP retransmissions were observed during the fio tests
  • The NICs are directly assigned to the iSCSI networks, without Linux bridges
Therefore I currently have no evidence that the problem is caused by network bandwidth, MTU or packet loss.

Multipath​

The ME5024 LUN is presented through multiple iSCSI paths and correctly detected by DM-Multipath.

However, the problem can be reproduced without multipath, by testing a single SCSI path directly:

/dev/sdh
The same behavior is observed on multiple individual paths, including paths through both ME5024 controllers.

This means the problem is not specific to DM-Multipath load balancing.

The most important finding​

The problem is highly dependent on I/O size and concurrency.

Using the same physical iSCSI path (/dev/sdh) and direct I/O:

Block sizeQueue depthResult
256 KiBQD2~1075 MiB/s, ~0.46 ms
512 KiBQD2~1108 MiB/s, ~0.90 ms
768 KiBQD1851 MiB/s, ~0.88 ms
768 KiBQD298.9 MiB/s, ~15.2 ms
1 MiBQD1~886 MiB/s, ~1.1 ms
1 MiBQD218.3 MiB/s, ~109 ms
The 768 KiB QD2 test is particularly interesting:

  • 96.78% of requests complete within 2 ms
  • but some requests take approximately 5.1 seconds
  • device utilization is ~99.5%
With 1 MiB QD2:

  • ~18 MiB/s
  • average latency ~109 ms
  • maximum latency ~5.1 seconds
  • approximately 2.2% of requests exceed 2 seconds
In contrast, 768 KiB QD1 delivers ~851 MiB/s with 97.6% of requests below 1 ms.

So the issue appears to be triggered when large sequential READ requests are outstanding concurrently. It is not simply a limitation of the storage media or the 25GbE link.

This also reproduces during real Proxmox VM migration​

During an actual migration from the ME5024 to Ceph, the ME5 multipath device showed approximately:

READ throughput: 130–160 MB/s
Average request size: ~950–1030 KB
Read latency: ~22–51 ms
Queue depth: ~3.5–5
Device utilization: ~85–96%
This is very similar to the synthetic fio behavior above.

The migration therefore appears to generate approximately 1 MiB concurrent READ requests, which puts the ME5024 into the same problematic behavior observed with fio.

Additional observations​

I also tested lowering the Linux block device max_sectors_kb to 512K. This caused 1 MiB requests to be split into smaller requests, but it did not reliably eliminate the latency problem. Therefore simply reducing the Linux block-layer maximum request size does not appear to be a complete solution.

The problem is also reproducible with multiple concurrent jobs (numjobs) and is not specific to fio's interpretation of iodepth.

Current conclusion​

At this point, my working hypothesis is that there is an interaction between:

  • Dell ME5024 / ME5 iSCSI implementation
  • large READ requests (roughly >512 KiB)
  • more than one outstanding READ
  • Linux/Proxmox I/O submission behavior
The issue is reproducible on individual iSCSI paths, on different ME5024 controller ports, and remains after upgrading the array to ME5.1.2.2.1.

The same ME5024 storage is able to deliver approximately 1.2 GB/s with VMware ESXi, so the array and physical storage are capable of substantially higher sequential throughput.

I would therefore appreciate input from anyone familiar with the ME5 Linux/iSCSI stack, particularly regarding:

  1. Whether this behavior is known with ME5024/ME5 and Linux.
  2. Whether there are recommended SCSI/iSCSI settings for large concurrent READs on ME5.
  3. Whether Proxmox/QEMU migration can be configured to issue smaller or less concurrent read requests.
  4. Whether there are known Linux kernel or open-iscsi issues related to large concurrent READs with ME5 arrays.
  5. Whether Dell has any specific ME5 tuning recommendation for this workload.
 
Whether this behavior is known with ME5024/ME5 and Linux.
Fairly easy to test, since you have access to the storage both at the "linux" level on pve OR passed as an iscsi target directly to a vm instead of as a virtio device.

  1. Whether there are recommended SCSI/iSCSI settings for large concurrent READs on ME5.
sounds like you got most of those covered; however, its imperative that you control LUN traffic only to its active controller. with two controllers you want a minimum of two stripesets. More is better. Also, ssd tiers can help minimize burst contention.
  1. Whether there are known Linux kernel or open-iscsi issues related to large concurrent READs with ME5 arrays.
  2. Whether Dell has any specific ME5 tuning recommendation for this workload.
Best place to ask is Dell support.