Свежие комментарии

С точки зрения системы это наверно не очень хорошее решение, но мне тоже интересно :-).

У меня других мыслей нет. Разве, что я отстал от жизни :-).

defaults

И, удивительным образом, не нашел как этот параметр посмотреть у собранного. Ищу вот...

На счёт скорости дисков. Вполне нормально, если скорости будут отличаться. Просто при жесткой увязке (как у raidz) быстрые диски будут привязаны к скорости более медленных и будут потери производительности. Но моя мысль была связана с полосатостью патерна чтения. Допустим нужно прочитать блок данных (recordsize), как в твоём последнем случае. Будет сформирован запрос на чтение (zio) 1MB, затем опускаясь по стеку будут сформированы три дочерних запроса (zio) по ~340kB и так далее. К моменту прихода запроса на физический диск может сложиться такая ситуация, что допустим один диск может прочитать сектора сразу, а два других должны будут пролететь перед чтением контрольные блоки. То есть один диск будет опережать два других. Возникла мысль, а может ли возникнуть в процессе чтения ситуация, что один диск прочитал всю свою порцию чтения из окна префетчинга, а один ещё только читает свою первую часть порцию. Тогда наверно возможна ситуация, что следующий запрос на чтение придет на, выполнивший свою работу, диск когда тот уже пролетит над этими данными и ему потребуется сделать лишний оборот. Это конечно предположение и возможно диск всегда читает дорожку и складывает данные в свой кэш. Поэтому я написал, что разница скоростей могла бы немного "посодействовать" подобной ситуации. Кстати, у зеркала при чтении нет такого влияния разницы скоростей дисков, потому что алгоритм балансировки построен на загрузке дисков и также нет жёстких связей (весь блок (recordsize) читается только с одного диска). Поэтому при чтении может быть выбрана почти вся пропускная способность. Мало того, в zfs предусмотрена возможность работы в зеркале ssd и hdd одновременно. Специально подстроен алгоритм балансировки. Для этого даже сделали автоматическое определение типа диска (non_rotating), пока правда только во FreeBSD.

Размер запроса на диск. При входе в подсистему geom, в твоём случае запрос (zio) ~340kB, Будут сформированы три дочерних запроса (bio) - 128kB, 128kB и ~84kB. Почему средний размер запроса ~170kB ума не приложу :-). Хотя он конечно коррелирует с ~340kB.

Так как я опасаюсь адаптека (там при смене дисков надо их "инициализировать" и хрен знает что оно при этом затирает) - я заказал еще один 9211, благо копейки стоит, придет (через дней 10, я надеюсь) - и буду развлекаться.

>> получали в два раза больше запросов

И вот эта загрузка она в моменте (без префетча) у двух дисков из 6 вообще 0. Но незагруженные диски - меняются.

Длинный префетч это размазывает, естественно.

Думаю, что можно и это самый лучший вариант. Я бы без чёткого понимания ситуации даже бы и не дёргался. Единственное на чём бы я заострил внимание - это разница в скорости дисков. Не уверен, но она тоже могла бы немного "посодействовать". Из твоего iostat однозначно видно, что два диска из шести получали в два раза больше запросов, то есть данные так уже лежали на дисках. Наверно это самое важное. Меня тогда же ещё смутил средний размер запроса чтения с диска (в районе 32k). Вроде из твоих описаний про 1M recordsize на диски должны приходить в основном запросы в 128k. Откуда взялись эти средние ~32k?

Ну вот и доказали, что с аппаратной частью у тебя всё хорошо. У меня ещё такой пропускной способности в руках не было, но думаю можно попробовать настроить последовательное чтение до 1GB/s (какая символическая цифра :-)). Если всё таки надумаешь перезаливать данные, то предлагаю потратить дополнительные 30 мин для проверки данного допущения (и количество дисков подходящее и скорости дисков распределились как надо :-)).
По существу. Так как я не эксплуатирую raidz, то могу только сделать предположение. Похоже ты попал с данной конфигурацией raidz в "устойчиво не хорошее сочетание разных факторов". Предполагаю самое простое решение убрать один диск из конфигурации raidz или добавить. Для проверки можно воспользоваться и составным диском.

He8 - на 4-6 градусов холоднее при одинаковом охлаждении, у меня (летом) это место близко к критичному бывает.

По iostat -x/gstat у всех дисков 99% и ожидаемая скорость: ~215 у обычных, 200 (из того что ниже - получается 190) у He8
Вот результаты двух прогонов:
fiolog: read : io=121780MB, bw=1214.4MB/s, iops=1214, runt=100310msec
fiolog2: read : io=121780MB, bw=1214.3MB/s, iops=1214, runt=100294msec

А вот без group reporting:
fiolog3: read : io=21694MB, bw=221511KB/s, iops=216, runt=100287msec
fiolog3: read : io=21694MB, bw=221925KB/s, iops=216, runt=100100msec
fiolog3: read : io=18814MB, bw=192605KB/s, iops=188, runt=100026msec
fiolog3: read : io=18878MB, bw=193108KB/s, iops=188, runt=100105msec
fiolog3: read : io=18942MB, bw=193363KB/s, iops=188, runt=100312msec
fiolog3: read : io=21758MB, bw=222502KB/s, iops=217, runt=100135msec

Я их dd почитал по одному. ~210Mb/s обычные, 185 - гелиевые, гелиевые чуть помедленнее - но это и ожидалось.

Префетченое оно положит в память, естественно.

По идее, в L2arc должно идти most frequently used (а MRU - нет).

Да-да, очень похоже.

Не помню в какой версии Солярки таймаут ответа при отсылке почты стоял "0". Поэтому письма ГЕОГРАФИЧЕСКИ ближе 400км доходили, дальше - отлуп по таймауту.
:-)