The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"OpenNews: Продолжение истории про быстродействие FS"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [Проследить за развитием треда]

"OpenNews: Продолжение истории про быстродействие FS"  
Сообщение от opennews on 13-Июн-04, 14:20 
На этот раз - о быстродействии UFS2 на программном RAID (ccd). Измерения проводились для UFS2 и EXT2 на обычных разделах и UFS2 на программном RAID0. Результат - производительность раздела на RAID0 (логическое объединение IDE дисков) значительно выше, но это не заслуга UFS.

URL: http://unix.ginras.ru/freenotes/test/ufs-and-ccd.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=3981

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]


1. "Продолжение истории про быстродействие FS"  
Сообщение от Илья Шипицин email on 13-Июн-04, 14:20 
пробовали тестировать UFS2 + async - softupdates ?
шустрая как электровеник
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

2. "Продолжение истории про быстродействие FS"  
Сообщение от Алексей Федорчук on 13-Июн-04, 16:58 
Чего нет - того нет. Спасибо, попробую. А не страшно?
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

3. "Продолжение истории про быстродействие FS"  
Сообщение от Гость on 13-Июн-04, 19:39 
Не шустрее. В обсуждении прошлой истории уже протестили.
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

14. "Продолжение истории про быстродействие FS"  
Сообщение от Илья Шипицин email on 15-Июн-04, 14:18 
в обсуждении прошлой истории тестили async + softupdates
а я предлагаю                        async - softupdates

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

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

4. "Продолжение истории про быстродействие FS"  
Сообщение от Дмитрий Ю. Карпов email on 13-Июн-04, 21:24 
При работе с диском обычно время задержки (позиционирование головки плюс время ожидания прихода нужного сектора под головку) важнее, чем скорость трансфера (чтения или записи).

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

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

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

5. "Продолжение истории про быстродействие FS"  
Сообщение от Ivan Voytas email on 14-Июн-04, 11:37 
А можно поподробнее про "две трети оборота в случае RAID-0"? Что-то мои доморощенные знания теории вероятности такого вывода не позволяют сделать.
И уж тем более здравый рассудок не позволяет принять того, что "ускорения ждать не приходится". Зависит исключительно от размера и типа кэша. RAID-5 например при чтении работает как RAID-0 на N-1 дисках.
И откуда цифра в 200Кб? Размер блоков разный бывает.
Что-то где-то кто-то там, одним словом.
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

6. "Продолжение истории про быстродействие FS"  
Сообщение от Дмитрий Ю. Карпов www.prof.pi2.ru email on 14-Июн-04, 12:05 
> А можно поподробнее про "две трети оборота в случае 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-диска при работе с перефирийными треками примерно в два раза меньше скорости интерфейса; умножаем это на время полуоборота...

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

7. "Продолжение истории про быстродействие FS"  
Сообщение от edo on 14-Июн-04, 12:27 
>> А можно поподробнее про "две трети оборота в случае 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 показывает обычно очень хорошие результаты на чтение (и на запись), но к сожалению слишком зависит от реализации

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

13. "Продолжение истории про быстродействие FS"  
Сообщение от Дмитрий Ю. Карпов www.prof.pi2.ru email on 15-Июн-04, 14:04 
edo:
> 1. запрос может уложиться в один блок (т.е. чтение производится только с одного диска)

Правильно. Я же говорил, что это - тема часа на два, а то и более. Тут мы сталкиваемся с вопросом о быьоре "блока черелования": если чётные секторы логического диска находятся на одном физическом, а чётные на другом (RAID-0 из двух дисков), то при запросе более одного сектора задержка сразу вырастает с полуоборота до двух/третей.

Предлагаю специалистам (тем, кто считает себя таковыми) решить задачу о выборе оптимального размера "блока черелования".

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

> 1a. куча мелких запросов достаточно равномерно распредляется между дисками и мы видим фактически уменьшение времени доступа по сравнению с однодисковой системой

Да - для этого RAID-контроллер должен работать в SCSI-стиле: принимать пачку запросов и распределять их самомтоятельно. И иметь на себе нехилый объём собственной памяти (десятки мегабайт).

