ZFS пул повільного послідовного читання

У мене є відповідне запитання щодо цієї проблеми, але воно стало занадто складним і занадто великим, тому я вирішив розділити цю проблему на NFS та місцеві проблеми. Я також намагався запитати про це в списку розсилки zfs-обговорювати без особливого успіху.

Повільне копіювання між каталогами NFS / CIFS на одному сервері

Контур: Як я налаштовуюсь і що я очікую

1. У мене є басейн ZFS з 4 дисками. Червоний 2 Тб, сконфігурований як 2 дзеркала з смугастим (RAID 10). У Linux, zfsonlinux. Немає пристроїв кешу чи журналу.
2. Дані збалансовані через дзеркала (важливо для ZFS)
3. Кожен диск може читати (необроблений w / dd) зі швидкістю 147 Мб / сек паралельно, даючи комбіновану пропускну здатність 588 МБ / сек.
4. Я очікую приблизно 115 Мб / сек запису, 138 МБ / сек зчитування та 50 МБ / сек перезапис послідовних даних з кожного диска, грунтуючись на орієнтирах подібного 4 ТБ червоного диска. Я очікую не менше 100 Мб / сек для читання чи запису, оскільки будь-який диск може зробити це сьогодні.
5. Я думав, що побачу 100% використання IO на всіх 4 дисках під час читання або завантаження послідовних даних. І що диски випускатимуть понад 100 Мб / сек при 100% використанні.
6. Я думав, що пул дасть мені близько 2x запису, 2x переписання та 4-кратну швидкість читання на одному диску - я помиляюся?
7. NEW Я думав, що ext4 zvol на тому ж пулі буде приблизно такою ж швидкістю , як ZFS

Що я насправді отримую

Я вважаю, що показник читання пулу не є настільки високим, як я очікував

bonnie ++ орієнтир у басейні від декількох днів тому

Версія 1.97 ------ Послідовний вихід ------ - Послідовний вхід- - Випадковий-
Паралельність 1 -Per Chr- --блок-- -записати- -Per Chr- --блок-- - дивиться--
Розмір машини 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

боні ++ на одному 4-кратному червоному приводі самостійно в зопулі

Версія 1.97 ------ Послідовний вихід ------ - Послідовний вхід- - Випадковий-
Паралельність 1 -Per Chr- --блок-- -записати- -Per Chr- --блок-- - дивиться--
Розмір машини 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 ТБ (вони подвійні). Однак швидкість читання, яку я очікував, складе близько 550 Мб / сек (4 рази швидкість 4 ТБ приводу), і я, принаймні, сподіваюся на близько 400 МБ / сек. Натомість я бачу близько 260 Мб / сек

Bonnie ++ у басейні з цього часу, збираючи інформацію нижче. Не зовсім так, як раніше, і нічого не змінилося.

Версія 1.97 ------ Послідовний вихід ------ - Послідовний вхід- - Випадковий-
Паралельність 1 -Per Chr- --блок-- -записати- -Per Chr- --блок-- - дивиться--
Розмір машини 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 під час запису. Мені здається нормально.

                                                 пропускна спроможність операцій
pool alloc безкоштовно читати читати читати писати
-------------------------------------------- ----- - ---- ----- ----- ----- -----
басейн2 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 124М
    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 128М
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 0 953 0 117М

zpool iostat під час перезапису. Здається , добре до мене, я думаю .

                                                 пропускна спроможність операцій
pool alloc безкоштовно читати читати читати писати
-------------------------------------------- ----- - ---- ----- ----- ----- -----
басейн2 1,27T 2,35T 1015 923 125M 101M
  дзеркало 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
  дзеркало 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 під час читання

                                                 пропускна спроможність операцій
pool alloc безкоштовно читати читати читати писати
-------------------------------------------- ----- - ---- ----- ----- ----- -----
басейн2 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.8K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 623 10 76,8M 96,8K
  дзеркало 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

іостат -x під час тієї ж операції зчитування. Зверніть увагу, як IO% не на 100%.

Пристрій: rrqm / s wrqm / sr / sw / s rkB / s wkB / s avgrq-sz avgqu-sz очікуємо r_await w_await svctm% util
sdb 0,60 0,00 661,30 30,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,50 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 каже, що всі диски швидко змінилися = 12
• модуль - параметри zfs zvol_threads = 32 zfs_arc_max = 17179869184
• sync = стандарт

Редагувати - 30 жовтня 2015 року

Я зробив ще кілька тестувань

