(вопрос был переформулирован, думаю, его нужно было более структурировать)
У нас есть Proxmox VE на системе Dell PowerEdge R610 gen 8. Платформа старая, но мы используем ее для определенного ПО, которое, как известно, не имеет преимуществ от современных ядер ЦП, но увеличивает производительность линейно с тактовой частотой ЦП, а частота 3,3 ГГц хорошо справляется с задачей. Анализ производительности показал, что дисковый ввод-вывод является серьезным узким местом, а другие - нет.
Конфигурация HW:
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, поэтому сравнение справедливо.
Планировщик ввода-вывода на обоих дисках был "none". Еще попробовал "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 будет читать с одного диска и достигнет производительности одного диска. Это оправдано, и этот первый результат теста хорош. Но другие ...
Это только хост-тесты. Когда мы сравнивали то, что происходит, когда мы запускали те же тесты внутри виртуальных машин, последние строки показали еще хуже, в виртуальной машине 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 ГиБ на задание - это слишком мало, чтобы все уладить? В остальном вроде нормально.
Совсем не похоже, что вы ограничены временем обслуживания IRQ при использовании только двух дисков SATA. Скорее всего, низкая скорость ввода-вывода, которую вы видите, является прямым результатом отключения контроллером MegaRAID собственных частных кешей DRAM диска, которые для SSD являются критический для получения хорошей производительности.
Если вы используете карту MegaRAID марки PERC, вы можете включить частный кэш диска через omconfig storage vdisk controller=0 vdisk=0 diskcachepolicy=enabled (Я написал это по памяти и только в качестве примера; пожалуйста, проверьте в omconfig Ссылка на интерфейс командной строки
Тем не мение, быть уверенным чтобы понять, что это означает: если кэш диска включен при использовании потребительского (т. е. без защиты по питанию) SSD, любое отключение электроэнергии может привести к потере данных. Если вы размещаете важные данные, сделайте не включить дисковый кеш; лучше купите SSD корпоративного уровня, который поставляется с кэш-памятью обратной записи с защитой от потери мощности (например, Intel S4510).
Если и только если ваши данные являются расходным материалом, не стесняйтесь включать внутренний кеш диска.
Еще одна ссылка: https://notesbytom.wordpress.com/2016/10/21/dell-perc-megaraid-disk-cache-policy/