Плюс к тому, следует различать операции чтения (которые в принципе можно полностью буферизовать при большом объёме RAM) и операции записи (которые придётся делать на случая сбоя питания).
Те, кто знакомы с понятием "транзакция", знают, что диск (дисковая система) не имеет права менять очер`дность выполнения операций записи, выполняющихся в ходе одной транзакции; так что свобода маневра у RAID-контроллера сильно ограничена.

> 2. блок может быть достаточно большим (то есть за время, пока с первого диска читается блок второй диск ищет следущий - начальное состояние второго диска уже не имеет значения)

Это я рассмотрел выше.

> 3. есть raid1. при правильной организации надо брать
{интеграл от 0 до 1} ( {интеграл от 0 до 1} ( min(X,Y) dX dY ) )

Это если контроллер умеет посылать запрос сразу к двум дискам и выбирать отает от того, кто ответил первым. Такое умение отражено в документации?


Дмитрий:
> Ну и у задержки есть предел ;-) !

Да - при увеличении количества дисков задержка стремится к полному обороту диска.

> И на сколько нам интересна первоначальная задержка?

Обрати внимание, что продавцы указывают именно скрорость вращения (главный параметр, определяющий задержку), а не скорость чтения/записи! Да ради снижения задержки производители перешли от пятидюймовых дисков к трёхдюймовым, потеряв в два с лишним раза площадь поверхности (и, соответвтсенно, ёмкости)!!! Ну так что же важнее, а?

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

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

> RAID лишь немногим хуже одинночного диска по затратам времени на каждое позиционнирование.

При двух дисках - в 1.33 раза. Это немного?


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

Не далее как вчера я спорил со студентом МФТИ. Я говорил, как OS (любая) должна работать с виртуальной памятью по моемУ мнению; а он говорил, что программирует под Linux, и там всё не так. Он позвонил другому преподу, потом полез в листинги компиляции - и выяснилось, что я такИ прав. И действительно - не могли же авторы Linux не додуматься до тех вещей, которые мне очевидны!

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

15. "Продолжение истории про быстродействие FS"  
Сообщение от Dmitry email(??) on 15-Июн-04, 15:07 
>
>> И на сколько нам интересна первоначальная задержка?
>
>Обрати внимание, что продавцы указывают именно скрорость вращения (главный параметр, определяющий задержку),
>а не скорость чтения/записи! Да ради снижения задержки производители перешли от
>пятидюймовых дисков к трёхдюймовым, потеряв в два с лишним раза площадь
>поверхности (и, соответвтсенно, ёмкости)!!! Ну так что же важнее, а?
>
Это не то, разговор шел именно о важности начала чтения, и если бы это только одно разовое чтение, я бы согласился.

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

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

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

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

9. "Продолжение истории про быстродействие FS"  
Сообщение от Дмитрий email(??) on 15-Июн-04, 00:53 
>> RAID-5 например при чтении работает как RAID-0 на N-1 дисках.
>
>И чем больше дисков, тем больше начальная задержка.
>
Ну и у задержки есть предел ;-) !
И на сколько нам интересна первоначальная задержка? Если только нам делать  больще нечего, то пожалуй. Если ввести асинхронность в процесс обмена с дисками, и считаем задачу выполненной после значительного количества найденных и прочитанных блоков самым невезучим диском, то некоторое увеличение начальной задержки не имеет значения. RAID лишь немногим хуже одинночного диска по затратам времени на каждое позиционнирование.

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

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

10. "Продолжение истории про быстродействие FS"  
Сообщение от toor99 email(ok) on 15-Июн-04, 01:52 
>А можно поподробнее про "две трети оборота в случае RAID-0"? Что-то мои
>доморощенные знания теории вероятности такого вывода не позволяют сделать.
>И уж тем более здравый рассудок не позволяет принять того, что "ускорения
>ждать не приходится". Зависит исключительно от размера и типа кэша. RAID-5
>например при чтении работает как RAID-0 на N-1 дисках.
>И откуда цифра в 200Кб? Размер блоков разный бывает.
>Что-то где-то кто-то там, одним словом.

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


Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

8. "OpenNews: Продолжение истории про быстродействие FS"  
Сообщение от poige (??) on 14-Июн-04, 13:17 
Если этот тот же Федорчук, что и автор

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

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

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

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

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

..."

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

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

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

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

11. "Продолжение истории про быстродействие FS"  
Сообщение от CGen email on 15-Июн-04, 02:33 
Так выходит дело не в USF, а в работе FreeBSD с дисками?
Моё чисто субъективное мнение: 5 CURRENT работает заметно медленнее, чем 4.10.
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

12. "Продолжение истории про быстродействие FS"  
Сообщение от c0x on 15-Июн-04, 08:13 
>Так выходит дело не в USF, а в работе FreeBSD с дисками?
>
>Моё чисто субъективное мнение: 5 CURRENT работает заметно медленнее, чем 4.10.

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

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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