• набір даних Bonnie ++ w / recordsize = 1M = 226MB write, 392MB читати набагато краще
• набір даних dd w / size size = 1M = 260MB write, 392MB читати набагато краще
• zvol w / ext4 dd bs = 1M = 128MB написати, 107MB читати, чому так повільно?
• набір даних 2 процесора паралельно = 227 Мб запису, зчитування 396 МБ
• dd direct io не відрізняється як на наборі даних, так і на zvol

Я набагато щасливіший за продуктивність із збільшеним розміром запису. Практично кожен файл у пулі перевищує 1 Мб. Тож я залишу це так. Диски все ще не отримують 100% використання, що змушує мене замислитись, чи все ще це може бути набагато швидше. І тепер мені цікаво, чому продуктивність zvol настільки хитра, як це я (злегка) використовую.

Я радий надати будь-яку інформацію, яку вимагають у коментарях / відповідях. Також є багато тонн інформації, розміщеної в іншому моєму запитанні: Повільне копіювання між каталогами NFS / CIFS на одному сервері

Я цілком усвідомлюю, що, можливо, я просто щось не розумію і що це може зовсім не бути проблемою. Заздалегідь спасибі.

Щоб зрозуміти, питання: Чому пул ZFS не такий швидкий, як я очікував? А може, є ще щось не так?

Мені вдалося досягти швидкості дуже близької до тих цифр, яких я очікував.

Я шукав 400 МБ / сек і керований 392MB / сек . Тому я кажу, що проблема вирішена. З пізнішим додаванням кеш-пристрою мені вдалося прочитати 458 Мб / сек (я вважаю кешований).

1. Це спочатку було досягнуто просто шляхом збільшення recordsizeзначення набору даних ZFS до1M

zfs set recordsize=1M pool2/test

Я вважаю, що ця зміна просто призводить до меншої активності диска, таким чином, більш ефективних великих синхронних читання і запису. Саме те, про що я просив.

Результати після зміни

• bonnie ++ = 226MB запису, 392MB прочитати
• dd = 260MB запису, 392MB читання
• 2 паралельні процеси = 227 Мб запису, зчитування 396 Мб

2. Мені вдалося ще краще, коли я додав кеш-пристрій (120 ГБ SSD). Писання йде в рази повільніше, я не знаю, чому.

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 і знову відформатував zvol.

mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/zvol/pool/volume

Я побіг bonnie++зробити простий орієнтир, і результати були відмінні. На жаль, я не маю результатів, але, як я пам'ятаю, вони були на 5-6 разів швидшими. Цю відповідь я ще раз оновлю, якщо знову буду орієнтиром.

Ваші результати цілком розумні, тоді як ваші очікування не такі: ви завищуєте покращення продуктивності читання, яке дає RAID1 (і, в розширенні, RAID10). Справа в тому, що двостороннє дзеркальне відображення дає максимум 2x швидкості читання / ВВП одного диска, але реальна продуктивність у світі може бути десь між 1x-2x.

Давайте уточнимо на прикладі. Уявіть, що у вас є система з двостороннім дзеркалом, кожен диск здатний до 100 Мб / с (послідовний) та 200 IOPS. З глибиною черги 1 (макс один сингл, котре видає запит) цей масив буде мати НЕ перевага по порівняно з одним диском: RAID1 розщеплює IO запити на черзі Два диска, але це НЕ розколоти один запит в протягом двох дисків (по крайней мере, будь-яка реалізація, яку я бачив, поводиться таким чином). З іншого боку, якщо ваша черга вводу-виводу більша (наприклад: у вас 4/8 невирішених запитів), загальна пропускна здатність диска буде значно вище, ніж на одному диску.

Аналогічний момент можна зробити і для RAID0, але в цьому випадку те, що визначає середнє поліпшення, - це функція не тільки розміру черги, але і розміру запиту IO : якщо ваш середній розмір IO нижчий за розмір, це не буде смугастим на двох (або більше) дисках, але він буде обслуговуватися одним. Ваші результати із збільшеним записом Bonnie ++ свідчать про таку точну поведінку: роздягання значно виграє від великого розміру вводу-виводу.

Тепер має бути зрозуміло, що поєднання двох рівнів RAID в масиві RAID10 не призведе до лінійного масштабування продуктивності, але воно встановить для нього верхню межу . Я майже впевнений, що якщо ви запускаєте кілька екземплярів dd / bonnie ++ (або використовуєте fioдля прямої маніпуляції чергою IO), ви отримаєте результати більш відповідні з вашим початковим очікуванням, просто тому, що ви будете оподатковувати свій масив IO більш повно ( кілька постійних послідовних / випадкових запитів вводу-виводу), а не завантаження їх одних, послідовних запитів вводу-виводу.