У меня есть связанный с этой проблемой вопрос, но он стал слишком сложным и слишком большим, поэтому я решил разделить проблему на NFS и локальные проблемы. Я также без особого успеха пытался спросить об этом в списке рассылки zfs-обсуждения.
Медленное копирование между каталогами NFS / CIFS на одном сервере
Краткое описание: как я настроен и чего я ожидаю
Что я на самом деле получаю
Я считаю, что производительность чтения пула не так высока, как я ожидал
Бонни ++ тест пула несколько дней назад
Version 1.97 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP igor 63G 99 99 232132 47 118787 27 336 97 257072 22 92.7 6
Бонни ++ на отдельном диске RED емкостью 4 ТБ отдельно в zpool
Version 1.97 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP igor 63G 101 99 115288 30 49781 14 326 97 138250 13 111.6 8
В соответствии с этим скорости чтения и перезаписи являются подходящими на основе результатов для одного диска 4 ТБ RED (они двойные). Тем не менее, скорость чтения, которую я ожидал, составила бы около 550 МБ / с (в 4 раза больше, чем у диска 4 ТБ), и я бы по крайней мере надеялся на около 400 МБ / с. Вместо этого я вижу около 260 МБ / сек.
Бонни ++ на пуле прямо сейчас, пока мы собираем информацию ниже. Не совсем так, как раньше, и ничего не изменилось.
Version 1.97 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP igor 63G 103 99 207518 43 108810 24 342 98 302350 26 256.4 18
zpool iostat во время записи. Мне кажется, все в порядке.
capacity operations bandwidth
pool alloc free read write read write
-------------------------------------------- ----- ----- ----- ----- ----- -----
pool2 1.23T 2.39T 0 1.89K 1.60K 238M
mirror 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 120M
mirror 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
zpool iostat во время перезаписи. Мне кажется, все в порядке, думаю.
capacity operations bandwidth
pool alloc free read write read write
-------------------------------------------- ----- ----- ----- ----- ----- -----
pool2 1.27T 2.35T 1015 923 125M 101M
mirror 651G 1.18T 505 465 62.2M 51.8M
ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 198 438 24.4M 51.7M
ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 306 384 37.8M 45.1M
mirror 651G 1.18T 510 457 63.2M 49.6M
ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 304 371 37.8M 43.3M
ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 206 423 25.5M 49.6M
Вот где мне интересно, что происходит
zpool iostat во время чтения
capacity operations bandwidth
pool alloc free read write read write
-------------------------------------------- ----- ----- ----- ----- ----- -----
pool2 1.27T 2.35T 2.68K 32 339M 141K
mirror 651G 1.18T 1.34K 20 169M 90.0K
ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 748 9 92.5M 96.8K
ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 623 10 76.8M 96.8K
mirror 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.0M 56.0K
iostat -x во время той же операции чтения. Обратите внимание на то, что IO% не равен 100%.
Device: rrqm/s wrqm/s r/s w/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 sdd 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 ++ с размером записи = 1M = 226MB запись, 392MB чтение намного лучше
- набор данных dd с размером записи = 1M = 260 МБ на запись, 392 МБ на чтение намного лучше
- zvol w / ext4 dd bs = 1M = 128MB запись, 107MB чтение почему так медленно?
- набор данных 2 параллельно обрабатывается = 227 МБ на запись, 396 МБ на чтение
- dd direct io ничем не отличается от набора данных и zvol
Мне гораздо больше понравилось исполнение с увеличенным размером записи. Практически каждый файл в пуле имеет размер более 1 МБ. Так что я оставлю это как есть. Диски по-прежнему не загружаются на 100%, что заставляет меня задуматься, может ли это быть намного быстрее. И теперь мне интересно, почему производительность zvol такая паршивая, если я (слегка) использую это.
Я рад предоставить любую запрошенную информацию в комментариях / ответах. В другом моем вопросе также есть масса информации: Медленное копирование между каталогами NFS / CIFS на одном сервере
Я полностью осознаю, что могу просто чего-то не понимать и это может не быть проблемой. Заранее спасибо.
Чтобы было понятно, вопрос: Почему пул ZFS не работает так быстро, как я ожидал? А может, что-то еще не так?
Мне удалось набрать скорость, очень близкую к ожидаемой.
Я искал 400 МБ / с и удалось 392 МБ / с. Итак, я говорю, что проблема решена. С последующим добавлением кэш-памяти мне удалось 458 МБ/ сек чтения (кажется, кешировано).
1. Сначала это было достигнуто простым увеличением набора данных ZFS. recordsize ценность для 1M
zfs set recordsize=1M pool2/test
Я считаю, что это изменение просто приводит к меньшей активности диска, а значит, более эффективному синхронному чтению и записи. Именно то, о чем я просил.
Результаты после изменения
2. Мне удалось еще лучше, когда я добавил кэш-устройство (SSD на 120 ГБ). Запись немного медленнее, я не уверен, почему.
Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
igor 63G 208325 48 129343 28 458513 35 326.8 16
Уловка с кеш-устройством заключалась в том, чтобы установить l2arc_noprefetch=0 в /etc/modprobe.d/zfs.conf. Это позволяет ZFS кэшировать потоковые / последовательные данные. Делайте это только в том случае, если ваше кеш-устройство быстрее, чем ваш массив, например мой.
Воспользовавшись изменением размера записи в моем наборе данных, я подумал, что это может быть аналогичный способ справиться с низкой производительностью zvol.
Я встретил несколько человек, которые упомянули, что они добились хороших результатов, используя volblocksize=64k, поэтому я попробовал. Не повезло.
zfs create -b 64k -V 120G pool/volume
Но потом я прочитал, что ext4 (файловая система, с которой я тестировал) поддерживает такие параметры для RAID, как stride и stripe-width, которым я никогда раньше не пользовался. Поэтому я использовал этот сайт для расчета необходимых настроек: https://busybox.net/~aldot/mkfs_stride.html и снова форматировал звол.
mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/zvol/pool/volume
Я побежал bonnie++ сделать простой тест, и результаты были отличными. К сожалению, у меня нет результатов, но, насколько я помню, они были как минимум в 5-6 раз быстрее для записи. Я обновлю этот ответ снова, если снова проведу тест.
Ваши результаты вполне разумны, а ваши ожидания - нет: вы преувеличиваете улучшение производительности чтения, которое дает RAID1 (и, соответственно, RAID10). Дело в том, что двухстороннее зеркальное отображение дает в большинстве В 2 раза выше скорость чтения / операций ввода-вывода в секунду по сравнению с одиночным диском, но реальная производительность может быть где-то между 1x-2x.
Поясним на примере. Представьте, что у вас есть система с двусторонним зеркалом, где каждый диск имеет скорость 100 МБ / с (последовательная) и 200 операций ввода-вывода в секунду. При глубине очереди 1 (максимум один невыполненный запрос) этот массив будет иметь нет Преимущество перед одним диском: RAID1 разделяет запросы ввода-вывода на очередь двух дисков, но это делает не разделить один запрос на два диска (по крайней мере, любая реализация, которую я видел, ведет себя таким образом). С другой стороны, если ваша очередь ввода-вывода больше (например, у вас есть 4/8 невыполненных запросов), общая пропускная способность диска будет значительно выше, чем у одного диска.
То же самое можно сделать и для RAID0, но в этом случае средние улучшения определяются не только размером очереди, но и Размер запроса ввода-вывода также: если ваш средний размер ввода-вывода меньше размера блока, то он будет не быть разбитым на два (или более) диска, но обслуживаться он будет одним. Ваши результаты с увеличенным размером записей Bonnie ++ демонстрируют точное поведение: чередование значительно выигрывает от большего размера ввода-вывода.
Теперь должно быть ясно, что объединение двух уровней RAID в массиве RAID10 будет не приводит к линейному масштабированию производительности, но устанавливает верхний предел для этого. Я почти уверен, что если вы запустите несколько экземпляров dd / bonnie ++ (или используете fio для непосредственного управления очередью ввода-вывода) вы получите результаты, более соответствующие вашим исходным ожиданиям, просто потому, что вы будете облагать налогом свой массив ввода-вывода более полным образом (несколько выдающихся последовательных / случайных запросов ввода-вывода), а не загружать его одиночными последовательными Только запросы ввода-вывода.