同じマシン上のWindowsと比較して、Linuxストレージのパフォーマンスが悪い
（質問は再定式化されました。もっと構造化する必要があると思います）
Dell PowerEdge R610 gen 8システムにはProxmox VEが搭載されています。プラットフォームは古いですが、特定のS/Wに使用します。これは、最新のCPUコアからの利点がないことはよく知られていますが、CPUクロック周波数で直線的にパフォーマンスを向上させ、3.3GHzは、パフォーマンス分析の結果、ディスクI/Oは深刻なボトルネックになっていることが示されましたが、そうでないものもあります。
ハードウェア構成は次のとおりです。
- Dell PowerEdge R610 gen 8、2018年5月22日のBIOS v6.6.0（最新）、デュアルPSU-どちらも問題ないようです。サーバーがUEFIで起動します。
- CPU：2x Xeon X5680（Nehalem、合計12コア、3.3 GHz、最大3.6 GHzにブースト）
- RAM：96 GiB-6x Samsung M393B2K70DM0-YH9（DDR3、16GiB、1333MT/s）
- ストレージコントローラー：LSI MegaRAID SAS 9240-4i、JBODモード（SAS-MFI BIOS、FW v20.10.1-0107-最新のものではない）
- ストレージ：2x新しいSamsung SSD 860 EVO 1TB、ファームウェアRVT03B6Q
私たちが使用するMegaRAIDは、組み込みの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の両方で、同じ構成のfioを使用して広範なI/Oテストを行いました。構成の唯一の違いは、aioライブラリ（Windowsではwindowsaio、Linuxではlibaio）とテストデバイスの仕様です。 fio configはこの投稿から適応されました： https://forum.proxmox.com/threads/pve-6-0-slow-ssd-raid1-performance-in-windows-vm.58559/#post-270657 。 ServerFaultの制限である30K文字に達するため、完全なfio出力を表示できません。誰かが見たいなら、どこかで共有できます。ここでは、要約行のみを表示します。 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は32 MiBのPEサイズで作成されるため、その内部ではすべてが32 MiBに揃えられます。
lsblk --discardは、TRIMをサポートしているデバイスがないことを示します（キューに入れられていなくても）。これはおそらく、LSI2008チップがこのコマンドを認識していないためです。 Queued 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は、少なくとも2つのスレッドがある場合、両方のドライブからのみ読み取ります。最初のテストはシングルスレッドであるため、Linuxは単一のドライブから読み取り、単一のドライブのパフォーマンスを実現します。これは正当であり、この最初のテスト結果は問題ありません。しかし、他の...
これらはホストテストのみです。 VM内で同じテストを実行したときの結果を比較すると、最後の行はWindowsでさらに悪化しましたVM PVEの下で（バルーニングなしの固定メモリ、固定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
これらのテスト中、Hyper-VでのWindowsは、PVEでの同じLinuxと同じように、大きなI/O負荷にもかかわらず非常に責任がありました。しかし、WindowsがPVEの下で実行されたとき、そのGUIのクロールが遅く、RDPセッションはパケットのドロップが原因で切断される傾向があり、ホストのHAは最大48でした。
テスト中、単一のコアに非常に大きな負荷があり、たまたま「メガサス」割り込みを処理しました。このカードは単一の割り込みソースしか表示しないため、これを「ハードウェアで」拡散する方法はありません。 Windowsはテスト中にそのような単一コアの負荷を表示しなかったので、ある種の割り込みステアリングを使用しているようです（コアに負荷を分散します）。また、全体的なCPU負荷は、Windowsホストテストでは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は小さすぎて解決できませんか？それ以外はすべて問題ないようです。
2つのSATAディスクのみを使用する場合、IRQサービス時間によって制限されることはほとんどありません。むしろ、遅いIO表示される速度は、MegaRAIDコントローラがディスク自体のプライベートDRAMキャッシュを無効にした直接の結果であり、SSDの場合はcritical良好なパフォーマンスを得る。
PERCブランドのMegaRAIDカードを使用している場合は、omconfig storage vdisk controller=0 vdisk=0 diskcachepolicy=enabledを介してディスクのプライベートキャッシュを有効にすることができます（これはメモリから書いたもので、例としてのみ使用しています。 the omconfigで確認してくださいCLIリファレンス
とにかく、これが何を意味するかを理解するために必ず確認してください：コンシューマ（つまり、電源保護されていない）SSDを使用しているときにディスクキャッシュが有効になっている場合、停電データが失われる可能性があります。重要なデータをホストする場合は、ディスクキャッシュを有効にしないでください。むしろ、powerlossで保護されたライトバックキャッシュが付属するエンタープライズグレードのSSDを購入します（例：Intel S4510）。
データが使い捨ての場合に限り、ディスクの内部キャッシュを有効にしてください。
さらに参照： https://notesbytom.wordpress.com/2016/10/21/Dell-perc-megaraid-disk-cache-policy/