Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
Стыдно вспомнить, но в молодости я тоже занимался... 08.02.05 11:08 Число просмотров: 2298
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
Стыдно вспомнить, но в молодости я тоже занимался оптимизацией.
Оптимизация ускоряет дисковые процессы - это по моему миф. Когда файлы кешируются, то по барабану как они лежат на диске. Разве что первое прчтение будет занимать чуть больше времени.
Про сервак я вообще молчу. Когда куча пользователей работают каждый со своим файлом, то по барабану фрагментирован ли каждый из них или непрерывен, все равно головка дергаться будет.
То же самое с копированием большого количества файлов - головка дергается по фатам, каталогам и содержимым файлов, и собственно по барабану дернется ли она в то же самое место при считывании очередной порции файла или в другое.
И нечего мучить диск оптимизацией из-за мнимого копеечного выигрыша производительности при работе.
|
|
<software>
|
Программа дефрагментации НТФС. 07.02.05 17:10
Автор: Garick <Yuriy> Статус: Elderman
|
преамбула отсюда http://www.ixbt.com/storage/ntfs.html
"Допустим, мы хотим положить файлы подряд в начало диска. Кладем один файл. Он оставляет хвост занятости дополнения до кратности 16. Кладем следующий - после хвоста, естественно. Через некоторое время, по освобождению хвоста, имеем дырку <16 кластеров размером. Которую потом невозможно заполнить через API дефрагментации! В результате, до оптимизации картина свободного места выглядела так: много дырок примерно одинакового размера. После оптимизации - одна дыра в конце диска, и много маленьких <16 кластеров дырок в заполненном файлами участке. Какие места в первую очередь заполняются? Правильно, находящиеся ближе к началу диска мелкие дырки <16 кластеров... Любой файл, плавно созданный на прооптимизированном диске, будет состоять из дикого числа фрагментов. Да, диск потом можно оптимизировать снова. А потом еще раз.. и еще.. и так - желательно каждую неделю. Бред? Реальность.
......
Пока есть всего один дефрагментатор, который игнорирует API дефрагментации и работает как-то более напрямую - Norton Speeddisk 5.0 для NT. Когда его пытаются сравнить со всеми остальными - Diskeeper, O&O defrag, т.д. - не упоминают этого главного, самого принципиального, отличия. Просто потому, что эта проблема тщательно скрывается, по крайней мере уж точно не афишируется на каждом шагу. Speeddisk - единственная на сегодняшний день программа, которая может оптимизировать диск полностью, не создавая маленьких незаполненных фрагментов свободного места. Стоит добавить также, что при помощи стандартного API невозможно дефрагментировать тома NTFS с кластером более 4 Кбайт, а SpeedDisk и это может.
К сожалению, в Windows 2000 поместили дефрагментатор, который работает через API, и, соответственно, плодит дырки <16 кластеров. Так что как только появится (если еще не появился) - так сразу надо качать Speeddisk для W2k.
Как некоторый вывод из всего этого: все остальные дефрагментаторы при одноразовом применении просто вредны. Если вы запускали его хоть раз - нужно запускать его потом хотя бы раз в месяц, чтобы избавится от фрагментации новоприбывающих файлов."
Амбула
статья за 2000 год. изменилось что нибудь с другим софтом? Не могу никак найти новой информации.
Очень интересует софтинка под ДОС (или загрузочный образ под Линукс) дефрагментирующий НТФС без болезни описанной выше.
|
|
Стыдно вспомнить, но в молодости я тоже занимался... 08.02.05 11:08
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
Стыдно вспомнить, но в молодости я тоже занимался оптимизацией.
Оптимизация ускоряет дисковые процессы - это по моему миф. Когда файлы кешируются, то по барабану как они лежат на диске. Разве что первое прчтение будет занимать чуть больше времени.
Про сервак я вообще молчу. Когда куча пользователей работают каждый со своим файлом, то по барабану фрагментирован ли каждый из них или непрерывен, все равно головка дергаться будет.
То же самое с копированием большого количества файлов - головка дергается по фатам, каталогам и содержимым файлов, и собственно по барабану дернется ли она в то же самое место при считывании очередной порции файла или в другое.
И нечего мучить диск оптимизацией из-за мнимого копеечного выигрыша производительности при работе.
|
| |
Здесь ситуация несколько иная... 08.02.05 11:40
Автор: Garick <Yuriy> Статус: Elderman
Отредактировано 08.02.05 11:43 Количество правок: 1
|
> Оптимизация ускоряет дисковые процессы - это по моему миф.
> Когда файлы кешируются, то по барабану как они лежат на
> диске. Разве что первое прчтение будет занимать чуть больше
> времени.
> Про сервак я вообще молчу. Когда куча пользователей
> работают каждый со своим файлом, то по барабану
> фрагментирован ли каждый из них или непрерывен, все равно
> головка дергаться будет.
На сервере РЕЙД 5 стоит еще и со своим кешем, а как он (РЕЙД 5) распределяет физически по диску блоки - одному РЕЙДУ известно. Представители Интел на конференциях "скромно" обходят этот вопрос. И вопрос дефрагментации рейда. Информация ИМХО конфенденциальная.
> То же самое с копированием большого количества файлов -
> головка дергается по фатам, каталогам и содержимым файлов,
> и собственно по барабану дернется ли она в то же самое
> место при считывании очередной порции файла или в другое.
в НТФС нет фата. есть MFT. И особенность работы такова, что при оставшемся свободном месте менее 15%, это место выделяется для данных, те происходит фрагментация MFT, что может сильно снизить производительность. Для серверов с одиночным или зеркальным диском ситуация возможна и она произошла из за ошибок в планирование дискового пространства (базы 1с положили на системный диск и они разрослись до почти полного "забоя" дискового пространства).
> И нечего мучить диск оптимизацией из-за мнимого копеечного
> выигрыша производительности при работе.
Головка то будет дергаться, но у привода головки есть свой ресурс и снижение нагрузки на привод может привести увеличению срока службы диска, а при большом ИТ парке к некоторой экономии бюджета.
При достаточно высокой стоимости серверной мощности оптимизация или исправление просчетов (лучше их не допускать:-) могут принести значительную экономию.
ЗЫ: Я не призываю делать плановую (например ежемесячную) дефрагментацию. Ресурс диска при этом также пострадает. Но исправить просчет и вернуть плановую производительность ИМХО надо.
ЗЫЫ: я заметил достаточно ощутимый прирост скорости закрузки ОС в2к на рабочей станции со слабой мощностью после дефрагментации. Сотрудник доволен, начальство то же (несколько продлен срок службы компа за незначительные ресурсы) :-)
|
| | |
Слово "фрагментация" можно применять только к файловой... 08.02.05 13:22
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> На сервере РЕЙД 5 стоит еще и со своим кешем, а как он
> (РЕЙД 5) распределяет физически по диску блоки - одному
> РЕЙДУ известно. Представители Интел на конференциях
> "скромно" обходят этот вопрос. И вопрос дефрагментации
> рейда. Информация ИМХО конфенденциальная.
Слово "фрагментация" можно применять только к файловой структуре. К РЭЙДу этот термин не применим. От комментариев воздержусь.
> в НТФС нет фата. есть MFT. И особенность работы такова, что
Все равно это таблица с информацией о размещении файлов. Структура принципиально другая смысл содержимого абсолютно идентичный. Как эту таблицу не назови, в любой ФС есть такая табличка.
> при оставшемся свободном месте менее 15%, это место
> выделяется для данных, те происходит фрагментация MFT, что
> может сильно снизить производительность. Для серверов с
> одиночным или зеркальным диском ситуация возможна и она
> произошла из за ошибок в планирование дискового
> пространства (базы 1с положили на системный диск и они
> разрослись до почти полного "забоя" дискового
> пространства).
У каждой ФС есть свои преимущества и недостатки. Причем преимущества могут себя проявить недостатками при определенной ситуации.
> Головка то будет дергаться, но у привода головки есть свой
> ресурс и снижение нагрузки на привод может привести
> увеличению срока службы диска, а при большом ИТ парке к
> некоторой экономии бюджета.
Если диск не тянет трех лет непрерывной работы с максимальной нагрузкой, значит он неправильно спроектирован или бракованный.
> При достаточно высокой стоимости серверной мощности
> оптимизация или исправление просчетов (лучше их не
> допускать:-) могут принести значительную экономию.
Другими методами можно добиться бОльшего экономического эффекта.
> ЗЫ: Я не призываю делать плановую (например ежемесячную)
> дефрагментацию. Ресурс диска при этом также пострадает. Но
> исправить просчет и вернуть плановую производительность
> ИМХО надо.
Файловый кэш колосально снижает нагрузку на диск. Операционная система должна оптимизировать перемещение головки.
> ЗЫЫ: я заметил достаточно ощутимый прирост скорости
> закрузки ОС в2к на рабочей станции со слабой мощностью
> после дефрагментации. Сотрудник доволен, начальство то же
> (несколько продлен срок службы компа за незначительные
> ресурсы) :-)
РС загружаются раз в день, серваки раз в год. Без разницы что 10 секунд будет грузиться, что 100 секунд, что 10 минут.
При загрузке ОС принимают участие в основном системные файлы, а они как правило нефрагментированы, лежат друг за другом, "близко" друг от друга (если считать расстояние в целиндрах), да еще в начале диска.
|
| | | |
ре:Слово "фрагментация" можно применять только к файловой... 08.02.05 16:01
Автор: Garick <Yuriy> Статус: Elderman
|
> Слово "фрагментация" можно применять только к файловой
> структуре. К РЭЙДу этот термин не применим. От комментариев
> воздержусь.
Я рассматривал систему в комплексе. ИМХО неучитывать особености носителя (контроллер+диски) нельзя. Компаковский Смартаррай с 4-мя дисками в РЕЙД 5 (27 гб) на запрос дефрагментации пошуршал винтами и выдал "готово" через несколько сек. Делал ли реально он что с инфой или выдал статус "готово"? Вот в чем вопрос. ИМХО статус:-)
> Все равно это таблица с информацией о размещении файлов.
> Структура принципиально другая смысл содержимого абсолютно
> идентичный. Как эту таблицу не назови, в любой ФС есть
> такая табличка.
ФАТ таблица не может фрагментироваться по стандарту, МТФ может и это приводит к снижению производительности.
> У каждой ФС есть свои преимущества и недостатки. Причем
> преимущества могут себя проявить недостатками при
> определенной ситуации.
Что есть - то есть:-)
> Если диск не тянет трех лет непрерывной работы с
> максимальной нагрузкой, значит он неправильно спроектирован
> или бракованный.
А он должен работать с максимальной нагрузкой. У десктопных винтов ПВ (продолжительность включения) не 100%. Но не это главное. Серверные SCSI винты расчитаны на 100% ПВ, но время жизни сервера (7-8 лет) больше гарантийного срока винта и приходится их "беречь":-)
> > При достаточно высокой стоимости серверной мощности
> > оптимизация или исправление просчетов (лучше их не
> > допускать:-) могут принести значительную экономию.
>
> Другими методами можно добиться бОльшего экономического
> эффекта.
Примеры? А если еще к "другими методами" добавить и этот - хуже не будет
> Файловый кэш колосально снижает нагрузку на диск.
> Операционная система должна оптимизировать перемещение
> головки.
Файловый кеш не дешево обходится, особенно для РЕЙД контроллеров, а еще и с батарейкой.
> РС загружаются раз в день, серваки раз в год. Без разницы
> что 10 секунд будет грузиться, что 100 секунд, что 10
> минут.
Разница есть, простые смертные юзвери оценивают качество работы ИТ отдела в удобстве (но не в ущерб безопасности). Иногда имеет тенденцию опаздывать и быстрая загрузка реалибитирует их в глазах нач отделов. Еще встречаются форс мажоры по важной отгрузке/тендерам/клиенте и выключении света. Явный пример: ХР при равных достаточных условиях грузится быстрее в2к. Программеры МС оптимизировали процесс загрузки ОС. Если бы фактор быстрой закгрузки не был бы важен в бизнес процесе - вряд ли бы МС заморачивалась бы с этим:-)
> При загрузке ОС принимают участие в основном системные
> файлы, а они как правило нефрагментированы, лежат друг за
> другом, "близко" друг от друга (если считать расстояние в
> целиндрах), да еще в начале диска.
Не факт. При "чистой" системе это так, но после установке СП и хотфиксов после начала использования кома - может начаться фрагментация. К системным можно отнести и доустановленные сервисы, стартующие при запуске системы, которые в свою очередь, через некоторое время, также патчаться и фиксятся.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
