Плохая производительность хранилища Linux по сравнению с Windows на той же машине

(вопрос был переформулирован, я думаю, что его нужно было более структурировать)

У нас есть Proxmox VE на Dell PowerEdge R610 система поколения 8. Платформа старая, но мы используем ее для определенного ПО, которое, как известно, не имеет преимуществ от современных ядер ЦП, но увеличивает производительность линейно с тактовой частотой ЦП, а частота 3,3 ГГц хорошо справляется с задачей. Анализ производительности показал, что дисковый ввод-вывод является серьезным узким местом, в то время как другие - нет.

Конфигурация оборудования:

• Dell PowerEdge R610 gen 8, BIOS v6.6.0 от 22.05.2018 (самая последняя), двойная БП - оба вроде ок. Сервер загружается в UEFI.
• ЦП: 2x Xeon X5680 (Nehalem, всего 12 ядер, 3,3 ГГц, увеличивается до 3,6 ГГц)
• ОЗУ: 96 ГиБ - 6x Samsung M393B2K70DM0-YH9 (DDR3, 16 ГБ, 1333 МТ / с )
• Контроллер хранилища: LSI MegaRAID SAS 9240-4i, режим JBOD (SAS-MFI BIOS, FW v20.10.1-0107 - не последняя версия)
• Хранилище: 2x новых Samsung SSD 860 EVO 1TB, прошивка RVT03B6Q

MegaRAID, который мы используем, не является встроенным PERC. Встроенный был способен работать только с SATA 1,5 Гбит / с, что слишком медленно, также отключены режимы JBOD или HBA. В отличие от этого, дополнительный 9240-4i запускает SSD с максимальной скоростью интерфейса 6 Гбит / с и поддерживает режим JBOD.

У карты нет батареи и кеша, поэтому было очевидно, что у нее слишком низкая производительность когда RAID был построен с ним, поэтому оба диска настроены как JBOD и используются с программным RAID. Теоретический максимум для интерфейса 6 Гбит / с составляет 600 МБ / с (с учетом кодирования проводов от 8 до 10 бит), это то, чего можно ожидать от последовательного теста одного диска.

Мы провели обширные тесты ввода-вывода в обоих разделах. Linux и Windows, оба с fio с одинаковой конфигурацией. Единственными отличиями в конфигурации были библиотека aio (windowsaio в Windows, libaio в Linux) и спецификации тестовых устройств. Конфигурация fio была адаптирована из этого сообщения: https://forum.proxmox.com/threads/pve-6-0-slow-ssd-raid1-performance-in-windows-vm.58559/#post-270657 . Я не могу показать полные выходные данные fio, потому что это приведет к превышению предела ServerFault в 30 тысяч символов. Я могу поделиться ими где-нибудь еще, если кто-то захочет их увидеть. Здесь я покажу только итоговые строки. 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 Гбит / с:

# 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 МиБ, а «основной» большой раздел, который представляет собой LVM PV и где были выполнены все тесты, начинается точно с 512 МБ:

# 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 МБ, поэтому внутри все выравнивается по 32 МиБ.

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, так что сравнение справедливо.

Планировщик ввода-вывода был «нет» на обоих дисках. Я также попробовал "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 была настроена с зеркалированием Logical Disk Manager. . Результаты следующие:

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 будет читать с одного диска и достигнет производительности одного диска. Это оправдано, и этот первый результат теста удовлетворителен. Но другие ...

Это только хост-тесты. Когда мы сравнивали то, что происходит, когда мы запускали те же тесты внутри виртуальных машин, последние строки показали еще хуже, в виртуальной машине Windows с PVE (без увеличения фиксированной памяти, фиксированная частота процессора, virtio scsi v171, обратная запись с барьерами) отображалось на 70% меньше чем под Windows под Hyper-V. Даже Linux VM под PVE показывает результаты намного хуже, чем Windows под Hyper-V:

                     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

Во время этих тестов Windows под Hyper-V была достаточно ответственной, несмотря на большую нагрузку ввода-вывода, тот же Linux под PVE. Но когда Windows работала под PVE, ее графический интерфейс медленно сканировал, сеанс RDP имел тенденцию отключаться из-за потери пакетов, а HA на хосте достигало 48, что в основном было связано с огромным ожиданием ввода-вывода!

Во время в тесте была обнаружена довольно большая нагрузка на одно ядро, которое обслуживало «мегасервисное» прерывание. Эта карта показывает только один источник прерывания, поэтому нет возможности распространить это "аппаратно". Windows не показывала такую ​​одноядерную нагрузку во время теста, так что вроде бы использует какое-то управление прерываниями (распределяет нагрузку на ядра). И общая загрузка процессора в тесте хоста 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 было так плохо? (Идеальное значение - 1200 МБ / с.) 5 ГиБ на задание - это слишком мало, чтобы все уладить? Все остальное вроде в порядке.