Я сделал несколько простых тестов производительности, и кажется, что чтение с моего RAID1 медленнее, чем запись:

root@dss0:~# for i in 1 2 3; do dd if=/dev/zero of=/dev/sda bs=1048576 count=131072; done
137438953472 bytes (137 GB) copied, 192.349 s, 715 MB/s
137438953472 bytes (137 GB) copied, 192.851 s, 713 MB/s
137438953472 bytes (137 GB) copied, 193.026 s, 712 MB/s
root@dss0:~# for i in 1 2 3; do dd if=/dev/sda of=/dev/null bs=1048576 count=131072; done
137438953472 bytes (137 GB) copied, 257.201 s, 534 MB/s
137438953472 bytes (137 GB) copied, 255.522 s, 538 MB/s
137438953472 bytes (137 GB) copied, 259.945 s, 529 MB/s

Я понимаю, что dd не является инструментом тестирования производительности, но этот результат все еще является сюрпризом.

Система была построена производителем и имеет материнскую плату Supermicro с 16 ГБ ОЗУ. RAID-контроллер представляет собой MegaRAID 9271-8i с 1 Гбайт кеша. На объединительной плате SAS-933EL1 установлено 8 дисков SAS 2 ТБайт. Я не уверен в кабелях, один разъем контроллера идет к объединительной плате SAS, другой идет к двум дискам SATA, которые содержат ОС.

RAID1 был настроен с помощью этой команды:

root@dss0:~# /opt/MegaRAID/MegaCli/MegaCli64 -CfgLdAdd -r1 [8:0,8:1,8:2,8:3,8:4,8:5,8:6,8:7] WB NORA Direct -a0
Adapter 0: Created VD 0
Adapter 0: Configured the Adapter!!
Exit Code: 0x00

root@dss0:~# /opt/MegaRAID/MegaCli/MegaCli64 -LDInfo -LALL -aALL
Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name                :
RAID Level          : Primary-1, Secondary-0, RAID Level Qualifier-0
Size                : 7.275 TB
Sector Size         : 512
Is VD emulated      : No
Mirror Data         : 7.275 TB
State               : Optimal
Strip Size          : 256 KB
Number Of Drives    : 8
Span Depth          : 1
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy   : Disk's Default
Encryption Type     : None
PI type: No PI
Is VD Cached: No
Exit Code: 0x00

Я ожидаю, что доступ для чтения по крайней мере так же быстро, как доступ для записи, может быть, даже быстрее. Скорость записи 715 МБ / с, кажется, приближается к пределу в 6 ГБ одного разъема SAS / SATA. Возможно, это проблема конфигурации или кабелей с объединительной платой SAS? Можно ли запросить конфигурацию объединительной платы SAS с помощью команды MegaRAID? Пожалуйста, порекомендуйте.

Обновить

Как пояснили Пойдж и Питер, более медленная, чем ожидалось, производительность чтения, вероятно, вызвана кэшированием подсистемы ввода-вывода Linux.

При использовании прямого флага в команде dd я получаю

root@dss0:~# dd if=/dev/sda of=/dev/null bs=1048576 count=131072 iflag=direct
137438953472 bytes (137 GB) copied, 199.862 s, 688 MB/s

что намного лучше, но все еще на 10% медленнее, чем скорость записи. Использование oflag = direct не влияло на скорость записи.

Poige абсолютно прав насчет кэша записи, но здесь есть более подробная информация.

Дд с нулями и использование кэша записи - это неправильный способ для сравнения (если, конечно, вы не хотите протестировать кэш записи, который, вероятно, полезен только для файловой системы, чтобы увидеть, насколько он синхронизирует метаданные, создает новые файлы и т. д. ) (и, вероятно, dd всегда неверный тип теста, но он работает для очень простого теста)

Я предлагаю вам использовать dd по крайней мере с одной из следующих опций:

conv=fdatasync -> this will make it flush to disk before finishing and calculating speed
oflag=direct   -> this will make it skip the OS cache but not the disk cache
conv=sync      -> more like skipping the disk cache too, but not really ... just flushing it every block or something like that.

И не используйте ноль либо. Некоторые интеллектуальные аппаратные средства / программное обеспечение / прошивки могут использовать некоторые комбинации клавиш, если данные настолько предсказуемы, как нули. Это особенно верно, если есть сжатие, которое, я полагаю, вы не используете. Вместо этого используйте случайный файл в памяти (такой как / dev / shm). Урандом медленный, поэтому вам нужно временно его где-то написать, чтобы прочитать снова. Создайте случайный файл размером 50 МБ:

dd if=/dev/urandom of=/dev/shm/randfile bs=1M count=50

Прочитайте файл много раз, чтобы написать его (здесь я использую cat, чтобы прочитать его 6 раз):

dd if=<(cat /dev/shm/randfile{,,,,,}) of= ... conv=fdatasync

rm /dev/shm/randfile

Также имейте в виду, что чтение raid1 выполняется быстрее при параллельных операциях, поэтому диски можно использовать независимо. Вероятно, недостаточно умно координировать диски для чтения разных частей одной и той же операции на разных дисках.

Ключ к ответу на ваш вопрос - чтение вперед . Однажды у меня тоже случилась такая проблема .

Таким образом, для оптимальной производительности последовательного чтения все диски должны постоянно подключаться к входу.

Когда вы используете ddw / o directio(см. man dd), Операция записи выполняется не сразу, а через кеш ОС, поэтому у нее больше шансов задействовать все диски последовательно и достичь максимально возможной производительности.