Yuri N. Glibovetz [mailto:gyn***@m*****.ru] пишет:
>
> > 3. ОСНОВНЫЕ ЗАДЕРЖКИ на уровне файловой системы происходят не при
> > чтении-записи данных, а при открытии-закрытии файлов!
>
> Именно при чтении-записи данных и происходит основная
> задержка, связанная с фрагментацией. Причина в том, что
> скорость перемещения головки диска на несколько порядков ниже
> скорости чтения-записи информации. Допустим, время
> перемещения головки с начального до конечного цилиндра 30мс
> (что приблизительно соответствует реальности).
> Если соседние данные будут разбросаны на крайние цилиндры, то
> при размере кластера 4Кб за одну секунду будет прочитано
> всего 133Кб, в то время, как диск способен передавать 100Мб в
> секунду (разница почти на три порядка). Обычно такой дикой
> фрагментации не бывает, но все равно замедление на один
> порядок очень даже возможно.
>
Не совсем так. Более-менее "правильный" планировщик создаст в очереди команд
к диску две группы - на чтение в начале диска, и на чтение в конце диска. И
выполнит их последовательно, т.е. глобальных перемещений будет всего 3-5
(учитывая другие запросы к диску). К тому же время позиционирования
начало-конец на самом деле ненамного больше времени трэк-трэк (гораздо
меньше порядка)). Основное время занимает точная доводка и стабилизация
головок. Да и передать 100мб за секунду на сегодняшний день не способен
никто 8-)) - самый гнилой винт дает 2-3 ГБ/с уже "для приложений", т.е.
после всех "надстроек" файловой системы. А если имелось в виду
100_Гига_б/с... У меня NTFS5 на "Cheetah X15 36LP" (это при 15Krpm и
uwSCSI-320!) усредненно давала порядка 65ГБ/с в лучшие годы... Процы стояли
неслабые - Ксеоны однако.
Задержка первых данных ("сырых" секторов) при выполнении команды
позиционивания-чтения при сброшенных дисковых кэшах находится в порядках
"срденее время позиционирования"+"2-4 оборота диска"+"50~500мкс на системные
нужды" т.е. для ИДЕ дисков 7200об/мин это порядка 9-12мс, для uwSCSI дисков
на 10000об/мин это уже 3-5мс.
Как таковая, фрагментация файлов данных начинает играть заметную роль в
_быстродействии_приложения_ только в несколькох случаях:
1) приложение "медленное", и сервер успевает вытеснить данные из системного
кэша (имеются в виду _служебные_данные о файле - таблицы размещения и т.п.)
При перепрочтении ещё и служебной информации уж точно будет больше
позиционирования. Насколько я помню, и в NTFS, и в большинстве Униксовых ФС
служебная информация разбросана по диску, а в самых "умных" её размещение
начинается не с начала раздела диска, как многие думают, а с середины -
среднее расстояние позиционирования до данных от центра раздела в два раза
меньше, чем от края (можно и вперёд лететь, и назад)...
2) сервер сильно загружен другими задачами, и просто вытесняет блоки данных
из дискового кэша.
3) Близкий к 2) вариант - маленький размер самого кэша. По моим прикидкам,
дисковый кэш в RAM должен позволять вмещать всю служебную информацию со всех
смонтированных томов плюс 25-50% (хотя бы) от объёма часто запрашиваемых
данных. Это минимизирует "неудобные" запросы позиционирования-чтения. Запись
в служебные области все равно останется, но если разрешена отложенная
запись, это почти незаметно. Такие требования при современном "гигантизме"
дисков иногда непросто выполнить - служебная область на заполненном 120ГБ
томе может составлять 3-4гб, а если на нем очень много мелких файлов (при
хостинге веб сайтов, например) то ещё больше. Тут NTFS резко проигрывает
EXTам и UFSам, поскольку в НТ с каждым файлом хранится (и каждый раз
обрабатывается ситемой) не очень маленький Access Control List, который в
Униксах занимает всего пару DWORD. Сама идея ACL и NTFS Security очень
сильная, но в большинстве практических применений избыточная.
4) на сервере только один диск - и на систему, и на данные, и у него
отключена отложенная запись. Типично для "маленьких" серверов под
Вынь2000АС-контроллером домена. Эта "роль"(PDC) принудительно отключает
отложенную запись. Система создаёт _заметный_ поток на запись (логи и пр.),
да и сама запись осуществляется несколько медленнее, и позиционирование для
записи "вклинивается" в поток команд к диску самым бесцеремонным образом...
-= лёгкий оффтопик =-
Со скоростью работы дисков связано несколько разных факторов -
-- средняя задержка позинионирования - вычисляется именно "усреднением",
т.е. зависит от задач, выполняющихся его контроллером. У SCSI дисков,
поддерживающих очередь команд (а они все её поддерживают) контроллер может
лучше планировать перемещения головок. Вкупе с другими фишками средняя
скорость поиска на хороших uwSCSI дисках достигает 3.5-4мс(!).
-- задержка "track-to-track". При чтении очень больших объёмов данных
"подряд" создает паузы в потоке данных, вызванные "шаганием" тонарма с
головками. У хороших SCSI-дисков составляет 0.2-0.3мс(!). Ближе к центру
диска она чуть меньше, поскольку стабилизация головок проходит легче при
меньшей скорости обдува пограничным слоем воздуха.
-- средняя задержка поиска сектора, вызванная конечной скоростью вращения
дисков. Идеально было бы сразу после стабилизации головок на цилиндре
считать за один оборот все содержимое цилиндра, и потом разбираться с ним.
High-End диски, похоже, примерно так и делают - кэш 8мб примерно
соответствует объёму нескольких дорожек (например, Seagate Cheetah X15 36LP
имеет 18497 цилиндров - в среднем по 2мб на дорожку). Читают ли они только
одну поверхность, или весь цилиндр - не знаю, не изучал. По-моему, памяти
все-таки маловато для всего цилиндра, да и предыдущие данные надо отдавать в
шину постепенно.
-- Задержки передачи данных. Целиком и полностью зависят от возможностей
интерфейсов, загрузки контроллера и самой системы и пр.
-- "скрытые" технологические моменты:
- рекалибровка термическая - механические свойства системы меняются
при нагреве;
- рекалибровка вибрационная (есть такая на быстрых дорогих дисках)
для устранения резонансной вибрации в многодисковых шасси;
кстати, из этих же соображений реальная скорость вращения у
каждого диска чуть-чуть "своя"
- снижение активности с целью охлаждения микросхем (тоже видел такое
в одном Design Note на микроконтроллер от Fujitsu)
- искусственное "выравнивание" потока данных на т.н AV (Audio-Video)
дисках, предназначенных для потоковой записи-чтения (видеомонтаж etc.), при
котором даже в "удачных" последовательностях команд все равно имитируется
некоторая задержка позиционирования.
__ПОЛЕЗНОЕ:
Поскольку внешние треки позволяют записывать в 2-2.5 раза больше данных при
той же линейной (физической) плотности записи, современные диски используют
технологию зонной записи (кажется, так она называется), размечая внешние
треки на бОльшее количество секторов.
Это дает интересный эффект (проверен на практике): для интенсивной
файлогонятельной загрузки есть смысл создать отдельный раздел на внешнем
крае диска. Я генерил RAID 0+1 (stripped-marrored volume) на двух парах
небольших винтов (старенкие читы 9ГБ 10000об/мин) специально для хранения
данных 1С, для самодельного фокспрошного приложения, даже для кеширующих
прокси (SQUID, MS ISA Server) - результат очень заметный даже визуально!
И последствия фрагментации в таком случае минимизируются при прочих равных
условиях - количество перемещений головок в 2 раза меньше.
...Кстати, на IDE дисках почему-то иногда наблюдалось обратное (например, на
Fujitsu 20GB 7200rpm).
Спасибо за долготерпение при прочтении данного опуса.
Всех благ, Игорь Гаврилюк
-*Название листа "Обсуждения и споры о свободных системах и всём сопутствующем"
Написать в лист: comp.soft.linux.debate-list@subscribe.ru
Архив Листа - http://subscribe.ru/archive/comp.soft.linux.debate Поиск: http://www.google.com
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.debate/rules
Номер письма: 1310; Возраст листа: 241; Участников: 583
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.debate/msg/173863
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.debate-list@subscribe.ru
Отписать : mailto:comp.soft.linux.debate--unsub@subscribe.ru
http://subscribe.ru/ mailto:ask@subscribe.ru
