Свежие комментарии
| Title | Comment |
|---|---|
| Никаких исходников, всё |
Никаких исходников, всё предельно просто. Просто моё понимание/опыт на данный момент как выжать максимум из дисков. Почта нужна что бы послать один файл (если захочешь попробовать). |
| Гайки без комментариев смысла |
Гайки без комментариев смысла не имеют. Гайкам с комментариями буду очень рад, потому что читать исходники я вот точно не буду, а документации на новомодные гайки практически нету (Evil tuning guide, но оно не безумно новое) |
| Действительно веселее :-). |
Действительно веселее :-). Значит распределение контрольных блоков зависит от разных причин. Для raidz2 больший recordsize явно предпочтительней. Я бы ещё потестировал 512kB на 6 дисковой конфигурации, это избавит стек ввода-вывода от дополнительной разборки/cборки запросов (все запросы к данным =MAXPHYS), хотя выгода наверно мизерная, но зато немного снизится латентность. |
| Сделал датасет с recordsize |
Сделал датасет с recordsize=128k. Там оно выглядит не столь позорно: device r/s w/s kr/s kw/s ms/r ms/w ms/o ms/t qlen %b Хотя общий результат по скорости чтения примерно тот же (но с учетом того, что это на живом сервере и там в фоне какая-то нагрузка, в устойчивовти этих данных есть сомнения и надо будет на пустом датасете тренироваться). При этом, 7-й диск добавляет изрядно: http://blog.lexa.ru/2016/12/06/freebsd_zfs_read_speed_oni_ubili_kenni.html И я его таки буду ставить, потому что данные все едино двигать придется. |
| Дык, по другому и не делают... |
...тестовый стенд называется! Кстати, у Вас реальной инфы - море! --> создайте 96GB файл = архив реальных данных Опять же, если "однопоточное чтение" = 4 файла по ~100МБ, то и тестовая нагрузка должна соответствовать этому; а не 1005000 Гиговый файл гонять. Нет? |
| Тогда вполне нормально. |
Тогда вполне нормально. |
| raidz1 - recordsize и ashift |
raidz1 - recordsize и ashift такие же (1m/12) |
| Там не 200. Там 185/120 |
Там не 200. Там 185/120 (начало, хвост) у быстрых и 162/113 у более медленных. Это dd if=/dev/ada.. of=/dev/null bs=1m skip=0m/5m Пул заполнен на 44%, куда лег тестовый файл - хрен пойми (ну то есть zdb пойми, но я не буду в его выдаче разбираться) |
| Или может быть на системе |
Или может быть на системе (где raidz1) минимальный размер записымаемого блока меньше, даже не знаю. |
| Там в комментарии к |
Там в комментарии к исходникам, вроде было что-то - про только для ординарной чётности. |
| Ты хочешь сказать, что сейчас |
Ты хочешь сказать, что сейчас raidz2 на 6 дисках превратился в полный аналог raid4 с двумя дисками чётности? Хотя, если сейчас никто не дробит блоки и все записываемые блоки идеально деляться на 4 и минимальный размер записываемого блока 4х4=16kB, то всё наверно может быть :-). Но как по мне, если это так, то это тоже не нормально. Ещё вопрос, если это диски со скоростью 200MB/s, то кто съел 50MB/s? Хотя может быть это пролёт над метаданными или чтение ближе к концу дисков. Если гипотеза о raid4 подтвердится, то получается, что на многопоточной нагрузке 7 дисков в raidz2 явно будут смотреться лучше (там всё должно размазаться, но проверить желательно). Да, чем больше я "приобщаюсь" к raidz2 тем больше вопросов возникает. Получается эффективность при последовательном чтении чуть больше 50% (610/1180). |
| Да, при этом 5-дисковый |
Да, при этом 5-дисковый raidz1 ведет себя нормально, там чтение по всем 5 дискам размазано. |
| Ну вот "раньше" ("плохие |
Ну вот "раньше" ("плохие файлы") загрузка постепенно вращалась между дисками. То есть ada1/ada6 (в данном примере) не были всегда нулевыми. Сейчас же - там строго нули. Меня это раздражает и так как все едино данные опять двигать, я думаю туда 7-й диск докупить, благо на новой материнке 8 портов, а не 6. |
| Похоже раньше кто-то дробил |
Похоже раньше кто-то дробил блоки. Мысли есть, но я думаю там быстро разберутся. |
| Ну вот чтение "хорошего" |
Ну вот чтение "хорошего" файла выглядит так (это 5сек-усреднение): device r/s w/s kr/s kw/s ms/r ms/w ms/o ms/t qlen %b Плохой файл не сохранился. |
| Впрочем, я понял как ты |
Впрочем, я понял как ты считаешь. Просто понятие скорости (то есть "количества работы за единицу времени") - оно сложное. Чтобы два раза не вставать, "90%" в твоем способе подсчета - это в 10 раз (быстрее). |
| avx2 же еще. |
avx2 же еще. На одинаковой частоте (и если не упирается в память) - в два раза (относительно, соответственно, sse4). Ну а 1.5 раза - вот они на картинке выше. |
| Ну вот data move дойдет до - |
Ну вот data move дойдет до - и тогда. |
| Не интересно там, где было |
Не интересно там, где было raidz2 из 6 и ~32kB. Если будет оказия - черкани. |
| Гоню. ~128 - это на запись. |
Гоню. ~128 - это на запись (5 дисков в raidz1, ashift=12) |
| Ну вот сейчас в бою (tar cvf; |
Ну вот сейчас в бою (tar cvf; tar xvf) - в районе 120-128к |
| Я насчитал чуть более 30% |
Я насчитал чуть более 30% (точнее около 32%). Недавно сравнивал i7 второго и шестого поколения одинаковой частоты, вышло так же. Так что нет там 1.5 раза. |
| Может заметил - какой средний |
Может заметил - какой средний размер запроса был при чтении "быстрого" файла? |
| Мне чтобы проводить |
Мне чтобы проводить эксперименты на пустом пуле - надо разобрать ящик, сунуть туда другой контроллер и другие диски и пока оно так работает - ящик невозможно использовать (а вообще у меня там активный а не архивный сторадж). То есть вот если там есть лаба с 12-ю дисками у кого-то, то вот им и карты в руки. Как отрепортят что починили - ну да, один раз проверю. |
| Ну ничего в голову не |
Ну ничего в голову не приходит другого. zdb наверное умеет такое показать, но я не умею его читать. |
| Интересная развязка :-). |
Интересная развязка :-). Получается аллокатор выделял место под записываемые блоки на дисках не последовательно? |
| freebsd-fs |
Ну, вот, пошла движуши, вот и Стив подтянулся, так что я своё ставлю on hold (но если что -- готов какие-нибудь эксперименты попроводить, если ты short of resources) |
| Похоже что стандартный. |
Похоже что стандартный. Значит и чувствительности вполне железные. Только с исо 100 не совсем понятно, то, что передержка, это понятно, но по остальным параметрам нет, и размер файлов отличается почти на полтора мегабайта в плюс у исо 100 |
| Ну надо смотреть на камеру. |
Ну надо смотреть на камеру. Но -0.7 - это не стандартный ли сдвиг точки серого (а -1.7 - соответственно, нестандартный)? |
| testbed is weak |
то что есть под рукой довольно слабенькое, главное, памяти всего 4G, но, надеюсь, на тесты сгодится. попросил коллег ткнуть дисочков, пошол строить. |
Pages
