Свежие комментарии
| Title | Comment |
|---|---|
| Вот меня (с моим паттерном - |
Вот меня (с моим паттерном - важен один поток) порадовало кстати то, что raidz в один поток читает быстрее. Довольно неожиданный результат, я ожидал что zfs зеркало умеет правильно нагрузить и для одного потока. (может быть префетч выключен и включение - изменит это?) |
| Проверялось соответствие |
Проверялось соответствие формулы 2V против 3V. Из кеша проверять нету смысла :). Можно задать с помощью fio любую нагрузку, но вопрос какую? И как потом оценить? |
| Да-да, в зеркале будут не |
Да-да, в зеркале будут не full-stroke, а половинки. В 3-way-зеркале - трети, вопросов нет. Вопрос в том, какой реальный паттерн реальной нагрузки. Вот к примеру на сервере где blog.lexa.ru - чтений 1% (потому что памяти больше чем надо - и все вообще что читалось - лежит в кэше). |
| Я ошибся не 1GB, а 1TB. |
Я ошибся не 1GB, а 1TB. Получается 8GB - 1TB - 8GB - 1TB - 8GB - 1TB - 8GB. |
| Такие длинные треды бывают |
Такие длинные треды бывают редко - и я ленюсь (ну и сам читаю через RSS). Когда-нибудь - починю. Но ведь лень! |
| formatting |
Ох йо, как жэ ж оно косо форматирует при большой глубине вложенности-то! И подветку отдельно не поглядеть, в отличие от LJ :( Лёх, с этим ничего нельзя сделать? |
| С рассуждениями почти |
С рассуждениями почти полностью согласен. Но в данном примере на 4 потока в raidz каждая головка диска обязательно будет летать в четыре разные позиции (в какой последовательности неясно, но минимум на 1/4 часть диска, предположим в среднем 1/2, если в среднем сильно больше, тогда совсем беда). В случае зеркал в лучшем случае одна головка будет делать перемещение только на 1/4, что впрочем тоже ещё нужно доказать. Получается на вскидку имеем двукратное превосходство. Хотя чутьё мне подсказывает :) (https://github.com/geomflash/geomflash/blob/master/Performance%20raid1%2...), что будет "разница будет возрастать". |
| Я не думаю что "возрастать". |
Я не думаю что "возрастать". Зеркало и два потока: каждый поток спозиционируется на своей области дисков, seek-ов лишних почти нет, счастье. Но оптимизация определяется именно количеством копий. Будет 10 копий (и много потоков) - ну на 10 зон побъем диски. |
| При увеличении потоков чтения |
При увеличении потоков чтения - разница будет возрастать. |
| Ну да, два потока можно |
Ну да, два потока можно сбалансировать по двум зеркалам - и здорово, что такая оптимизация есть. |
| Во всех описываетых ранее |
Во всех описываетых ранее тестах размер recordsize был 128k. Дошли руки провести простенький тест из 4 дисков (WD Black 2T). Создавался raidz из 4 дисков и страйп из двух зеркал. Все настройки для файловых систем были одинаковы (немного оптимизированны, кеширование только для метаданных). Что бы не усложнять и обеспечить простую воспроизводимость, тест делался с помощью dd. Вначале записывался файл 64GB, затем 256GB, затем ещё один на 64GB. Соотношение скоростей записи 1,42, 1,4, 1,44. Очень близко к теоретическому 1,5 :). Затем последовательно читался первый и второй файл. Соотношение скоростей чтения 1,42, 1,37, что тоже довольно близко к 1,5. Последний тест - чтение первого и третьего файла одновременно. Соотношение суммарной скорости чтения 0,74, то есть страйп из двух зеркал быстрее raidz в 1,34 раза. Зная, что алгоритм балансировки чтения у встроенного в zfs зеркала, мягко говоря, оставляет желать лучшего. Повторил тест на страйпе из зеркал с лучшим алгоритмом балансировки. По записи тоже самое, по чтению 1,2, 1,2, 0,38. Получается при чтении в два потока raidz медленнее zfs на двух зеркалах в 2,6 раза. Для понимания порядка цифр - raidz в один поток чтения выдавал 343MB/s, в два потока суммарно 186MB/s. zfs на двух зеркалах - в один поток 285MB/s, в два потока суммарно 484 MB/s. |
| тут и не с переходником, гм, |
тут и не с переходником, гм, бывает. про старую сигму на цифросапогах думаю все знают - но бывает не только с сигмой и не только на сапогах, и причем не обязательно чтоб что-то из этого было старым. только брать и проверять конкретные комплекты :/ |
| 135/2 - одна из наиболее |
135/2 - одна из наиболее древних "актуальных" линз, понятно что все менялось за 20 лет то (хотя в актуальной линейке есть и более древние) Прикол в том, что похоже что в части "совместимости с переходником - на чужие тесты полагаться нельзя, похоже. |
| за 135/2 не скажу, а из более |
за 135/2 не скажу, а из более попсового доводилось разбирать 28-70/3.5-4.5 несколько штук - так вот там даже аппаратно разницы было оймама - какие-то на текстолитовых платах собраны, а какие-то целиком на флексах. |
| Разделение ответственности - |
Разделение ответственности - работает! |
| > Еще бы этот звук убрать - |
> Еще бы этот звук убрать - будет идеально. До того - пользоваться можно, но всякий раз вздрагиваю. Но вообще конечно все время удивляешься - это же было очевидно разработчикам адаптера в самой же Sigma... ну не мб же чтобы они это сами не видели или считали что это нормально. |
| C маленьким recordsize на |
C маленьким recordsize на raidzN с неподходящим количеством дисков - действительно будет большой оверхед (и как я понимаю, если взять ashift=12 и recordsize=4k, то из raidz2 мы эффективно получим 3-way mirror). Но размер записи стандартный - 128к а не 8. В том числе и по этой причине. |
| Проверил свои тесты, благо я |
Проверил свои тесты, благо я записал статистику в файл. Всё верно плюс/минус 1%. Я в начале считал всё тоже только по первому диску, перепроверил для всех дисков входящих в raidz. Для теста были созданы 6 разделов по 512GB. Из этих разделов создал raidz из 6 дисков. Создал файловую систему по умолчанию. С помощью dd записал файл в 64GB блоками по 128k. На все диски записалось 98,6GB. Если учесть, что должно было записаться в 1,2 раза больше (76,8GB), то получился оверхед 28%. Затем с помощью fio в этот файл записал случайным образом 256MB блоками по 128k. Записалось 402,9MB. С учётом коэффициента 1,2 получилось 31% оверхеда. Получачается при при модификации файла в таких условиях пенальти отсутствует (чтения не наблюдалось вообще). Также заметил, что после снятия статистики данные ещё некоторое врямя писались на диск из кеша. Поэтому результаты могут незначительно отличаться в большую сторону. Вспомнил, что когда-то раньше разбирался с низкой производительностью zvol на 3TB и тогда выяснил, что пишется где-то на 30% больше. Правда там recordsize по умолчанию по-моему был 8k. Поэтому сделал вывод, что на созданных по умолчанию файловых системах оверхед при записи приблизительно 30%. Повторил Ваш тест. Правда размер диска был 32GB. Всё подтвердилось - размер файла был 96%, от размера диска, а оверхед по записи 1,8%! Задумался. Подумал маленький размер диска по сравнению с объёмом памяти (на машине 16GB). |
| Фичи софта. |
Я понимаю, что уже не актуально. Тем не менее: |
| Другой вопрос, что еще 10% |
Другой вопрос, что еще 10% рекомендуют держать пустыми т.к. там есть песня про фрагментацию. |
| Ну проверить то - недолго. |
Ну проверить то - недолго. Беру виртуальную машину: $uname -a Подцепляю к ней в виртуальный же диск на 8 гигабайт, прямо на ходу da1: <VMware, VMware Virtual S 1.0> Fixed Direct Access SCSI-2 device Создаю zpool и смотрю что получилось zpool create ztest /dev/da1 zfs create ztest/ztest1 Пишу туда файл на весь размер: dd if=/dev/zero of=/ztest/ztest1/file bs=1024M ls -l /ztest/ztest1/file Значит влезло 8255045632 байт, а места было 16777216*512 = 8589934592 байт Делим, получаем 0.96101, то есть 4% оверхед. Как вы получили 30% - не понимаю!
|
| По дефолтным настройкам zfs |
По дефолтным настройкам zfs имеет оверхед по записи приблизительно +30% от записываемого объёма (вне зависимости от организации vdev). Если поиграться можно снизить до 4-5% (у меня больше не получалось, правда не использовал больших recodsize). Тоже немного поэксперементировал с raidz. Скорость оценить не могу, так как использовал разделы одного диска. Но по объёму записываемой информации получил похожие результаты. Пенальти не вылазит, даже при случайной модификации большого файла :). Возможно, если объём записанных данных будет сравним или превосходить размер пула (имеется ввиду с учётом модификаций и удалений), то начнёт что-то вылазить. |
| Я кажется видел этот |
Я кажется видел этот калькулятор им. delphix. То есть потери есть, с этим я не спорю, просто при recordsize в 256 секторов (1M по 4k сектор) округления до 3-4 (они там до 1+p, где p - избыточность) не будут заметны. |
| Т.е. рекордсайз делится на |
Т.е. рекордсайз делится на число дисков (минус чётность), и получившееся округляется вверх до делимости на минимальный рекордсайз, (т.е. эффективно 4K в нынешних условиях). |
| Но не до конца. Я сейчас не |
Но не до конца. Я сейчас не дома, а в понедельник поищу гуглдоковскую табличку калькулятор где вино когда сколько теряется. |
| То есть на больших record |
То есть на больших record size это должно эффективно прятаться. |
| Вот delphix: |
Вот delphix: A misunderstanding of this overhead, has caused some people to recommend using “(2^n)+p” disks, where p is the number of parity “disks” (i.e. 2 for RAIDZ-2), and n is an integer. These people would claim that for example, a 9-wide (2^3+1) RAIDZ1 is better than 8-wide or 10-wide. This is not generally true |
| Нет, не понимаю! |
Нет, не понимаю! |
| Я на всякий случай спрошу: ты |
Я на всякий случай спрошу: ты же понимаешь, что у RAIDZx должно быть 2^n + x дисков или ZFS радостно будет терять место, да? |
| Я ж написал. По одному диску, |
Я ж написал. По одному диску, но там по всем 6-ти за три дня аптайма цифры близкие. |
Pages
