（问题被重新表述，我认为它需要更加结构化）
我们在 Dell PowerEdge R610 gen 8 系统上安装了 Proxmox VE。该平台比较老旧，但我们将其用于特定的软件，众所周知，该软件没有现代 CPU 内核的优势，但其性能会随着 CPU 时钟频率线性增加，而 3.3GHz 很好地实现了目标。性能分析显示磁盘 I/O 是严重的瓶颈，而其他则不是。
硬件配置是：
- Dell PowerEdge R610 gen 8，BIOS v6.6.0，2018 年 5 月 22 日（最新），双 PSU - 两者似乎都正常。服务器在 UEFI 中启动。
- CPU：2x Xeon X5680（Nehalem，共 12 个核心，3.3GHz，最高可加速至 3.6 GHz）
- 内存：96 GiB - 6x 三星 M393B2K70DM0-YH9 (DDR3, 16GiB, 1333MT/s)
- 存储控制器：LSI MegaRAID SAS 9240-4i，JBOD 模式（SAS-MFI BIOS，FW v20.10.1-0107 - 不是最新版本）
- 存储：2x 全新三星 SSD 860 EVO 1TB，固件 RVT03B6Q
我们使用的 MegaRAID 不是内置 PERC。内置 PERC 只能支持 1.5 Gbit/S SATA，速度太慢，而且 JBOD 或 HBA 模式被禁用。与此不同，附加的 9240-4i 以最大 6 Gbit/s 接口速度运行 SSD，并允许使用 JBOD 模式。
该卡没有电池，也没有缓存，因此在用它构建 RAID 时，性能显然太低，因此两个磁盘都配置为 JBOD 并与软件 RAID 一起使用。6 Gbit/s 接口的理论最大值为 600 MB/s（考虑 8 到 10 位线路编码），这是单驱动器顺序测试的预期结果。
我们在 Linux 和 Windows 下都进行了广泛的 i/o 测试，两者都使用相同配置的 fio。配置中唯一的区别是 aio 库（Windows 中为 windowsaio，Linux 中为 libaio）和测试设备规格。fio 配置改编自此帖子：https://forum.proxmox.com/threads/pve-6-0-slow-ssd-raid1-performance-in-windows-vm.58559/#post-270657。我无法显示完整的 fio 输出，因为这将达到 ServerFault 的 30k 个字符的限制。如果有人想看，我可以将它们分享到其他地方。在这里，我将仅显示摘要行。Linux（Proxmox VE）配置了 MD RAID1 和“厚”LVM。
SSD 内的缓存已启用：
# hdparm -W /dev/sd[ab]
/dev/sda:
write-caching = 1 (on)
/dev/sdb:
write-caching = 1 (on)
设备以 6 Gb/s 的接口速度运行：
# smartctl -i /dev/sda
smartctl 7.0 2018-12-30 r4883 [x86_64-linux-5.3.10-1-pve] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Samsung based SSDs
Device Model: Samsung SSD 860 EVO 1TB
Serial Number: S4FMNE0MBxxxxxx
LU WWN Device Id: x xxxxxx xxxxxxxxx
Firmware Version: RVT03B6Q
User Capacity: 1 000 204 886 016 bytes [1,00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Fri Feb 7 15:25:45 2020 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
# smartctl -i /dev/sdb
smartctl 7.0 2018-12-30 r4883 [x86_64-linux-5.3.10-1-pve] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Samsung based SSDs
Device Model: Samsung SSD 860 EVO 1TB
Serial Number: S4FMNE0MBxxxxxx
LU WWN Device Id: x xxxxxx xxxxxxxxx
Firmware Version: RVT03B6Q
User Capacity: 1 000 204 886 016 bytes [1,00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Fri Feb 7 15:25:47 2020 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
分区被仔细地对齐到 1 MiB，并且“主”大分区（即 LVM PV 以及所有测试均在此处完成）恰好从 512 MiB 开始：
# fdisk -l /dev/sd[ab]
Disk /dev/sda: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 860
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 1DDCF7A0-D894-8C43-8975-C609D4C3C742
Device Start End Sectors Size Type
/dev/sda1 2048 524287 522240 255M EFI System
/dev/sda2 524288 526335 2048 1M BIOS boot
/dev/sda3 526336 1048575 522240 255M Linux RAID
/dev/sda4 1048576 1953525134 1952476559 931G Linux RAID
Disk /dev/sdb: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 860
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 63217472-3D2E-9444-917C-4776100B2D87
Device Start End Sectors Size Type
/dev/sdb1 2048 524287 522240 255M EFI System
/dev/sdb2 524288 526335 2048 1M BIOS boot
/dev/sdb3 526336 1048575 522240 255M Linux RAID
/dev/sdb4 1048576 1953525134 1952476559 931G Linux RAID
没有位图：
# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md126 : active raid1 sda4[2] sdb4[0]
976106176 blocks super 1.2 [2/2] [UU]
md127 : active raid1 sda3[2] sdb3[0]
261056 blocks super 1.0 [2/2] [UU]
unused devices: <none>
LVM 创建时 PE 大小为 32 MiB，因此其内部的所有内容都与 32 MiB 对齐。
lsblk --discard显示没有设备支持任何 TRIM（即使是非排队的）。这可能是因为 LSI2008 芯片不认识此命令。排队 TRIM 在以下 SSD 上被列入黑名单：https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/ata/libata-core.c?id=9a9324d3969678d44b330e1230ad2c8ae67acf81不管怎样，这仍然和 Windows 看到的一样，因此比较是公平的。
两个磁盘上的 I/O 调度程序均为“无”。我还尝试了“mq-deadline”（默认设置），但总体而言，结果更差。
在该配置下，fio 显示以下结果：
PVEHost-128K-Q32T1-Seq-Read bw=515MiB/s (540MB/s), 515MiB/s-515MiB/s (540MB/s-540MB/s), io=97.5GiB (105GB), run=194047-194047msec
PVEHost-128K-Q32T1-Seq-Write bw=239MiB/s (250MB/s), 239MiB/s-239MiB/s (250MB/s-250MB/s), io=97.7GiB (105GB), run=419273-419273msec
PVEHost-4K-Q8T8-Rand-Read bw=265MiB/s (278MB/s), 265MiB/s-265MiB/s (278MB/s-278MB/s), io=799GiB (858GB), run=3089818-3089818msec
PVEHost-4K-Q8T8-Rand-Write bw=132MiB/s (138MB/s), 132MiB/s-132MiB/s (138MB/s-138MB/s), io=799GiB (858GB), run=6214084-6214084msec
PVEHost-4K-Q32T1-Rand-Read bw=265MiB/s (278MB/s), 265MiB/s-265MiB/s (278MB/s-278MB/s), io=98.7GiB (106GB), run=380721-380721msec
PVEHost-4K-Q32T1-Rand-Write bw=132MiB/s (139MB/s), 132MiB/s-132MiB/s (139MB/s-139MB/s), io=99.4GiB (107GB), run=768521-768521msec
PVEHost-4K-Q1T1-Rand-Read bw=16.8MiB/s (17.6MB/s), 16.8MiB/s-16.8MiB/s (17.6MB/s-17.6MB/s), io=99.9GiB (107GB), run=6102415-6102415msec
PVEHost-4K-Q1T1-Rand-Write bw=36.4MiB/s (38.1MB/s), 36.4MiB/s-36.4MiB/s (38.1MB/s-38.1MB/s), io=99.8GiB (107GB), run=2811085-2811085msec
在完全相同的硬件配置上，Windows 配置了逻辑磁盘管理器镜像。结果是：
WS2019-128K-Q32T1-Seq-Read bw=1009MiB/s (1058MB/s), 1009MiB/s-1009MiB/s (1058MB/s-1058MB/s), io=100GiB (107GB), run=101535-101535msec
WS2019-128K-Q32T1-Seq-Write bw=473MiB/s (496MB/s), 473MiB/s-473MiB/s (496MB/s-496MB/s), io=97.8GiB (105GB), run=211768-211768msec
WS2019-4K-Q8T8-Rand-Read bw=265MiB/s (278MB/s), 265MiB/s-265MiB/s (278MB/s-278MB/s), io=799GiB (858GB), run=3088236-3088236msec
WS2019-4K-Q8T8-Rand-Write bw=130MiB/s (137MB/s), 130MiB/s-130MiB/s (137MB/s-137MB/s), io=799GiB (858GB), run=6272968-6272968msec
WS2019-4K-Q32T1-Rand-Read bw=189MiB/s (198MB/s), 189MiB/s-189MiB/s (198MB/s-198MB/s), io=99.1GiB (106GB), run=536262-536262msec
WS2019-4K-Q32T1-Rand-Write bw=124MiB/s (130MB/s), 124MiB/s-124MiB/s (130MB/s-130MB/s), io=99.4GiB (107GB), run=823544-823544msec
WS2019-4K-Q1T1-Rand-Read bw=22.9MiB/s (24.0MB/s), 22.9MiB/s-22.9MiB/s (24.0MB/s-24.0MB/s), io=99.9GiB (107GB), run=4466576-4466576msec
WS2019-4K-Q1T1-Rand-Write bw=41.4MiB/s (43.4MB/s), 41.4MiB/s-41.4MiB/s (43.4MB/s-43.4MB/s), io=99.8GiB (107GB), run=2466593-2466593msec
比较：
windows none mq-deadline comment
1058MB/s 540MB/s 539MB/s 50% less than Windows, but this is expected
496MB/s 250MB/s 295MB/s 40-50% less than Windows!
278MB/s 278MB/s 278MB/s same as Windows
137MB/s 138MB/s 127MB/s almost same as Windows
198MB/s 278MB/s 276MB/s 40% more than Windows
130MB/s 139MB/s 130MB/s similar to Windows
24.0MB/s 17.6MB/s 17.3MB/s 26% less than Windows
43.4MB/s 38.1MB/s 28.3MB/s 12-34% less than Windows
仅当至少有两个线程时，Linux MD RAID1 才会从两个驱动器读取数据。第一个测试是单线程，因此 Linux 将从单个驱动器读取数据，并实现单个驱动器性能。这是合理的，并且第一个测试结果很好。但其他...
这些只是主机测试。当我们比较在虚拟机内运行相同测试时的情况时，最后一行显示的结果更糟，在 PVE 下的 Windows VM 中（无膨胀固定内存、固定 CPU 频率、virtio scsi v171、带屏障的写回），它显示的结果比 Hyper-V 下的 Windows 少 70%。即使是 PVE 下的 Linux VM 也比 Hyper-V 下的 Windows 差很多：
windows, windows, linux,
hyper-v pve pve
128K-Q32T1-Seq-Read 1058MB/s 856MB/s 554MB/s
128K-Q32T1-Seq-Write 461MB/s 375MB/s 514MB/s
4K-Q8T8-Rand-Read 273MB/s 327MB/s 254MB/s
4K-Q8T8-Rand-Write 135MB/s 139MB/s 138MB/s
4K-Q32T1-Rand-Read 220MB/s 198MB/s 210MB/s
4K-Q32T1-Rand-Write 131MB/s 146MB/s 140MB/s
4K-Q1T1-Rand-Read 18.2MB/s 5452kB/s 8701kB/s
4K-Q1T1-Rand-Write 26.7MB/s 7772kB/s 10.7MB/s
在这些测试中，尽管 I/O 负载很大，但 Hyper-V 下的 Windows 表现相当出色，PVE 下的 Linux 也一样。但是当 Windows 在 PVE 下运行时，其 GUI 运行缓慢，RDP 会话往往会因数据包丢失而自行断开连接，主机上的 HA 高达 48，这主要是由于巨大的 I/O 等待！
在测试期间，单个核心的负载相当大，而这个核心恰好为“megasas”中断提供服务。此卡仅显示单个中断源，因此无法“在硬件中”分散负载。Windows 在测试期间没有显示这样的单核负载，因此它似乎使用了某种中断控制（将其负载分散到核心上）。并且 Windows 主机测试中的整体 CPU 负载被认为低于 Linux 主机。但是，这无法直接比较。
问题是：为什么它这么糟糕，我是不是忽略了什么？它的性能能与 Windows 相媲美吗？（我写这篇文章时手都颤抖了，不知该说什么，与 Windows 相比，追赶上来真是令人不快。）
@shodanshok 建议的附加测试：
[global]
ioengine=libaio
group_reporting
filename=/dev/vh0/testvol
direct=1
size=5G
[128K-Q1T32-Seq-Read]
rw=read
bs=128K
numjobs=32
stonewall
[128K-Q1T32-Seq-Write]
rw=write
bs=128K
numjobs=32
stonewall
[4K-Q1T32-Seq-Read]
rw=read
bs=4K
numjobs=32
stonewall
[4K-Q1T32-Seq-Write]
rw=write
bs=4K
numjobs=32
stonewall
[128K-Q1T2-Seq-Read]
rw=read
bs=128K
numjobs=2
stonewall
[128K-Q1T2-Seq-Write]
rw=write
bs=128K
numjobs=2
stonewall
结果：
128K-Q1T32-Seq-Read bw=924MiB/s (969MB/s), 924MiB/s-924MiB/s (969MB/s-969MB/s), io=160GiB (172GB), run=177328-177328msec
128K-Q1T32-Seq-Write bw=441MiB/s (462MB/s), 441MiB/s-441MiB/s (462MB/s-462MB/s), io=160GiB (172GB), run=371784-371784msec
4K-Q1T32-Seq-Read bw=261MiB/s (274MB/s), 261MiB/s-261MiB/s (274MB/s-274MB/s), io=160GiB (172GB), run=627761-627761msec
4K-Q1T32-Seq-Write bw=132MiB/s (138MB/s), 132MiB/s-132MiB/s (138MB/s-138MB/s), io=160GiB (172GB), run=1240437-1240437msec
128K-Q1T2-Seq-Read bw=427MiB/s (448MB/s), 427MiB/s-427MiB/s (448MB/s-448MB/s), io=10.0GiB (10.7GB), run=23969-23969msec
128K-Q1T2-Seq-Write bw=455MiB/s (477MB/s), 455MiB/s-455MiB/s (477MB/s-477MB/s), io=10.0GiB (10.7GB), run=22498-22498msec
事情很奇怪，为什么 128K-Q1T2-Seq-Read 这么糟糕？（理想值是 1200MB/s。）每个作业 5 GiB 太小，无法解决问题？其他一切似乎都还好。
答案1
如果只使用两个 SATA 磁盘，则不太可能受到 IRQ 服务时间的限制。相反，您看到的缓慢 IO 速度很可能是 MegaRAID 控制器禁用磁盘自己的私有 DRAM 缓存的直接结果，对于 SSD 而言，这些缓存批判的以获得良好的表现。
如果您使用的是 PERC 品牌的 MegaRAID 卡，则可以通过以下方式启用磁盘的私有缓存omconfig storage vdisk controller=0 vdisk=0 diskcachepolicy=enabled（我根据记忆写下了这段内容，仅作为示例；请咨询CLIomconfig参考
反正，确定了解这意味着什么：如果在使用消费级（即无电源保护）SSD 时启用了磁盘缓存，任何断电都可能导致数据丢失。如果您托管关键数据，请不是启用磁盘缓存；相反，购买带有断电保护写回缓存的企业级 SSD（例如：Intel S4510）。
当且仅当您的数据是可消耗的，那么请随意启用磁盘的内部缓存。
更多参考：https://notesbytom.wordpress.com/2016/10/21/dell-perc-megaraid-disk-cache-policy/