На SATA 3.0, 6.0 Гбит / с
*-disk:0
description: ATA Disk
product: WDC WD20EFRX-68E
vendor: Western Digital
physical id: 0
bus info: scsi@1:0.0.0
hw_sector_size: 512
logical_block_size: 512
physical_block_size: 4096
# parted /dev/sda print
Model: ATA WDC WD20EFRX-68E (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
У меня есть следующие результаты fio на пустом / dev / sda3 (ext4):
fio --name=seqread --rw=read --direct=1 --ioengine=libaio --bs=8k --numjobs=8 --size=1G --runtime=600 --group_reporting
seqread IOPS=8960, BW=70.0MiB/s (73.4MB/s)(8192MiB/117028msec)
fio --name=seqwrite --rw=write --direct=1 --ioengine=libaio --bs=32k --numjobs=4 --size=2G --runtime=600 --group_reporting
seqwrite IOPS=1538, BW=48.1MiB/s (50.4MB/s)(8192MiB/170345msec); 0 zone resets
fio --name=randread --rw=randread --direct=1 --ioengine=libaio --bs=8k --numjobs=16 --size=1G --runtime=600 --group_reporting
randread IOPS=163, BW=1305KiB/s (1337kB/s)(765MiB/600078msec)
fio --name=randwrite --rw=randwrite --direct=1 --ioengine=libaio --bs=64k --numjobs=8 --size=512m --runtime=600 --group_reporting
randwrite IOPS=165, BW=10.3MiB/s (10.8MB/s)(4096MiB/395912msec); 0 zone resets
fio --name=randrw --rw=randrw --direct=1 --ioengine=libaio --bs=16k --numjobs=8 --rwmixread=90 --size=1G --runtime=600 --group_reporting
randrw read IOPS=141, BW=2258KiB/s (2313kB/s)(1324MiB/600086msec)
randrw write IOPS=15, BW=253KiB/s (259kB/s)(148MiB/600086msec); 0 zone resets
Сначала я подумал, что у меня неправильное выравнивание секторов,
Number Start End Size File system Name Flags
1 1048576B 511705087B 510656512B fat32 boot, esp
2 511705088B 54198796287B 53687091200B raid
3 54198796288B 215260069887B 161061273600B ext4 Linux filesystem
4 215260069888B 2000398917119B 1785138847232B Linux RAID raid
, но все начальные сектора делятся на 4096, и parted говорит мне, что
(parted) align-check opt 1
1 aligned
(parted) align-check opt 2
2 aligned
(parted) align-check opt 3
3 aligned
(parted) align-check opt 4
4 aligned
Эти результаты fio аналогичны для системы, работающей на Debian 10 и Arch Linux Live cd . Это не самые быстрые прядильщики, поэтому я могу жить с последовательными результатами (хотя они должны быть выше), но случайные результаты R, W и RW неприемлемы.
Ядро 5.0.x (5.2.x в Live CD), а планировщик по умолчанию (и рекомендуется )
# cat /sys/block/sda/queue/scheduler
[mq-deadline] none
Изменение планировщика на BFQ не помогло.
AFAIK выравнивание секторов нормально , но либо мне чего-то не хватает, либо у меня есть неисправные диски (новые и на гарантии). <200 IOPS и <2,5 МБ / с временами делают систему непригодной для использования.
Я не понимаю. Как мне это исправить? Или у меня есть неисправные диски (маловероятно, поскольку это два идентичных диска с одинаковыми результатами)?
Вы, кажется, делаете ввод-вывод в файловой системе с Вашими fio заданиями. Если так, это добавляет другой фактор соединения к Вашим результатам. ПРЕДУПРЕЖДЕНИЕ - выполнение ввода-вывода непосредственно к дисковому узлу может УНИЧТОЖИТЬ файловую систему и данные, которые уже являются там так быть осторожными, если Вы действительно принимаете решение перейти непосредственно в /dev/sda
!
Вы идете прямые только максимум с 8 выдающихся I/Os. Это, вероятно, слишком низко для наблюдения диска лучшая производительность (диски SATA могут обычно ставить приблизительно 32 выдающихся I/Os в очередь). Вы также используете несколько процессов для представления ввода-вывода, который, вероятно, подвергнется немного служебным по сравнению с представлением ввода-вывода асинхронно.
Сводка: не может сказать, являются ли диски дефектными, потому что Ваши fio задания выглядят странными. Возможно, недостаточно ввода-вывода отправляется (fio дисковая статистика упоминаний, которая Вы не включали здесь - проверка, на что Ваше использование диска похоже). Дополнительно вещи как кэши на самом диске могут означать возможное возвращение искаженного результата из-за области, Вы работаете в том, чтобы быть настолько маленьким и несколько заданий, работающих над той же областью диска так быть предупрежденными там также (я предположил бы, что это будет более вероятно "последовательные" случаи).