У меня есть связанный вопрос об этой проблеме, но он стал слишком сложным и слишком большим, поэтому я решил разделить проблему на NFS и локальные проблемы. Я также пытался спросить об этом в списке рассылки zfs-обсуждения без особого успеха.
Медленное копирование между каталогами NFS / CIFS на одном сервере
Схема: как я настроен и что я ожидаю
- У меня есть пул ZFS с 4 дисками. 2TB RED настроен как 2 зеркала с чередованием (RAID 10). В Linux zfsonlinux. Нет кеша или логов устройства.
- Данные сбалансированы по зеркалам (важно для ZFS)
- Каждый диск может читать (raw w / dd) со скоростью 147 МБ / с параллельно, что дает общую пропускную способность 588 МБ / с.
- Я ожидаю около 115 МБ / с записи, 138 МБ / с чтения и 50 МБ / с перезаписи последовательных данных с каждого диска, основываясь на тестах аналогичного 4 ТБ КРАСНОГО диска. Я ожидаю не менее 100 МБ / с для чтения или записи, поскольку любой диск может сделать это в наши дни.
- Я думал, что увижу 100% ввода-вывода на всех 4 дисках, когда под нагрузкой читаю или записываю последовательные данные. И что диски будут выдавать более 100 МБ / с при 100% загрузке.
- Я думал, что пул даст мне примерно 2x запись, 2x перезапись и 4x производительность чтения на одном диске - я не прав?
- NEW Я думал, что ext4 zvol в том же пуле будет примерно с той же скоростью, что и ZFS
Что я на самом деле получаю
Я считаю, что производительность чтения пула не так высока, как я ожидал
Бонни ++ тест на пул от нескольких дней назад
Версия 1.97 ------ Последовательный вывод ------ - Последовательный ввод- - Случайный- Параллелизм 1 -Per Chr- -Block-- -Переписать- -Per Chr- -Block-- -Seeks-- Размер машины K / сек% CP K / сек% CP K / сек% CP K / сек% CP K / сек% CP K / сек% CP / сек% CP igor 63G 99 99 232132 47 118787 27 336 97 257072 22 92,7 6
bonnie ++ на отдельном 4TB RED диске самостоятельно в zpool
Версия 1.97 ------ Последовательный вывод ------ - Последовательный ввод- - Случайный- Параллелизм 1 -Per Chr- -Block-- -Переписать- -Per Chr- -Block-- -Seeks-- Размер машины K / сек% CP K / сек% CP K / сек% CP K / сек% CP K / сек% CP K / сек% CP / сек% CP igor 63G 101 99 115288 30 49781 14 326 97 138250 13 111,6 8
В соответствии с этим скорости чтения и перезаписи являются подходящими на основе результатов от одного КРАСНОГО накопителя емкостью 4 ТБ (они двойные). Однако скорость чтения, которую я ожидал, составила бы около 550 МБ / с (в 4 раза больше, чем у диска 4 ТБ), и я бы, по крайней мере, надеялся на скорость около 400 МБ / с. Вместо этого я вижу около 260 МБ / с
bonnie ++ о пуле только сейчас, собирая нижеприведенную информацию. Не совсем так, как раньше, и ничего не изменилось.
Версия 1.97 ------ Последовательный вывод ------ - Последовательный ввод- - Случайный- Параллелизм 1 -Per Chr- -Block-- -Переписать- -Per Chr- -Block-- -Seeks-- Размер машины K / сек% CP K / сек% CP K / сек% CP K / сек% CP K / сек% CP K / сек% CP / сек% CP igor 63G 103 99 207518 43 108810 24 342 98 302350 26 256,4 18
зпул иостать во время записи. Кажется, хорошо для меня.
пропускная способность операций пропускная способность Выделите пул бесплатно читать писать читать -------------------------------------------- ----- - ---- ----- ----- ----- ----- pool2 1.23T 2.39T 0 1.89K 1.60K 238M зеркало 631G 1,20T 0 979 1,60K 120M ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 0 1007 1,60K 124M ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 0 975 0 120 М зеркало 631G 1,20T 0 953 0 117M ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 0 1,01K 0 128M ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 0 953 0 117M
зпул иостат во время перезаписи. Кажется , хорошо ко мне, я думаю .
пропускная способность операций пропускная способность Выделите пул бесплатно читать писать читать -------------------------------------------- ----- - ---- ----- ----- ----- ----- pool2 1,27 т 2,35 т 1015 923 125 м 101 м зеркало 651G 1.18T 505 465 62.2M 51.8M ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 198 438 24,4 млн. 51,7 млн. ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 306 384 37,8 млн. 45,1 млн. зеркало 651G 1.18T 510 457 63.2M 49.6M ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 304 371 37,8 млн. 43,3 млн. ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 206 423 25,5 млн. 49,6 млн.
Вот где мне интересно, что происходит
зпул иостат во время чтения
пропускная способность операций пропускная способность Выделите пул бесплатно читать писать читать -------------------------------------------- ----- - ---- ----- ----- ----- ----- pool2 1.27T 2.35T 2.68K 32 339M 141K зеркало 651G 1.18T 1.34K 20 169M 90.0K ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 748 9 92,5M 96,8 КБ ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 623 10 76,8 М 96,8 КБ зеркало 651G 1.18T 1.34K 11 170M 50.8K ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 774 5 95,7M 56,0K ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 599 6 74,0 М 56,0 К
iostat -x во время той же операции чтения. Обратите внимание, что IO% не на 100%.
Устройство: rrqm / s wrqm / sr / sw / s rkB / s wkB / s avgrq-sz avgqu-sz await r_await w_await svctm% util SDB 0,60 0,00 661,30 6,00 83652,80 49,20 250,87 2,32 3,47 3,46 4,87 1,20 79,76 сдд 0,80 0,00 735,40 5,30 93273,20 49,20 251,98 2,60 3,51 3,51 4,15 1,20 89,04 sdf 0,50 0,00 656,70 3,80 83196,80 31,20 252,02 2,23 3,38 3,36 6,63 1,17 77,12 sda 0,70 0,00 738,30 3,30 93572,00 31,20 252,44 2,45 3,33 3,31 7,03 1,14 84,24
Настройки zpool и тестового набора данных:
- время выключено
- сжатие выключено
- ashift - 0 (автоопределение - насколько я понимаю, это нормально)
- ZDB говорит, что все диски Ashift = 12
- модуль - параметры zfs zvol_threads = 32 zfs_arc_max = 17179869184
- синхронизация = стандартная
Изменить - 30 октября 2015 г.
Я сделал еще несколько испытаний
- набор данных bonnie ++ w / recordsize = 1M = 226MB для записи, 392MB для чтения намного лучше
- набор данных dd w / размер записи = 1M = 260MB записи, 392MB читать намного лучше
- zvol w / ext4 dd bs = 1M = 128MB write, 107MB read почему так медленно?
- набор данных 2 обрабатывается параллельно = запись 227 МБ, чтение 396 МБ
- dd direct io не делает различий в наборе данных и в zvol
Я намного доволен выступлением с увеличенным размером записи. Почти каждый файл в пуле занимает более 1 МБ. Так что я оставлю это так. Диски все еще не загружаются на 100%, что заставляет меня задуматься, может ли это быть намного быстрее. И теперь я задаюсь вопросом, почему производительность zvol такая паршивая, потому что я этим (слегка) пользуюсь.
Я рад предоставить любую запрашиваемую информацию в комментариях / ответах. В моем другом вопросе также содержится масса информации: медленное копирование между каталогами NFS / CIFS на одном сервере.
Я полностью осознаю, что я могу просто что-то не понимать и что это может вообще не быть проблемой. Заранее спасибо.
Чтобы прояснить ситуацию, возникает вопрос: почему пул ZFS не так быстр, как я ожидаю? И, может быть, что-то еще не так?
dd
чтобы увидеть, какую производительность вы получите. Возможно, вы также захотите попробовать прямой ввод-вывод, когда вы переходите на скорости потоковой передачи, где двойная буферизация из-за кеширования может повлиять на производительность. FWIW, 3/4 теоретической общей производительности чтения с 4-х дисков хороша.%util
цифры.Ответы:
Мне удалось получить скорость очень близко к числам, которые я ожидал.
Я искал 400 МБ / сек и управляемый 392MB / сек . Поэтому я говорю, что проблема решена. С последующим добавлением устройства кэш-памяти мне удалось прочитать 458 МБ / с (кешируется, я полагаю).
1. Сначала это было достигнуто просто путем увеличения
recordsize
значения набора данных ZFS до1M
Я полагаю, что это изменение приводит только к меньшей активности на диске, что позволяет более эффективно выполнять большие синхронные операции чтения и записи. Именно то, что я просил.
Результаты после изменения
2. Мне удалось еще лучше, когда я добавил кэш-устройство (120 ГБ SSD). Запись немного медленнее, я не знаю почему.
Трюк с устройством кеша заключался в том, чтобы установить
l2arc_noprefetch=0
в /etc/modprobe.d/zfs.conf . Это позволяет ZFS кэшировать потоковые / последовательные данные. Делайте это только в том случае, если ваше кеш-устройство работает быстрее вашего массива, например, моегоПолучив выгоду от изменения размера записи в моем наборе данных, я подумал, что это может быть аналогичный способ справиться с плохой производительностью zvol.
Я столкнулся с некоторыми людьми, которые упомянули, что они добились хороших результатов при использовании
volblocksize=64k
, поэтому я попробовал это. Не повезло.Но потом я прочитал, что ext4 (файловая система, с которой я тестировал) поддерживает опции для RAID, например,
stride
иstripe-width
которые я никогда раньше не использовал. Поэтому я использовал этот сайт для расчета необходимых настроек: https://busybox.net/~aldot/mkfs_stride.html и снова отформатировал zvol.Я побежал,
bonnie++
чтобы сделать простой тест, и результаты были превосходны. К сожалению, у меня нет результатов, но, насколько я помню, они были как минимум в 5-6 раз быстрее для записей. Я обновлю этот ответ еще раз, если я снова проведу тестирование.источник
Ваши результаты вполне разумны, в то время как ваши ожидания не таковы: вы преувеличиваете улучшение производительности чтения, предоставляемое RAID1 (и, соответственно, RAID10). Дело в том, что двухстороннее зеркалирование дает максимум 2-кратную скорость чтения / IOP для одного диска, но реальная производительность может быть где-то между 1x-2x.
Давайте уточним на примере. Представьте, что у вас есть система с двухсторонним зеркалом, каждый диск имеет скорость 100 МБ / с (последовательная) и 200 IOPS. С глубиной очереди 1 (макс один сингл, выдающее запрос) этот массив будет иметь не преимущество по сравнению с одним диском: RAID1 расщепляет IO запросы на очереди Два диска, но это не расколоть один запрос в течение двух дисков (по крайней мере, любая реализация, которую я видел, ведет себя таким образом). С другой стороны, если ваша очередь ввода-вывода больше (например, у вас 4/8 невыполненных запросов), общая пропускная способность диска будет значительно выше, чем у одного диска.
Аналогичное замечание можно сделать для RAID0, но в этом случае средние улучшения определяются не только размером очереди, но и размером запроса IO : если ваш средний размер IO меньше размера чанка, он не будет чередоваться. на двух (или более) дисках, но он будет обслуживаться одним. Ваши результаты с увеличенным размером записей Bonnie ++ показывают это точное поведение: чередование значительно выигрывает от большего размера ввода-вывода.
Теперь должно быть ясно, что объединение двух уровней RAID в массиве RAID10 не приведет к линейному масштабированию производительности, но устанавливает для него верхний предел . Я вполне уверен, что если вы запустите несколько экземпляров dd / bonnie ++ (или
fio
будете использовать их для прямой манипуляции с очередью ввода-вывода), вы получите результаты, более совпадающие с вашими первоначальными ожиданиями, просто потому, что вы будете облагать налогом массив IO более полным образом ( несколько выдающихся последовательных / случайных запросов ввода-вывода), а не загружать его только из одних последовательных запросов ввода-вывода.источник