Почему 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, не включает синхронизацию.

Если бы вы использовали "синхронизацию", вы бы сбрасывали каждую запись... может быть, это означает каждый блок, который работал бы очень медленно. "Синхронизация" должна использоваться только в очень строгих системах, например. базы данных, в которых потеря одной транзакции из-за сбоя диска недопустима (например, если я перевожу миллиард баксов с моего банковского счета на ваш, и система выходит из строя, и вдруг у вас есть деньги, но я тоже)

Вот еще одно объяснение с дополнительными опциями, о котором я читал давно. http://romanrm.ru/en/dd-benchmark

И еще одно замечание: ваш эталонный тест, который вы делаете таким образом, по моему мнению, полностью действителен, но не по мнению многих других. Но это не испытание в реальной жизни. Это однопоточная последовательная запись. Если ваш реальный пример использования такой, например. отправка больших файлов по сети, тогда это может быть хорошим тестом. Если ваш вариант использования отличается, например. FTP-сервер с 500 людьми, загружающими небольшие файлы одновременно, тогда это не очень хорошо.

А также, вы должны использовать случайно сгенерированный файл в оперативной памяти для достижения наилучших результатов. Некоторые файловые системы слишком умны, когда вы кормите их нулями. например. в Linux используется файловая система ram tmpfs, которая монтируется в /dev/. (а в некоторых системах /dev/random или /dev/urandom работает медленно, поэтому используйте другие... Я забыл, какие, но в любом случае они будут намного меньше ОЗУ, поэтому не используйте напрямую)

dd if=/dev/random 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.

Итак, как вы настроили свое растровое изображение?