Повільна швидкість послідовності на 9x7-накопичувачі raidz2 (ZFS ZoL 0.8.1)


9

Я використовую великий пул ZFS, побудований для послідовного зчитування розміру 256K + запиту та запису через iSCSI (для резервного копіювання) на Ubuntu 18.04. Враховуючи потребу у високій пропускній здатності та просторовій ефективності та меншій потребі у випадкових низькоблокових робочих характеристиках, я перейшов з смугастим рейд2 на смугасті дзеркала.

Однак продуктивність послідовного читання 256K набагато нижча, ніж я очікував (100 - 200 Мбіт / с, піки до 600 Мбіт / с). Коли дзвінки потрапляють ~ 99% iowait в iostat, резервні пристрої зазвичай працюють від 10 до 40% iowait, що підказує мені, що вузьке місце мені щось не вистачає в конфігурації, враховуючи, що це не повинно бути заднім планом або процесорами в ця система та послідовне навантаження не повинні працювати надто сильно.

Я грав трохи з параметрами модуля (поточна конфігурація нижче), читав сотні статей, проблеми на OpenZFS github і т. Д. Настроювання попереднього вибору та агрегації привело мене до цього рівня продуктивності - за замовчуванням я працював приблизно на ~ 50 Мбіт / с послідовне зчитування, коли ZFS надсилав TINY запити на диски (~ 16K). Коли агрегація та попереднє завантаження працюють добре (я думаю), читання дисків набагато вище, в середньому - 64 кк в іостаті.

NIC - це LIO iscsi-мішень із завантаженням cxgbit + Windows Chelsio iscsi-ініціатор працює добре поза ZFS-дзвінками, з оптаном, безпосередньо відображеним на карті, повертаючи майже повну лінійну швидкість в NIC (~ 3,5 Гбіт / с читання та запису).

Я чекаю занадто багато? Я знаю, що ZFS надає пріоритет безпеці щодо продуктивності, але я б очікував, що 7x9 raidz2 забезпечить кращі послідовні зчитування, ніж один одиночний mdadm-рейд на 9 приводів6.

Специфікації системи та журнали / конфігураційні файли:

Chassis: Supermicro 6047R-E1R72L
HBAs: 3x 2308 IT mode (24x 6Gbps SAS channels to backplanes)
CPU: 2x E5-2667v2 (8 cores @ 3.3Ghz base each)
RAM: 128GB, 104GB dedicated to ARC
HDDs: 65x HGST 10TB HC510 SAS (9x 7-wide raidz2 + 2 spares)
SSDs: 2x Intel Optane 900P (partitioned for mirrored special and log vdevs)
NIC: Chelsio 40GBps (same as on initiator, both using hw offloaded iSCSI)
OS: Ubuntu 18.04 LTS (using latest non-HWE kernel that allows ZFS SIMD)
ZFS: 0.8.1 via PPA
Initiator: Chelsio iSCSI initiator on Windows Server 2019

Конфігурація басейну:

ashift=12
recordsize=128K (blocks on zvols are 64K, below)
compression=lz4
xattr=sa
redundant_metadata=most
atime=off
primarycache=all

Конфігурація ZVol:

sparse
volblocksize=64K (matches OS allocation unit on top of iSCSI)

Схема басейну:

7x 9-wide raidz2
mirrored 200GB optane special vdev (SPA metadata allocation classes)
mirrored 50GB optane log vdev

/etc/modprobe.d/zfs.conf:

# 52 - 104GB ARC, this system does nothing else
options zfs zfs_arc_min=55834574848
options zfs zfs_arc_max=111669149696

# allow for more dirty async data
options zfs zfs_dirty_data_max_percent=25
options zfs zfs_dirty_data_max=34359738368

# txg timeout given we have plenty of Optane ZIL
options zfs zfs_txg_timeout=5

# tune prefetch (have played with this 1000x different ways, no major improvement except max_streams to 2048, which helped, I think)
options zfs zfs_prefetch_disable=0
options zfs zfetch_max_distance=134217728
options zfs zfetch_max_streams=2048
options zfs zfetch_min_sec_reap=3
options zfs zfs_arc_min_prefetch_ms=250
options zfs zfs_arc_min_prescient_prefetch_ms=250
options zfs zfetch_array_rd_sz=16777216

