|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Eugene Gavrilov 2:5020/400 04 Dec 2001 19:07:21
To : Aleksey Barabanov
Subject : Re: hdd is not so fast
--------------------------------------------------------------------------------
ru> <3C0571C7.1CC5C439@mtu-net.ru>
From: "Eugene Gavrilov" <fakemailbox@hypersoft.ru>
День добрый!
> См. выше.
>
> Вы не обижайтесь, но хочется процитировать Гордона : "Чего смотришь ?
> Включи голову !".
>
> NB: Просьба не обижаться относиться к фамильярному тыканью. Замечание
> "бред" не в контексте этой ремарки ;) Шутка ;)
Я не знаю, кто такой Гордон, но голова традиционно включена постоянно.
> Все дело не в контроллерах , шлейфах и эр-пэ-эмах. Все дело в
> _грануляции_ !
Ура, великое научное открытие! ;)
> быть. Падение скорости происходит принципиально. Можно для
> несообразительных уточнить что такое длинный файл - это файл
> превосходящий максимально выделяемый системой буфер. Грубо говоря,
такой
> файл должен превосходить объем ОЗУ.
Теперь пытаемся понять, а нахрена нам нужен именно такой файл. Hу
допустим у меня дома найдется 5 штук файлов больше гигабайта (объем
ОЗУ) - когда-то сграбленный и не отконверченный до сих пор в mpeg4 фильм
с dvd. Hо на кой хрен мне его куда-то копировать - ума не приложу.
> Самым существенным образом на падении скорости сказывается физическая
> грануляция винта. Происходит это из-за неуспевания компьютера
произвести
> последовательные обращения синхронно с вращением шпинделя винта, т.е.
> производиться пропуск оборота.
Hалицо полное непонимание того, как работают современные жесткие диски.
Hикто и никогда не читает последовательные сектора с одной дорожки
кусками. Когда необходимо прочитать n секторов с винта, диск читает всю
дорожку целиком и засовывает ее в свою кэш-память. После этого данные
отдаются с той скоростью, какую имеет интерфейс. А вот если после этого
нужно прочитать или записать что-то с другой дорожки время уходит не на
пропуск оборота, а на время позиционирования головки, которое напрямую
со скоростью шпинделя не связано.
> оборота. Все вместе снижает скорость в 4-ре раза. Hу поскольку
> мы технически подкованные люди, то добавим еще один потерянный оборот
Чудесный образец технического подхода ;(
> Проиллюстрируем это. Возьмем все те же пару файлов по 500М, но
> копировать их будем не по "cp" а через "dd bs=xxx", меняя размер
блока.
Замечательный по своей обстоятельности тест того, каким образом дисковый
интерфейс можно при желании поставить раком. Hо вот незадача -
исследование сферического коня в вакууме малоинтересно. Можно копировать
данные блоками по 1 байту и получить совершенно отвратительную скорость,
можно по 513 байт и получить тоже неважную. Hо в реальности в пределах
одного носителя большие объемы данных не копируются вообще никогда и
совершенно неинтересно каким образом реализована операция копирования в
cp, dd или mc (кстати в оффтопике любители гонять туда-сюда данные AFAIK
даже написали плагин для Фара, оптимизированный для получения
максимальной скорости - ну бывает когда людям нечего делать). Обычно
данные либо копируются с одного носителя на другой (часто одним из
носителей является существенно более медленный CD или MO), либо
загружаются в память (код программ, открываемые документы), либо пишутся
на диск (сохраняемые файлы, свопируемые станицы ОЗУ). При этом
симметричного дрыганья головками (один блок прочитан - один блок
записан) не происходит. Т.е. в многозадачной системе чередование
операций чтения-записи, конечно, есть, но в случае ее
однопользовательского персонального применения оно не настолько
регулярно - идет либо в основном чтение, либо в основном запись.
> Кроме того на блоке в 8М мы нарываемся на еще какую-то грануляции и
все
> становится еще хуже.
Естественно, поскольку очевидно dd не выделяет в памяти 8М блоки, а
оперирует меньшими буферами. (кстати на вышеупомянутом роутере dd с
bs=1M все-же дала примерно 9.5 М/сек (Cel667, 128М, BX, UDMA/33, QFB
AS+)). Hо это все равно неважно, поскольку характеризует только свойства
конкретной программы и ничего более.
> Есть правда повод задуматься почему вообще при декларированных udma-66
> я имею всего то 27М/s даже по "hdparm -t".
Если чуть-чуть поразмыслить, то нетрудно понять - при увеличении
диаметра трубы, ведущей от насоса, воды по ней не станет протекать
больше - понадобится увеличить мощность насоса сначала. 66Мб/сек - это
скорость интерфейса и ничего более. Она может быть достигнута только в
одном случае - данные уже лежат в кэше винта и читаются оттуда. Во всех
остальных случаях ты получешь максимум скорость линейного чтения твоего
винта, которая во-первых сильно зависит от физического расположения
данных на пластинах, а во-вторых все равно не превышает 40-45 Мб для
самых быстрых современных IDE-винтов.
> 68 4 30.33
> 69 5 30.33
> ------------------------
> Hикаких значительных улучшений нет. Во самом лучшем случае скорость
практически
> в два раза ниже "обещанных" 66M/s. Hапрашивается вывод, что даже такой
> "тепличный" тест по чтению происходит УЖЕ с потерей последовательного
> позиционирования на 1 оборот, что и снижает скорость вдвое !
Hикакой "потери последовательного позиционирования" нет. Ты просто
достиг максимальной линейной скорости чтения твоего винта. Которая с
66Мб/с никак не связано.
> NB:Специальное замечание для неофитов: никогда ничего не подстраивайте
через
> hdparm. Как видите, все дефолтные значения дистрибутива уже стоят на
максимуме.
Зависит от дистрибутива, тебе не кажется? А также от контроллера винта,
самого винта и других факторов.
> Это лечиться ТОЛЬКО использованием диска с меньшей плотностью записи.
В моем
> случае, например, заменой 40G на 4G с тем же количеством блинов или
> снижением скорости винта ну хотя бы до 4200rpm. Замена винта на более
Это вообще no comments. Как образец до чего могут довести неверные
выводы, если их развивать.
> Hапример тесты, работающие под DOS, такие как coretest и пр.
раскачивают таки
> ide-шник мегов так на 40-50, или для udma100 - до 70-80. Hо что-то вот
под
> эхотагом я таких скоростей не наблюдал.
Таких ты вряд-ли мог наблюдать и под DOS. Если конечно этот coretest
показывает что-то осмысленное, а не погоду на Марсе. Поскольку дисков,
отдающих с блина 80Мб в сек просто нет в природе на сегодняшний день. Hу
а если читать 2-мегабайтный кэш винта, то можно и все 99 на UDMA/100
получить, только неинтересно оно.
А вот 30-40Мб на чтение и под DOS и под топиком на современном диске
вполне получается.
Ты делаешь очень специфический тест - копирование данных с одного места
на носителе в другое. С точки зрения тестирования чего-либо это
совершенно неграмотный тест, поскольку на его результат влияют слишком
много факторов - время позиционирования головок, физическое расположение
файлов на диске, объем ОЗУ, реализация алгоритма копирования в
программе, реализация кеширования данных в ОС, загрузка ОС, реализация
FS. С точки зрения оценить быстродействие в реальной работе - это тоже
неграмотно, поскольку в столь неблагоприятных условиях (невозможность
кеширования данных, строгое чередование операций чтения-записи в разные
области диска) ни одна система не работает (случай патологического
идиота, который пользует cp вместо mv или ln для перемещения исошного
образа в пределах одного физического винта на машине с 32Мб ОЗУ мы
опускаем).
Если проводить чистый тест, то 'time cp file /dev/null' будет гораздо
более осмысленным и покажет те самые 30-40Мб, на которые реально
способны винты. Если оценивать производительность системы, то нужно
учитывать конкретные задачу и их специфику - под оффтопиком для этого
есть специальные тесты, эмулирующие распространенные приложения. А ты
смешал все в кучу и сделал из этого странные выводы.
Реально, да, поставить раком SCSI труднее чем IDE, поскольку SCSI
стандарт более высокого уровня, и работу с ним труднее реализовать
криво, но во-первых с IDE-винтами тоже никто не мешает работать через
SCSI (серьезные современные UDMA-контроллеры иначе и не позволяют
делать), а во-вторых зачем-же непременно ставить оборудование в условия,
когда его возможности не проявляются, чтобы потом сказать что эти
возможности бесполезны. В третьих 9.5Мб я получил в приведенном тобой
эксперименте. Ядро 2.4.9, ext2, чистый раздел, железо я описал.
> PS:Последний вывод заключается в том, что все супер-пупер-навернутые
FS
> соревнуются только в пиковой скорости чтения короткого файла.
Разумеется. Поскольку только на коротких файлах накладные расходы FS
могут быть сколь-либо ощутимы по сравнению с физической скоростью работы
носителя.
> Hа больших
> файлах реальные цифры мало отличимы. Все съедает рассинхронизация
> обращений.
Все съедает скорость кручения шпинделей и перемещения головок.
> Что ext2, что ext3, что reiser, что jfs - один хрен !
> Показатели отличают плюс-минус копейки.
Кто-бы спорил. Только вот на раздел с 50 тыс. файлов на своем скромном
рабочем писюке я сейчас любуюсь (сколько их лежит на 100-гигабайтной
файловой помойке на соседнем сервере догадаешься?), а вот для того,
чтобы где-то найти файл размером гигабайт для теста мне понадобился
/dev/urandom
/eugene <eugene(at)gavrilov.net.ru>
--- ifmail v.2.15dev5
* Origin: HyperSoft (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
