Это продолжение: Высокоскоростная сетевая запись с хранилищем большой емкости. Установка заметно изменилась.
У меня есть пул с синглом рейд-z2 с 6 дисками, все диски Exos X18 CMR. С использованием фио и ручные тесты Я знаю, что массив может поддерживать последовательную запись со скоростью около 800 МБ/с в среднем, это нормально и соответствует ожидаемой производительности этого массива. Машина представляет собой Ryzen5 Pro 2400 GE (4 ядра/8 потоков, повышение частоты до 3,8 ГГц) с 32 ГБ ОЗУ ECC, загрузочным/системным диском NVMe и двумя портами Ethernet 10 Гбит/с (Intel x550-T2). Я использую новейшую систему Arch с zfs 2.1.2-1.
Мой вариант использования - это видеоархив, состоящий в основном из больших (~ 30 ГБ) однократно записываемых, однократно прочитанных, сжатых видео. я отключил время, установлен размер записи=1M, установлен сжатие = выкл. и дедупликация = выкл. так как данные на самом деле несжимаемы и тестирование показало худшую производительность с сжатие=lz4 чем выключенный несмотря на то, что сказал Интернет, и нет никаких дубликатов данных по замыслу. Этот пул расшаривается по сети через Samba. Я настроил свою сеть и Samba до такой степени, что передача с NVMe NTFS на компьютере с Windows на NVMe ext4 достигает 1 ГБ/с, т. е. достаточно близко к насыщению канала 10 Гбит/с 9K Jumbo Frames.
Вот где я сталкиваюсь с проблемами. Я хочу иметь возможность передавать один целый видеоархив 30G со скоростью 1 ГБ/с на рейд-z2 массив, поддерживающий последовательную запись только со скоростью 800 МБ/с. Мой план состоит в том, чтобы использовать грязные страницы на основе ОЗУ, чтобы поглотить распространение и позволить им сбрасываться на диск после того, как передача «завершена» на стороне клиента. Я подумал, что все, что мне нужно, это (1024-800)*30~=7Г грязных страниц в оперативной памяти, которые могут быть сброшены на диск в течение примерно 10 секунд после завершения передачи. Я понимаю последствия этого для целостности данных, и риск приемлем, поскольку я всегда могу снова передать файл позже на срок до месяца, если сбой питания приведет к потере или неполному файлу.
Однако я не могу заставить ZFS вести себя так, как я ожидаю... Я отредактировал свой /etc/modprobe.d/zfs.conf файл так:
параметры zfs zfs_dirty_data_max_max=25769803776
параметры zfs zfs_dirty_data_max_max_percent=50
параметры zfs zfs_dirty_data_max=25769803776
параметры zfs zfs_dirty_data_max_percent=50
параметры zfs zfs_delay_min_dirty_percent=80
Я выполнил соответствующий mkinitcpio -P команда для обновления моих initramfs и подтвердила, что настройки были применены после перезагрузки:
# arc_summary | grep грязные_данные
zfs_dirty_data_max 25769803776
zfs_dirty_data_max_max 25769803776
zfs_dirty_data_max_max_percent 50
zfs_dirty_data_max_percent 50
zfs_dirty_data_sync_percent 20
т.е. Я установил максимальное количество грязных страниц на 24 ГБ, что намного больше, чем 7 ГБ, которые мне нужны, и удерживаю, чтобы начать откладывать запись до тех пор, пока не будет использовано 80%. Насколько я понимаю, пул должен иметь возможность поглощать 19 ГБ в ОЗУ, прежде чем он начнет отталкивать записи от клиента (Samba) с задержкой.
Однако то, что я наблюдаю при записи из клиента Windows, заключается в том, что примерно через 16 секунд при скорости записи ~ 1 ГБ / с производительность записи падает с обрыва (йостат по-прежнему показывает, что диски усердно работают над сбросом данных), что, я могу только предположить, является механизмом отталкивания для регулирования записи ZFS. Однако это не имеет смысла, поскольку, по крайней мере, даже если ничего не было смыто в течение 16 секунд, оно должно было установиться через 3 секунды.Кроме того, в конце он снова отваливается, см. рисунок: [
][https://i.stack.imgur.com/Yd9WH.png]
Я пытался настроить zfs_dirty_data_sync_percent чтобы начать писать раньше, потому что буфер грязной страницы намного больше, чем по умолчанию, и я также пытался настроить активное масштабирование ввода-вывода с помощью zfs_vdev_async_write_active_{мин.,макс.}_dirty_percent чтобы ускорить запись с помощью большого грязного буфера. Оба они просто немного изменили положение утеса, но не так близко, как я ожидал.
Вопросы:
- Я неправильно понял, как работает задержка регулирования записи?
- Возможно ли то, что я пытаюсь сделать?
- Если да, то что я делаю неправильно?
Да, я знаю, я буквально гонюсь за парой секунд и никогда не окуплю усилий, потраченных на достижение этого. Все в порядке, на данный момент это личное между мной и ZFS и дело принципа ;)
