Утилизация 10Г сети и настройка АРКа по возможности.

[Voy50]

Добрый день, лень по английски печатать, поэтому пока тут.

Вступление: у меня на виндовой машинке в своё время была примо кеш. Эта штука умела писать сначала в ОЗУ(АРК) или быстрый ССД(Л2АРК), а потом уже скидывать на медленные хдд. Эта схема прекрасно работала, но от винды в целом пришлось отказаться по многим причинам. Выбирая ОС для НАСа я хотел виртуализацию и такой же кеш, поэтому выбор пал на трунас скейл(последняя версия). 4650Г, асрок б550 про4, 128 гб ЕЦЦ ОЗУ.

Поставлены 2 сетевухи 550 и 540. Подключение напрямую. Джамбо фреймы и мту 9014. Иперф3 показывает 9,5Г в обе стороны. В общем и целом сеть работает. Витуху менял, тесты на 30 см динии проводил, поэтому сеть на железном уровне априори в идеале.

Теперь встал вопрос о копировании файлов.

Если забирать файлы из НАСа, то всё прекрасно. Первый раз со скоростью ХДД, второй раз из АРКа со скоростью 1,1 Гбайт/сек. 1,1 из 1,25, я считаю прекрасно.

Но когда я заливаю в НАС скорость просаживается до 300-400 Мбайт/сек, а то и до скорости ХДД 80 Мбайт/сек.
Источник - винда 10. ССД самсунг 980 про 4х псай в4.

На сколько я понимаю, когда я сбрасываю файлы в НАС, то они должны попадать сначала в ОЗУ, а потом уже скидываться на ХДД. У меня такого не происходит.

Можно ли настроить трунас так, что бы он сначала принимал файлы в озу ну ли Л2АРК, а потом уже скидывал на ХДД?

 

[mav@]

ZFS и так всегда сначала пишет в ОЗУ, а потом уже сбрасывает на диск. Объем грязных данных ограничен определенный процентом ARC, но по умолчанию не более 4GB. Последнее можно подстроить, но обычно не нужно. L2ARC же по записи не работает, это кеш чтения.

А локально писать пробовал? Отделить скорость дисков от сети чтобы не лечить все сразу?

 

[Voy50]

Сделал пул по умолчанию из 1 диска на nwme pci 4x v3. С пула тянет без проблем и первый раз и последующие 1,1 ГБ. Запись на него то же просаживается до 70-80 МБ.
При этом пинг до сервера стабильный и запущенный окловский спидтест в это время выдает тарифные 500 мбит. Т.е. это явно не сеть захлебывается. Но я не понимаю, почему даже на нвме такие затупы. А в обратную сторону их нет вообще.

У процессора не больше 20% загрузки. Вся мать обдувается сейчас на максимальных оборотах.

С виндой таких просадок не было, поэтому сеть, я бы всё же исключил. Сетевушки воткнуты в слоты 4х. Но 550тая и так 4х.

Во вложении скрин параллеьной загрузки. Оба просаживаются. Оба на ~70 МБ. В сеть не упираюсь.

ССД воткнут в "родное" М2. Загрузки не помню куда, то ли в родные мамкины слоты то ли в ASM1064. Но, это не суть важно сейчас.

 

[mav@]

Вообще NVMe бывают разные. Многие используют SLC кеширование, которое увеличивает скорость записи на первые 1/8 свободной емкости, после чего она падает в разы и на долго. Принудительный `zpool trim ...` время от времени по идее может улучшить ситуацию.

Загрузка процессора в 20% -- это нормально, но надо так-же смотреть в первую очередь что ни одно из ядер и что важнее ни один из тредов/процессов не занят близко к 100% иначе при однопоточных нагрузках возможны локальные затыки (то что процессор имеет 12 тредов не значит что все могут быть использованы одновременно на конкретной нагрузке).

В любом случае нужно смотреть на статистику дисков во время записи, заняты ли они близко к 100%. При записи должны быть большую часть времени если узкое место в них, а если нет, то проблема где-то в другом месте.

 

[Voy50]

Да при чем тут диски, если я хочу писать в озу 40-70 Гб. Ради этого всё и затевалось, что бы скинуть на озу за пару минут, выключить рабочий пк и лечь спать, а дальше внутри НАСа оно само хоть до утра пускай. и даже если свет выключат, на рабочем пк проект сутки может спокойно полежать на всякий случай. И полное фиаско.

