The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Продолжение истории про быстродействие FS

12.06.2004 14:57

На этот раз - о быстродействии UFS2 на программном RAID (ccd). Измерения проводились для UFS2 и EXT2 на обычных разделах и UFS2 на программном RAID0. Результат - производительность раздела на RAID0 (логическое объединение IDE дисков) значительно выше, но это не заслуга UFS.

  1. Главная ссылка к новости (http://unix.ginras.ru/freenote...)
  2. OpenNews: Предыстория: Сравнение быстродействия файловых систем: FreeBSD vs Linux
Автор новости: Алексей Федорчук
Лицензия: CC-BY
Тип: яз. русский / К сведению
Короткая ссылка: https://opennet.ru/3981-ufs
Ключевые слова: ufs, fs, benchmark
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (15) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Илья Шипицин (?), 14:20, 13/06/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    пробовали тестировать UFS2 + async - softupdates ?
    шустрая как электровеник
     
  • 1.2, Алексей Федорчук (?), 16:58, 13/06/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Чего нет - того нет. Спасибо, попробую. А не страшно?
     
  • 1.3, Гость (?), 19:39, 13/06/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не шустрее. В обсуждении прошлой истории уже протестили.
     
     
  • 2.14, Илья Шипицин (?), 14:18, 15/06/2004 [^] [^^] [^^^] [ответить]  
  • +/
    в обсуждении прошлой истории тестили async + softupdates
    а я предлагаю                        async - softupdates

    на операциях с самбой быстрее в три раза (на тех операциях, которые требуют большого количества маленьких файлов)

     

  • 1.4, Дмитрий Ю. Карпов (?), 21:24, 13/06/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    При работе с диском обычно время задержки (позиционирование головки плюс время ожидания прихода нужного сектора под головку) важнее, чем скорость трансфера (чтения или записи).

    Время ожидания прихода нужного сектора под головку составляет в среднем:
    - половину оборота диска при одном диске;
    - две трети оборота диска при RAID-0 на двух дисках (нужно ждать того, кто откликнется позже).
    Позиционированием головки в этом слцчае мы можем пренебречь. Получается, что время ожидания играет решающую роль при работе блоками менее примерно двухсот килобайт (и по мере роста ёмкости дисков эта величина тоже растёт, хотя и медленнее). А обращения в системные области диска (в директории, в таблицы размещения файлов, в таблицы свободного места) не м.б. большими (правда, они кэшируются, но записвать их всё равно надо).

    Так что ускорения от RAID-0 массива ждать не приходится, не говоря уж о др.схемах.

     
     
  • 2.5, Ivan Voytas (?), 11:37, 14/06/2004 [^] [^^] [^^^] [ответить]  
  • +/
    А можно поподробнее про "две трети оборота в случае RAID-0"? Что-то мои доморощенные знания теории вероятности такого вывода не позволяют сделать.
    И уж тем более здравый рассудок не позволяет принять того, что "ускорения ждать не приходится". Зависит исключительно от размера и типа кэша. RAID-5 например при чтении работает как RAID-0 на N-1 дисках.
    И откуда цифра в 200Кб? Размер блоков разный бывает.
    Что-то где-то кто-то там, одним словом.
     
     
  • 3.6, Дмитрий Ю. Карпов www.prof.pi2.ru (?), 12:05, 14/06/2004 [^] [^^] [^^^] [ответить]  
  • +/
    > А можно поподробнее про "две трети оборота в случае RAID-0"?
    > Что-то мои доморощенные знания теории вероятности такого вывода не позволяют сделать.

    Запрос прихожит в случайное время. Оба диска находятся в случайном положении. Оба времени ожидания прихода сектора под головку (обозначим их X и Y) независимы и равномерно распределены в интервале {от 0 до 1}. Нам нужно максимальное. Берём двойной интергал:
    {интеграл от 0 до 1} ( {интеграл от 0 до 1} ( max(X,Y) dX dY ) )
    Дальше брать или не надо?

    > И уж тем более здравый рассудок не позволяет принять того, что "ускорения ждать не приходится".

    Реально бывает как ускорение, так и замедление. Это - тема двухчасовой лекции. Хочешь - организуй мне аудиторию и оплату, у меня есть что рассказать "городу и миру" (я уже преподаю в МФТИ, но хочу расширить свою преподапвательскую деятельность).

    > Зависит исключительно от размера и типа кэша.

    Какого кэша? Я в твоей машине с ходу назову тебе четыре кэша и штук пять процессоров.

    > RAID-5 например при чтении работает как RAID-0 на N-1 дисках.

    И чем больше дисков, тем больше начальная задержка.

    > И откуда цифра в 200Кб? Размер блоков разный бывает.

    Ну хорошо - 200 KB. Скорость IDE-диска при работе с перефирийными треками примерно в два раза меньше скорости интерфейса; умножаем это на время полуоборота...

     
     
  • 4.7, edo (?), 12:27, 14/06/2004 [^] [^^] [^^^] [ответить]  
  • +/
    >> А можно поподробнее про "две трети оборота в случае RAID-0"?
    >> Что-то мои доморощенные знания теории вероятности такого вывода не позволяют сделать.
    >
    >Запрос прихожит в случайное время. Оба диска находятся в случайном положении. Оба
    >времени ожидания прихода сектора под головку (обозначим их X и Y)
    >независимы и равномерно распределены в интервале {от 0 до 1}. Нам
    >нужно максимальное. Берём двойной интергал:
    >{интеграл от 0 до 1} ( {интеграл от 0 до 1} ( max(X,Y) dX dY ) )
    >Дальше брать или не надо?

    1. запрос может уложиться в один блок (то есть чтение производится только с одного диска)
    1a. куча мелких запросов достаточно равномерно распредляется между дисками и мы видим фактически уменьшение времени доступа по сравнению с однодисковой системой
    2. блок может быть достаточно большим (то есть за время, пока с первого диска читается блок второй диск ищет следущий - начальное состояние второго диска уже не имеет значения)
    3. есть raid1. при правильной организации надо брать
    {интеграл от 0 до 1} ( {интеграл от 0 до 1} ( min(X,Y) dX dY ) )

    в частности raid10 показывает обычно очень хорошие результаты на чтение (и на запись), но к сожалению слишком зависит от реализации

     
     
  • 5.13, Дмитрий Ю. Карпов www.prof.pi2.ru (?), 14:04, 15/06/2004 [^] [^^] [^^^] [ответить]  
  • +/
    edo Правильно Я же говорил, что это - тема часа на два, а то и более Тут мы с... большой текст свёрнут, показать
     
     
  • 6.15, Dmitry (??), 15:07, 15/06/2004 [^] [^^] [^^^] [ответить]  
  • +/
    >
    >> И на сколько нам интересна первоначальная задержка?
    >
    >Обрати внимание, что продавцы указывают именно скрорость вращения (главный параметр, определяющий задержку),
    >а не скорость чтения/записи! Да ради снижения задержки производители перешли от
    >пятидюймовых дисков к трёхдюймовым, потеряв в два с лишним раза площадь
    >поверхности (и, соответвтсенно, ёмкости)!!! Ну так что же важнее, а?
    >
    Это не то, разговор шел именно о важности начала чтения, и если бы это только одно разовое чтение, я бы согласился.

    >
    >Есть вещи, которые нельзя выполнять асинхронно - см.выше про "транзакции".
    >

    Транзакция или важность сохранения порядка записи на диск IMHO не причем.
    RAID не должен переписывать очереди, он должен баланисровать нагрузку и не давать запрос чтения на диск с самой длинной очередью заданий. Всего лишь - грубо так.

    Что касается параллельной отработки заданий дисками, делящих  шину на контроллер (клинический случай), то  это уже сделано. Для передачи данных им конечно придеться разобраться друг с другом, но готовить данные они смогут одновременно, веротяно что и между командой на запись и подтверждением выполнения записи шина остаеться свободной ( не уверен ).
    Поддерживает ли возможность параллельного работы конкретный контроллер и диски - придеться разбираться. Но скорее всего ДА !

     
  • 4.9, Дмитрий (??), 00:53, 15/06/2004 [^] [^^] [^^^] [ответить]  
  • +/
    >> RAID-5 например при чтении работает как RAID-0 на N-1 дисках.
    >
    >И чем больше дисков, тем больше начальная задержка.
    >
    Ну и у задержки есть предел ;-) !
    И на сколько нам интересна первоначальная задержка? Если только нам делать  больще нечего, то пожалуй. Если ввести асинхронность в процесс обмена с дисками, и считаем задачу выполненной после значительного количества найденных и прочитанных блоков самым невезучим диском, то некоторое увеличение начальной задержки не имеет значения. RAID лишь немногим хуже одинночного диска по затратам времени на каждое позиционнирование.

    Raid5 явно увеличит отношение кол-во_позиционирований/кол-во_данных для каждого диска. Если бы удалось ровномерно распределить файловые операции по дискам  без RAID, то это  было бы эффективней, чем теже дисковые операции с единым блочным устройством на основе обьеденных в RAID дисков. Осталось только найти некий новый способ балансировки нагрузки.
    А для RAID-а неплохо использовать  предварительное чтение, не скупиться на  буфера, вдруг все получиться не так печально..

     
  • 3.10, toor99 (ok), 01:52, 15/06/2004 [^] [^^] [^^^] [ответить]  
  • +/
    >А можно поподробнее про "две трети оборота в случае RAID-0"? Что-то мои
    >доморощенные знания теории вероятности такого вывода не позволяют сделать.
    >И уж тем более здравый рассудок не позволяет принять того, что "ускорения
    >ждать не приходится". Зависит исключительно от размера и типа кэша. RAID-5
    >например при чтении работает как RAID-0 на N-1 дисках.
    >И откуда цифра в 200Кб? Размер блоков разный бывает.
    >Что-то где-то кто-то там, одним словом.

    У теоретиков все так: если практика не сходитсч с теорией, то тем хуже для практики. Забей.


     

  • 1.8, poige (??), 13:17, 14/06/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Если этот тот же Федорчук, что и автор

    http://cs.mipt.ru/docs/comp/rus/os/unix/user_guide/fedorchuk/office/2/002xedi

    (http://www.yandex.ru/, искать Федорчук xedit)

    то увы, без скепсиса, к его творениям, мне относиться уже не удается:

    "...
    Этот редактор - прост, как грабли (или реклама в бозе почившей фирмы Сэлдом). Белый экран с тремя пунктами меню в верхней части (Quit, Save, Load). Ниже - рабочее поле с миниатюрными, совершенно непосильными для моего зрения буквами (рис. 3). Полная невозможность настроить чего бы то ни было - размер и гарнитуру шрифта, не говоря уже о шрифтоначертании или цвете фона.

    ...
    Открытие файла сделано далеко не блестяще - нужно набрать путь либо в командной строке, либо после еле заметной галочки вслед за пунктом меню Load.

    ..."

    Это про xedit. :-) Который умеет C-код "раскрашивать", и вообще,
    почти что маленький брат emacs'а.

    В общем, вот так вот. :-/

    /poige
    --
    http://www.i.morning.ru/~poige/

     
  • 1.11, CGen (?), 02:33, 15/06/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Так выходит дело не в USF, а в работе FreeBSD с дисками?
    Моё чисто субъективное мнение: 5 CURRENT работает заметно медленнее, чем 4.10.
     
     
  • 2.12, c0x (?), 08:13, 15/06/2004 [^] [^^] [^^^] [ответить]  
  • +/
    >Так выходит дело не в USF, а в работе FreeBSD с дисками?
    >
    >Моё чисто субъективное мнение: 5 CURRENT работает заметно медленнее, чем 4.10.

    Почитайте /usr/src/UPDATING

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру