У меня есть машина с 8-канальным контроллером LSI SAS3008, и тестирование отдельных дисков показывает, что я могу записывать на любой диск или все диски со скоростью от 174 МБ / с до 193 МБ / с при постоянной скорости записи:
Это результат работы команды dd if=/dev/zero of=/dev/mapper/mpath?p1 bs=1G count=100 oflag=direct вбежать параллельно на все 12 дисков:
107374182400 bytes (107 GB) copied, 556.306 s, 193 MB/s
107374182400 bytes (107 GB) copied, 566.816 s, 189 MB/s
107374182400 bytes (107 GB) copied, 568.681 s, 189 MB/s
107374182400 bytes (107 GB) copied, 578.327 s, 186 MB/s
107374182400 bytes (107 GB) copied, 586.444 s, 183 MB/s
107374182400 bytes (107 GB) copied, 590.193 s, 182 MB/s
107374182400 bytes (107 GB) copied, 592.721 s, 181 MB/s
107374182400 bytes (107 GB) copied, 598.646 s, 179 MB/s
107374182400 bytes (107 GB) copied, 602.277 s, 178 MB/s
107374182400 bytes (107 GB) copied, 604.951 s, 177 MB/s
107374182400 bytes (107 GB) copied, 605.44 s, 177 MB/s
Однако, когда я собираю эти диски вместе как устройство с программным рейдом 10, я получаю скорость записи около 500 МБ / с. Я ожидал получить вдвое больше, так как за одновременный доступ к этим дискам нет штрафов.
Я заметил процесс md10_raid10, который, как я предполагаю, приближается к 80% самого программного рейда, а одно ядро всегда находится со 100% временем ожидания и 0% бездействием. Однако какое ядро это меняется.
Кроме того, производительность падает еще больше при использовании буферного кеша для записи в смонтированную файловую систему EXT4 вместо использования oflag = direct для обхода кеша. Диски сообщают о занятости 25% (согласно мониторингу munin), но диски явно не нагреваются, но я беспокоюсь, что само устройство md10 может быть.
Есть предложения, что делать дальше? Я пытаюсь сравнить конфигурацию аппаратного рейда 10, хотя, похоже, я могу построить только 10-дисковый блок - при этом я надеюсь, что запись будет продолжаться 900 МБ / с. Я обновлю этот вопрос, когда узнаю больше.
Изменить 1:
Если я использую dd в жестком цикле записи в раздел ext4, установленный на этом устройстве, и я не использую буферный кеш (oflag = direct), я могу получить более 950 МБ / с на пике и 855 МБ / с с некоторыми изменениями в установить флаги.
Если я также буду читать с iflag = direct в то же время, я могу получить 480 МБ / с для записи и 750 МБ / с для чтения сейчас.
Если я пишу без oflag = direct, используя таким образом буферный кеш, я получаю запись 230 МБ / с и чтение 1,2 МБ / с, но машина кажется очень медленной.
Итак, возникает вопрос, почему использование буферного кеша так серьезно влияет на производительность? Я пробовал различные стратегии дисковой очереди, включая использование «noop» на уровне диска и установку «deadline» или «cfq» на соответствующее многопутевое устройство dm, или крайний срок для всех, или ни одного на dm и крайний срок на резервном диске. Кажется, что на резервном диске его не должно быть, а многопутевое устройство должно быть тем, которое я хочу, но это совсем не влияет на производительность, по крайней мере, в случае буферного кеша.
Ваш dd oflag=direct наблюдения могут быть связаны с проблемами управления питанием. Использовать PowerTOP чтобы увидеть, не слишком ли часто C-состояния вашего процессора переключаются выше C1 при загрузке записи. Если это так, попробуйте настроить PM, чтобы ЦП не спал, и повторно запустите тесты. Обратитесь к документации вашего дистрибутива, чтобы узнать, как это сделать - в большинстве случаев это будет intel_idle.max_cstate=0 параметр строки загрузки ядра, но YMMV.
Огромная разница в производительности между O_DIRECT запись и буферизованная запись могут быть вызваны:
Это очень похоже на узкое место, вызванное единственным потоком в md.
dd run показывает 170 МБ/ с+ на диск, поэтому путь не ограничен пропускной способностью подключения PCIeПока патчи для расчета контрольной суммы многопоточного RAID5 были привержены mdraid в 2013 году я ничего не могу найти о подобных усовершенствованиях RAID1 / RAID10, поэтому их может просто не быть.
ddпросто чтобы посмотреть, не изменится ли что-нибудьFWIW, вы редко (если вообще когда-либо) увидите пик производительности записи (особенно с файловой системой, отличной от CoW) при пропускной способности с механическими носителями. В большинстве случаев вы будете ограничены временем поиска, поэтому пиковая пропускная способность не должна вызывать особого беспокойства, если она соответствует вашим минимальным требованиям.
1 если вы делать ZFS, вам следует усовершенствовать свой метод тестирования, так как запись блоков с нулевым значением в набор данных ZFS может быть произвольно быстрой. Нули не записываются на диски, а просто связаны с нулевым блоком, если для набора данных включено сжатие.