Модель: Toshiba XG4 (THNSN5256GPUK)
Форм-фактор: M.2 (2280)
Интерфейс: PCIe 3.0 x4
Протокол: NVMe
Ёмкость: 256GB
Память: TLC
Шифрование: нет (Non-SED model)
Скорость (линейная): 1500 / 760 MB/s
Скорость (произвольная): не указано

Да, диск не топовый, я его из старого делла достал, когда случайно винду на нем грохнул, 760 мБ не 10Г, конечно, но и не 70 мБ. Диск живой, я его проверял.

Тестовые файлы 9 гБ. Никакого переполнения тцл не случается. На запись не знаю как смотреть, репорт показываетцифры диска, которые я вижу при копировании из винды.
хдд

writes

108.29 MiB

2.5 MiB

0

нвме

writes

212.23 MiB

1.35 MiB

0

Я, похоже, реально после 4 гб и проседаю. 3 гб на полной скидываю, а если 6 пытаюсь, в районе 4-х как раз провал и начинается.

 

[mav@]

Да при чем тут диски, если я хочу писать в озу 40-70 Гб.

Я на это в самом начале ответил. Читай `man 4 zfs` на предмет zfs_dirty_data_max_max, zfs_txg_timeout и вокруг.

 

[Voy50]

Да я это нагуглил сразу же:

Code:

    zfs_dirty_data_max_percent (10%) - при достижении доли грязных данных (в процентах от zfs_dirty_data_max) ждём завершения синхронизации транзакции
    zfs_dirty_data_max (10% от ОП, но не более zfs_dirty_data_max_max) - при достижении количества грязных данных (в байтах) ждём завершения синхронизации транзакции
    zfs_dirty_data_sync_percent (20%) - при достижении доли грязных данных (в процентах от zfs_dirty_data_max) начинаем синхронизацию транзакции
    удалён: zfs_dirty_data_sync (67108864) - синхронизовать транзакцию при накоплении указанного количества грязных данных
    zfs_delay_min_dirty_percent (60%) - при достижении доли грязных данных (в процентах от zfs_dirty_data_max) задержать транзакцию (см. zfs_vdev_async_write_active_max_dirty_percent)
    zfs_dirty_data_max_max_percent (25%) - ограничение для zfs_dirty_data_max_percent в процентах от ОП, неизменяемый
    zfs_dirty_data_max_max (25% от ОП) - ограничение для zfs_dirty_data_max, неизменяемый; кто-то вписывает сюда 4GB
    zfs_delay_scale (500000) - масштабный множитель для задержки транзакции (см. документацию; обратное к IOPS в наносекундах; если много задержек (vdev захлёбывается), то надо увеличить zfs_delay_scale или уменьшить zfs_delay_min_dirty_percent)
    zfs_per_txg_dirty_frees_percent (5) - предел освобождаемых косвенных блоков (в процентах от грязного), при превышении которого дальнейшее освобождение откладывается до следующей транзакции; 0 - без предела

Просто очень удивляет что такое древнее коробочное решение на столько кривое. Как минимум в моей практике:
кеш диски отваливаются после перезагрузки - любые. Свои дрова поставить нельзя.
невозможно разбить ЁМУ группы, т.к. патч не встроен, а самому его, как я понял, не поставить.
Теперь ешё выяснилось, что свою основную функцию трунас выполняет коряво, т.к. во первых не настроен максимальный объем АРКа(и конечно же в этом виноват линукс, а не коробочная версия готового продукта). И мне приходится узнавать что такое консоль, что бы поменять размер этого кеша, так и ещё небольшую кучку параметров, зависимых друг от друга, вместо того, что бы при первичной установке меня об этом спросили и дали подвигать ползунки.

Ещё не понятно как прокинуть 1 ХДД. В проксмоксе можно, а тут походу нельзя. Хотел в винду 1 корзину кинуть.

Я понимаю, что решение бесплатное, но, как минимум я, со своими вполне обычными хотелками споткнулся вообще везде. Ну да ладно, если никуда не перееду, напишу тут гайд и выложу замеры того, что получилось в итоге.

 

[mav@]

кеш диски отваливаются после перезагрузки - любые.

Не знаю о чем речь. У нас не отваливаются. Баг-репорт со всей информацией, пожалуйста. Видимо что-то делаете не так как все.

Свои дрова поставить нельзя.

Как раз потому-что коробочное решение. Мы не можем поддерживать все что есть в мире. Если чего важного не хватает -- баг-репорт, пожалуйста.

невозможно разбить ЁМУ группы, т.к. патч не встроен, а самому его, как я понял, не поставить.

Понятия не имею о чем речь. Можно баг-репорт с адекватной информацией?

