У меня есть 6-дисковый массив raid6 mdadm, на который я хотел бы протестировать записи:
root@ubuntu:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 sda[0] sdf[5] sde[4] sdd[3] sdc[2] sdb[1]
1953545984 blocks level 6, 64k chunk, algorithm 2 [6/6] [UUUUUU]
Тесты могут быть неточными из-за кеширования - например, обратите внимание, что скорость записи здесь выше, чем должна быть:
root@ubuntu:/mnt/raid6# dd if=/dev/zero of=delme bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.276026 s, 380 MB/s
Теперь мы можем довольно легко отключить каждый дисковый кеш:
root@ubuntu:~# hdparm -W0 /dev/sd*
/dev/sda:
setting drive write-caching to 0 (off)
write-caching = 0 (off)
/dev/sdb:
setting drive write-caching to 0 (off)
write-caching = 0 (off)
/dev/sdc:
setting drive write-caching to 0 (off)
write-caching = 0 (off)
/dev/sdd:
setting drive write-caching to 0 (off)
write-caching = 0 (off)
/dev/sde:
setting drive write-caching to 0 (off)
write-caching = 0 (off)
/dev/sdf:
setting drive write-caching to 0 (off)
write-caching = 0 (off)
Но есть еще кеширование Linux:
root@ubuntu:/mnt/raid6# dd if=/dev/zero of=delme bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.00566339 s, 1.9 GB/s
Чтобы отключить кеширование Linux, мы можем смонтировать файловую систему синхронно:
mount -o remount,sync /mnt/raid6
Но после этого записи становятся путь медленнее, чем должно быть:
root@ubuntu:/mnt/raid6# dd if=/dev/zero of=delme bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 23.3311 s, 449 kB/s
Как будто для работы mdadm требуется асинхронное монтирование. Что тут происходит?
Цитата вопрошающего:
Но есть еще кеширование Linux:
root@ubuntu:/mnt/raid6# dd if=/dev/zero of=delme bs=1M count=10 10+0 records in 10+0 records out 10485760 bytes (10 MB) copied, 0.00566339 s, 1.9 GB/sЧтобы отключить кеширование Linux, мы можем смонтировать файловую систему синхронно:
mount -o remount,sync /mnt/raid6
Это не совсем верно ... синхронизация не просто отключает кеширование, как вы хотите в тесте. Он превращает каждый результат записи в команду «sync», что означает полную очистку кеша до диска.
Вот сервер, чтобы лучше объяснить:
$ dd if=/dev/zero of=testfile bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 0.183744 s, 2.9 GB/s
$ dd if=/dev/zero of=testfile bs=1M count=500 conv=fdatasync
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 5.22062 s, 100 MB/s
conv = fdatasync просто означает очистку после записи и сообщает вам время, включая эту очистку. В качестве альтернативы вы можете:
$ time ( dd if=/dev/zero of=testfile bs=1M count=500 ; sync )
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 0.202687 s, 2.6 GB/s
real 0m2.950s
user 0m0.007s
sys 0m0.339s
А затем рассчитайте МБ / с из 2,95 с в реальном времени, а не 0,2 с. Но это уродливее и требует больше работы, поскольку статистика, выводимая dd, не включает синхронизацию.
Если бы вы использовали «синхронизацию», вы бы сбрасывали каждую запись ... может быть, это означает каждый блок, который будет работать очень медленно. "sync" следует использовать только в очень строгих системах, например. базы данных, где потеря одной транзакции из-за сбоя диска недопустима (например, если я переведу миллиард долларов со своего банковского счета на ваш, и система выйдет из строя, и вдруг у вас есть деньги, но я тоже).
Вот еще одно объяснение с дополнительными опциями, о котором я читал давно. http://romanrm.ru/en/dd-benchmark
И еще одно замечание: ваш тест, который вы делаете таким образом, полностью верен, на мой взгляд, хотя и не действителен по мнению многих других. Но это не испытание в реальной жизни. Это однопоточная последовательная запись. Если ваш случай использования в реальной жизни такой, например. отправка больших файлов по сети, тогда это может быть хорошим тестом. Если ваш вариант использования отличается, например. ftp-сервер с 500 людьми, загружающими небольшие файлы одновременно, тогда это не очень хорошо.
Кроме того, для достижения наилучших результатов вы должны использовать случайно сгенерированный файл в ОЗУ. Это должны быть случайные данные, потому что некоторые файловые системы слишком умны, когда вы вводите им нули. например. в Linux с использованием файловой системы RAM tmpfs, которая смонтирована в / dev /. И это должна быть RAM fs вместо использования / dev / urandom напрямую, потому что / dev / random действительно медленный, а / dev / urandom быстрее (например, 75 МБ / с), но все же медленнее, чем hdd.
dd if=/dev/urandom of=/dev/shm/randfile bs=1M count=500
dd if=/dev/shm/randfile bs=1M count=500 conv=fdatasync
Производительность значительно хуже, потому что синхронная запись заставляет вычисление четности забивать диски.
В общем, вычисление и запись четности - относительно медленный процесс, особенно с RAID 6 - в вашем случае md не только должен фрагментировать данные на четыре части, он затем вычисляет два фрагмента четности для каждой полосы. Для повышения производительности реализации RAID (включая MD) будут кэшировать недавно использованные полосы в памяти, чтобы сравнить данные, которые должны быть записаны, с существующими данными и быстро пересчитать четность при записи. Если новые данные записываются в кэшированную полосу, она может сравнивать, фрагментировать и повторно вычислять четность, даже не касаясь диска, а затем сбрасывать его позже. Вы создали ситуацию, когда md всегда пропускает кеш, и в этом случае он должен прочитать полосу с диска, сравнить данные, фрагментировать новые данные, повторно вычислить четность, а затем сбросить новую полосу прямо на диск. То, что потребовало бы нулевых операций чтения и записи с / на диск при попадании в кэш, становится шесть операций чтения и шесть записей за каждую написанную полосу.
Конечно, разница в производительности, которую вы наблюдали, огромна (1,9 ГБ / с против 449 КБ / с), но я думаю, что все это объясняется тем, сколько работы md выполняет для поддержания целостности данных.
Это снижение производительности может усугубляться тем, как у вас расположены диски ... если у вас есть все они на одном контроллере, такое дополнительное чтение и запись приведет к остановке производительности.
Расскажите, как устроены ваши 6 дисков? Для меня это звучит так, как если бы они были частью SAN / DAS любых целей - которые, вероятно, состоят из одних и тех же физических дисков (так что, если все 6 находятся на одном диске, это снизит производительность по сравнению с одним диском на 6).
Взгляните на эту ссылку на anwerleaks.com.
Итак, как вы настроили растровое изображение?