# tune coalescing (same-ish, increasing the read gap limit helped throughput in conjunction with low async read max_active, as it caused much bigger reads to be sent to the backing devices)
options zfs zfs_vdev_aggregation_limit=16777216
options zfs zfs_vdev_read_gap_limit=1048576
options zfs zfs_vdev_write_gap_limit=262144

# ZIO scheduler in priority order 
options zfs zfs_vdev_sync_read_min_active=1
options zfs zfs_vdev_sync_read_max_active=10
options zfs zfs_vdev_sync_write_min_active=1
options zfs zfs_vdev_sync_write_max_active=10
options zfs zfs_vdev_async_read_min_active=1
options zfs zfs_vdev_async_read_max_active=2
options zfs zfs_vdev_async_write_min_active=1
options zfs zfs_vdev_async_write_max_active=4

# zvol threads
options zfs zvol_threads=32

Я відриваю волосся на цьому. Натискання тисне на користувачів, щоб перейти на всі Windows з просторами зберігання, але я використовував простори зберігання паритету (навіть із Storage Spaces Direct з дзеркалами вгорі), і це не дуже. Мені спокуса перейти прямо на mdadm raid60 під iSCSI, але хотілося б, якби хтось міг вказати на щось з немилосердним голосом, що мені не вистачає, що розблокує продуктивність із захистом бітрота ZFS :)

Відповіді:


7

Хороше питання.

  • Я думаю, що ваш розріджений блок zvol повинен бути 128k.
  • Усі ваші налаштування планувальника ZIO повинні бути вищими, як мінімум 10 та максимум 64.
  • zfs_txg_timeout має бути набагато довше. Я роблю 15 або 30 років у своїх системах.
  • Я думаю, що декілька RAIDZ3 (або це була помилка) були надмірними і грають велику роль у виконанні. Чи можете ви орієнтуватися на RAIDZ2?

Редагувати: Встановіть Netdata в систему, відстежуйте використання та статистику ZFS.

Edit2: це для сховища Veeam. Veeam підтримує Linux як ціль і чудово працює з ZFS. Чи можете ви розглянути можливість порівняльного аналізу даних зі своїми даними? zvols не є ідеальним випадком використання для того, що ви робите, якщо тільки завантаження NIC не є критичною частиною рішення.


Дякую! Покроково в коментарях, що випливають за винятком, за винятком Z3, який справді був друком :). У volblocksize я тестував і 128k, і 64k, і продуктивність не дуже змінилася для послідовних читань. 128k, ймовірно, буде дещо більш економічно простір, але 64k відповідає розміру одиниці розподілу ОС клієнт-ініціатор, і, схоже, робить значно кращим у сценаріях випадкових вводу-виводу (які рідкісні), при цьому не має великого значення в послідовних сценаріях вводу-виводу. .
obrienmd

Я тестую з txg_timeout вище - чи це має значення, як мінімум, для послідовного читання? Враховуючи низький вміст ходу на резервних дисках, схоже, що флеші запису суперечать / значно впливають на середню швидкість читання.
obrienmd

1
НАЙБІЛЬШІ цікаві відгуки, які я маю для вас (я думаю), стосується планувальника ZIO. Коли я переміщую голку на асинхронних хвилинах і максимах, вона руйнує агрегацію іо, і чистий результат є досить поганим. Для читання, що мене тут дуже цікавить, оскільки записи чудові, перехід на 10/64 робить середній IO на диски ~ 16 КБ в іостаті, а середня швидкість читання скорочується на 75% (~ 30 - 60 Мбіт / с) з урахуванням цих дисків 'IOPS. Я також налаштував синхронізацію, прочитавши #, і не бачив жодного впливу, але я дам ще один кадр незалежно :)
obrienmd

zfs zfs_dirty_data_max_percent = 25 - там я зазвичай 40% або більше.
ewwhite

О, читання - це проблема? Що це за дані? Наскільки заповнений басейн?
ewwhite
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.