Теперь ешё выяснилось, что свою основную функцию трунас выполняет коряво, т.к. во первых не настроен максимальный объем АРКа(и конечно же в этом виноват линукс, а не коробочная версия готового продукта). И мне приходится узнавать что такое консоль, что бы поменять размер этого кеша, так и ещё небольшую кучку параметров, зависимых друг от друга, вместо того, что бы при первичной установке меня об этом спросили и дали подвигать ползунки.

Мы считаем что большинство пользователей от обилия ползунков или впадет в ступор или накрутит такого, что потом начнутся вопросы про 40-70МБ/с (я не настаиваю на аналогии, но не исключаю). Оганичение в 50% на размер ARC было в ZFS-on-Linux было с самого начала и по реальным причинам. В TrueNAS Core на базе FreeBSD его нет. И мы работаем над его снятием в Linuх, но не ценой экспериментов на ничего не подозревающих пользователях. У меня лично 171 коммит в OpenZFS только на github, а у вас?

Ещё не понятно как прокинуть 1 ХДД. В проксмоксе можно, а тут походу нельзя. Хотел в винду 1 корзину кинуть.

Работа с raw дисками -- не наш приоритет. У нас все построено вокруг ZFS.

Я понимаю, что решение бесплатное, но, как минимум я, со своими вполне обычными хотелками споткнулся вообще везде. Ну да ладно, если никуда не перееду, напишу тут гайд и выложу замеры того, что получилось в итоге.

И OpenZFS и TrueNAS полностью в open-source на github. Патчи и баг-репорты всегда приветствуются и рассматриваются.

 

[Voy50]

Я в первую очередь пользователь, не админ, не программист и т.д. Я хочу что бы из коробки всё работало. Это логично. Поэтому мои посты содержат некую эмоциональную часть, когда такого не происходит.

Понятия не имею о чем речь. Можно баг-репорт с адекватной информацией?

Issues with IOMMU groups for VM passtrough.

Hello, this is my first time using TrueNAS. I'm currently using the version TrueNAS-SCALE-21.08-BETA.2 (latest version at the moment.) kernel 5.10.42+truenas My setup consists of a MSI mag B550m mortar wifi with a r7 3700x. The motherboard has 1 PCIx16 (gen4/gen3) configured as x4x4x4x4 with...

www.truenas.com

 

[mav@]

Спасибо. Ответил в том посте.

 

[Voy50]

Понятных мне гайдов по своей проблеме(настройка грязных данных) я не нашел. Попробовал вот так:

Code:

system advanced update kernel_extra_options="zfs_arc_max=107374182400, zfs_dirty_data_max=53687091200, zfs_dirty_data_max_max=53687091200"

Без запятых, просто пробелами то же попробовал.

Не пашет. И размер арка не увеличивается. И на запись ничего не получилось, после 4-х ГБ всё схлопывается до 70 мБ/сек.

Потом я полез в /sys/module/zfs/parameters/ и увидел там у zfs_dirty_data_max 4 ГБ. По методу Lawrence Systems я загнал все цифры выше в пост инит

Code:

echo 107374182400 >> /sys/module/zfs/parameters/zfs_arc_max
echo 53687091200>> /sys/module/zfs/parameters/zfs_dirty_data_max
echo 53687091200>> /sys/module/zfs/parameters/zfs_dirty_data_max_max

Можно с уверенностью сказать, что размер грязных данных вырос. Я попробовал кинуть 18 ГБ. Я ожидал, что он весь зайдет в ОЗУ, а из неё будет уже в своем темпе писаться на диск. Что я увидел, запись идет на приемом уровне где-то до половины. Потом резко встает на 0 и не двигается. Далее кусками дописывает файлы. Т.е. судя по всему софт не пускает больше 10-12 гБ в ОЗУ. Но её же пустой 100 ГБ доступно, я же этот параметр передал.

Это не сеть отваливается, сеть функционирует полностью стабильно. Не единого разрыва.

Продолжение следует.

 

[Voy50]

Финалим:
В моём случае:

Когда в пуле 1 диск, не важно ХДД или НВМЕ - запись работает коряво. Проседает. Почему -даже разбираться не буду пытаться.

С пулом 3 хдд cmr тошибы тп300 3 тб. Всё работает нормально. Заслал 70 ГБ, просадки начались как раз после 50-ти ГБ.

Не то что бы solved, т.к. я должен помнить сколько отвел под кеш, когда балуюсь с ВМ. И плохие показатели на одиночных дисках. Но учитывая, что у меня только ПФсенс на 2 ГБ ОЗУ и пара сервисов, я думаю, что меня на текущий момент это устроит.