HDD и SSD – единство различий (страница 5)
реклама
Хоть игра вышла недавно, но представляет старый 'движок' с новыми картами. Нагрузка на дисковую систему соответствующая - мизерная.
Crysis Warhead.
Режим загрузки уровня ведется блоками с большим разбросом величин, что подразумевает индивидуальное считывание частей игры.
В самом процессе игры чего-то необычного не наблюдается, дисковая активность незначительная, фрагменты подгружаются блоками 4-8 Кбайт для высокоскоростного доступа и порядка 1 Кбайт для низкоскоростного.
реклама
В статистике присутствует 3 Мб записанных данных. Их источником было три автоматических сохранения по 1 Мб в процессе игры. Интересно, запись велась большими блоками (64 Кбайт и 256 Кбайт), что подразумевает оптимизацию и довольно необычно.
Crysis 2.
Не могу сказать, что принес CryENGINE 3 в игру как игровой движок, но работа с диском и использование памяти явно претерпели изменения к лучшему. Если в Crysis Warhead, для девяти минут игрового времени, было считано 2.3 Гбайта за пять минут дисковой активности, то в Crysis 2, за 23 минуты всего 419 Мбайт. Похоже, этой игре вообще не важна производительность дисковой системы.
И, напоследок, самое сладкое - S.T.A.L.K.E.R.: Зов Припяти.
С загрузкой все логично - эта игра использует режим отображения файлов вместо файловых операций, поэтому большой трафик присутствует только в разделе Mapping. Размер блока при данных операциях большой, от 128 Кбайт до 16 Мбайт при среднем 5 Мбайт. Пока всё красиво, переходим к процессу игры. И тут наступает ОЙ.
В процессе игры происходит большая активность ФАЙЛОВЫХ операций. Ну, так не бывает, не верю. Объяснение данному феноме́ну может быть только одно - загрузку графического окружения разработали одни люди, а то, что делается при самой игре - другие. Один разработчик не будет смешивать разнородный тип обращения для однотипных действий. Если используется file mapping, то он и будет использоваться для всех операций с данными - так проще и удобнее. С точки зрения использования реальной или виртуальной памяти, оба способа: отображение файлов и файловое чтение в блок памяти полностью одинаковы - и там, и там требуется регион памяти одинакового размера.
реклама
Правда, стоит отметить, что отображение файлов всё же лучше работает с большими объемами данных, а с маленькими могут быть накладки и файловое чтение может быть эффективнее. Ну, эта игра 'славится' своими микрофризами, поэтому постоянное высокоскоростное чтение во время игрового процесса не вызывает недоумения. Просто так сделано. Ужасно.
О, давайте сделаем прогон официального измерителя производительности фирмы GSC Game World. В нём отсутствуют такие мелкие глупости, как подгрузка уровней и состояния объектов.
Гм, никаких файловых операций не вижу.
Прежде, чем закрыть вопрос игр, хорошо бы взглянуть - насколько стабильна дисковая активность в играх. Статистика показывает общие результаты, но считывание может происходить импульсно, не монотонно. В таком случае мера дефектности будет выше.
Не будем особо распространяться, достаточно двух игр - Crysis Warhead (слева) и S.T.A.L.K.E.R. (справа).
Лог снимался с помощью S&M, поэтому на графиках присутствуют только файловые операции (линия красного цвета, шкала логарифмическая) без дисковых операций в режиме отображения. Для S.T.A.L.K.E.R. этот недостаток проявляется в отсутствии показа дисковой активности при загрузке уровня в самом начале и середине графика.
Ну что, в обоих случаях видно, что интенсивность считывания данных примерно одинакова за все игровое время, что позволяет доверять результатам статистики, приведенным ранее.
Перейдем от игрового компьютера к 'неигровому'.
На нём запускалось обычное, и не совсем, офисное программное обеспечение. На компьютере установлены uTorrent, Opera и довольно быстрый интернет.... что давно стало обычным явлением. Компьютер для работы, игр на нём нет.
Статистика за 273 часа, но компьютер на ночь не выключался, поэтому сюда заложено 2/3 простоя. Torrent работал всё время, но нагрузка от него мизерная - о нём разговор позже.
Если сравнивать с 'игровым' компьютером, то отличия имеются.
Для медленных операций чтения ситуация примерно та же - 15 часов чтения файлов 1 Кбайт, а для медленной записи новое - если в игровом компьютере медленная запись практически отсутствовала, то в этом варианте запись происходит, причем довольно часто, четыре часа общей работы. Размер блока записи напоминает чтение, 1 Кбайт, но присутствуют блоки и большего размера - 2-4-8 Кбайт.
реклама
Для быстрых операций как чтения, так и записи, характерен блок доступа 128 Кбайт. Хотя, сам факт, что семь часов происходили быстрые (высокоскоростные) операции чтения настораживает. Может Opera 'помогла'? Интернетом-то пользовались.
По отображению то же, что и ранее - система читала очень большими блоками. Странно, что набралось почти три минуты, когда система записывала в режиме отображения, да еще и блоками по 64 Кбайт.
От общего к частному. Давайте попробуем разобраться с Torrent.
На компьютере установлен клиент uTorrent 2.2 с настройками по умолчанию. Вначале загрузка файла. Левый выполнялся со средней скоростью 4М, правый 5М.
Разница в скоростях обоих вариантов незначительна, а лог снимался два раза для другого - посмотреть повторяемость результатов.
Из существенного - из двух минут работы программы девять секунд производилось медленное чтение (всего порядка 60 Кбайт); быстро, но недолго (2-13 секунд) считывалось 10-85 Мбайт просто огромными блоками (400-600 Кбайт) и записывалось одну минуту в высокоскоростном режиме. В последнем случае блок записи был 1 Мбайт. Чтение через отображение тоже проявило свою активность, куда же без нее. Активность была в течение одной минуты при среднем размере блока порядка 1 Мбайт. Только не спрашивайте меня, зачем операционная система буферизировала операцию записи, вариантов ответа столько, что перечислять устанешь. Ну, делала и всё, примем как должное. Всё равно изменить ничего нельзя (ага, выключить файл подкачки. Примечание переводчика).
Загрузка была, теперь раздача. Слева 300К, справа 2М.
Если забыть про низкоскоростной обмен, что совсем 'мелочь', то выходит следующая картина - uTorrent читает блоками 128 Кбайт. Второе - при раздаче 'что-то' пишется на диск. Для первого случая за шесть минут было записано 3.3 Мбайт и роздано 120 Мбайт. Для второго - 14 Мбайт за полчаса и раздачи 4.8 Гбайт данных. Похоже, uTorrent пишет на диск каждые 15 секунд блок данных 128 Кбайт вне зависимости от скорости раздачи данных. Этот вид статистики не может показать, производится ли подобная активность при приеме данных, ведь тип и место записи отдельных операций статистики не разделяются.
Если говорить о программах, которые изначально ориентированы на высокое использование дисковой системы, то, как правило, в них применяются специальные меры по увеличению блока доступа для снижения нагрузки. Например, VirtualDub (перекодирование видеоконтента) считывает блоками 128 Кбайт и записывает 512 Кбайт при использовании специальных временных буферов - всё это настраивается в свойствах программы.
Что до 'фирменных' программ типа Photoshop, то в них возможно всякое и логическому осмыслению не подлежит. У пользователя всё равно нет выбора, будет работать с тем, что есть.
Паузы в работе
В предыдущем разделе вы видели, что дисковая система работает с высокой нагрузкой довольно редко и не слишком долго.
Это означает микро-паузы в работе. У обоих типов дисковых накопителей, и у HDD, и у SSD, используется режим отложенной записи. Если есть пауза в работе и присутствуют несохраненные данные, то накопитель выполнит их запись. С точки зрения операционной системы это произойдет совершенно незаметно. Давайте уточним - выполнение команды записи кэшированное, то есть дисковый накопитель сразу возвращает признак 'выполнено' и действительное выполнение записи можно почувствовать только по 'странной' задержке или падению скорости выполнения команд чтения. Если есть пауза в работе, то запись будет выполнена в этот момент времени и очередь команд на чтение не пострадает, ведь она была пустой.
Кроме отложенной записи, HDD может выполнять предвыборку типично используемых данных. Не слишком известный факт, но HDD некоторых фирм знают о типе файловой системы на диске. Узнать это нетрудно, достаточно прочитать нулевой сектор и разобрать очень простую структуру разделов диска.
Как HDD может использовать эти данные? Загадка за семью печатями. У каждого типа файловой системы свои особенности. Для операционных систем Windows самой любимой является NTFS с ее журналированием и стремлением упихивать мелкие файлы в MFT. Первое означает постоянный (и довольно глупый) поток записей журналирования, которые можно слегка 'покэшировать' с снижением объема реально выполняемых операций. А второе - частую модификацию отдельных секторов данных, которые были считаны совсем недавно. При добавлении незначительных по объему данных в MFT они дописываются к последней структуре (в конец, в середину, куда выйдет).
При этом не производится никакого выравнивания на границу сектора. Если бы выравнивание производилось, то терялся бы смысл записи в MFT. Но, если новые данные не выровнены, то это обязывает предварительно считать текущее содержимое сектора перед его записью. Вполне очевидно, что подобный тип деятельности тщательно кэшируется в Windows, но память под кэш когда-нибудь закончится или ‘отберется’ программой пользователя. Особенно это 'любят' HDD с AF (сектором 4 Кбайта).
Интересно, когда SSD научатся сами понимать файловую систему? Если уж даже HDD как-то используют эти знания, то в SSD это позволит избавиться от всяких TRIM-ов и GC. Да и транслятор можно сделать проще, хотя – это точно 'размечтался'.
Если взять SSD, то у него более сложная внутренняя структура и при паузах ему сразу найдется что делать. Кроме обозначенной ранее отложенной записи, SSD должен (бы) выполнять фоновую сборку мусора, балансировку использования блоков NAND - анализ статистики и освобождение наименее использованных страниц, упорядочение служебных структур диска. Кроме того, может производиться кэширование чтения - вычитывание в кэш-память данных, которые могут потребоваться впоследствии. Режим предсказания и автонастройки на тип выполняемых команд свойственен современной аппаратуре и есть шанс, что этот прием распространился и в топологии SSD, благо признаки этого отмечаются.
При тестировании быстродействия дискового накопителя на него создается сплошной поток команд, без каких-либо пауз. Насколько данный прием справедлив? Если вспомнить статистику, приведенную выше, то может быть только один вывод - при работе приложений дисковая активность не постоянна. Даже при загрузке игр процент использования дисковой системы далеко не 100%. Вполне понятно, что если суть работы приложения в переписывании файла с одного диска на другой, то особых пауз там не наблюдается, но насколько часто вы пользуетесь такими приложениями?
Ну, хорошо, почему же тесты не желают вставлять паузы в последовательность дисковых команд? Это же уменьшит "синтетичность" исследований и даст более адекватные результаты. Увы, не все так легко.
Паузы добавить просто, но как потом их учитывать? Например, выдали команду записи с последующим простоем. В какой момент считать задание выполненным? Если с HDD бо́льшую часть времени осуществляется позиционирование на нужную дорожку, для маленьких файлов, то в SSD вообще что-то трудно предсказать - очень уж много зависит от того, чем до этого занимался контроллер. А раз трудно предсказать время операции, то - как отделить от нее дополнительную паузу, которую специально добавили в тест? Короче говоря, если с операциями чтения какой-то слабодостоверный результат и можно получить, то с записью и ее отложенным кэшированием всё 'глухо'.
Сервер и домашний компьютер
С домашним компьютером вроде бы всё совсем не ясно, а как быть с серверным использованием дисковых накопителей?
Понятно, что есть модели типа Database, Webserver, Fileserver, но что они значат? На диск посылается сплошная очередь заданий на чтение и запись. Нормально? Ну, давайте начнем с конца - если сервер работает с 100 %-ной загрузкой дисковой системы, то это мертвый сервер. Его производительность уже совсем 'никакая' и его клиенты будут в бешеном восторге.
Вообще-то, загрузка дисковой системы может быть большой, но не долго. Иначе сервер в помойку. Кроме того, при тестировании серверного применения дисков, используют сценарии при довольно существенном и большом проценте операций записи в общем трафике. Я с трудом представляю такой 'черный ящик', называемый сервером, и в котором процент операций записи более, ну скажем, тридцати процентов. Да еще и при большой многопоточности. Единственное, что приходит на ум из задач с присутствием записи - это кэширующий диск для потокового вещания. Но и тут количество потоков записи несопоставимо меньше количества подключаемых клиентов.
PCMark Vantage
Довольно интересный тест. Конечно, до SYSmark не дотягивает, в нем нет пауз. А потому "сферический конь", зато красивый.
Возьмем несколько дисков и посмотрим. Детального тестирования в рамках этой статьи проводить не стоит, и так уже много всякого. Но так, пройдемся по ключевым точкам. Жаль, что нет передовых SSD дисков... ну, что есть.
Участники забега:
- 10k AHCI: Western Digital VelociRaptor WDC WD1500HLFS (150 Гбайт)
- 7200 AHCI: Western Digital Black WDC WD1001FALS (1 Tбайт)
- 7200 IDE: Maxtor Diamond Plus 9 6Y080P0 (80 Гбайт, IDE, единственный привод без поддержки NCQ)
- 5400 AHCI: Western Digital Green WDC WD15EADS (1.5 Tбайт)
- SSD: RAID0 на контроллере JMicron JM36x из двух безродных SSD с формулой 90/35.
Вполне очевидно, что с SSD, даже с таким 'богом забытым', соревноваться бесполезно. Но почему привод 7200 Western Digital Black был быстрее 10k Western Digital VelociRaptor в тесте 'Windows Media Center'? Догадок может быть много, сразу вспоминается два ядра у контроллера WD Black, но не будем отвлекаться.
PCMark Vantage измеритель производительности интересный, но не более того, коль скоро в нем сплошная синтетика. Увы. Можно заметить какие-то аномалии в проколы в производительности, но как сие перенести на реальные приложения пользователя?
eBoostr
В операционных системах Windows последних поколений - Vista и 7 - есть элементы и технологии для ускорения работы с дисковыми накопителями.
Это ReadyBoost® и SuperFetch®. Первое позволяет загрузить во внешний носитель (USB Flash) часто используемые файлы, что снижает время их загрузки. Уменьшение времени вызвано упорядоченным расположением файлов и отсутствием механических деталей у такого типа носителей. Второе - сверхактивное использование системной памяти для кэширования файловых операций. В SuperFetch несколько иначе понимают системную память - она используется как кэш дисковой системы. При этом если программе потребовалась оперативная память, то ей назначаются страницы в файле подкачки без выделения самой памяти и каких-либо действий со страницами файла подкачки.
Короче говоря, память для Windows - это место на диске и всё основано на кэшировании работы дисковой системы. Если в операционных системах предыдущего поколения процент занятости памяти показывал осмысленную информацию, то в Vista/7 этот индикатор особого смысла не несет - кэширование диска включает и выделяемую память. Кроме того, при нехватке системной памяти весь кэш может быть безболезненно удалён операционной системой, а после освобождения памяти, по окончанию работы приложения, SuperFetch начнет заново собирать в ненужной уже системной памяти кэш часто используемых файлов.
Внешне эта деятельность проявляется в 'странной' дисковой активности после выхода из приложения, по привычке ассоциируемая с нехваткой системной памяти из-за обмена данными с файлом подкачки, что вызывает у пользователя желание установки большего количества памяти. Увы, вложенные средства не окупятся, сохранился ли кэш SuperFetch или нет, заметить трудно – его эффективность проявится при повторном запуске программы. И часто вы запускаете небольшие программы, да еще и такие, которые долго загружаются с большой дисковой активностью, на современных дисках?
Программа eBoostr позволяет выполнять действия, аналогичные ReadyBoost и SuperFetch, и работает на Windows не только семейства Vista/7, что позволяет получить ускорение диска даже в "старенькой" Windows XP. Впрочем, программа и позиционировалась изначально как ReadyBoost for Windows XP.
Зачем я упомянул о ней? У SSD есть одно достоинство и один недостаток - очень высокая скорость чтения с маленьким временем поиска и ... безобразная запись. Не столько сам механизм записи, сколько небольшой ресурс NAND и довольно небольшая скорость. Причем, чем дальше в лес, чем более тонкий техпроцесс NAND, тем ресурс будет меньше и меньше. Эта безрадостная картина объясняется тем, что в одной ячейке Flash носителем информации и так уже является ‘счетное’ количество электронов, а будет еще меньше. Интересно, а как у NAND с радиационной стойкостью? Естественный фон никуда не делся, а гамма-излучение легко проходит сквозь корпус микросхемы и может изменить заряд ячейки.
Впрочем, отвлекся. Как бы использовать SSD, чтобы объем записи на него был поменьше?
Можно использовать EWF (Enhanced Write Filter), что позволяет полностью исключить запись на SSD. Но цена этого ... нет, спасибо, не хочется. К слову сказать - EWF можно поставить не только на Windows XP, но и на последнии версии операционной системы Windows, только вам потребуется встраиваемая (Embedded) редакция Windows 7.
Второй вариант 'нестандартного' применения SSD - кэширование дисков. Не думаю, что вы готовы собирать аппаратуру в соответствии с требованием программы maxiq, поэтому про данный способ лучше сразу забыть.
Третий вариант - применить eBoostr.
Данная программа свою функцию выполняет, но ничего сверхнеобычного не ждите. Да, она поможет в 2-3 раза быстрее запустить приложение в первый раз, но все последующие будут производиться из кэша диска операционной системы. Хотя, то же верно и для обычных HDD и SSD. Эффективность работы программы, по ее собственной статистике, составляет 20-60 процентов в зависимости от того, как часто меняются программы на компьютере.
Еще одной особенностью программы является возможность сбора ‘псевдо’ дискового массива - eBoostr позволяет создавать кэш-файл на нескольких физических дисках и при запросе считывать данные одновременно со всех дисков массива.
Стоит ли специально покупать SSD именно для его работы в eBoostr? Сложно сказать, наверно нет. Для точного ответа требуется детальное тестирование. На просторах интернета проводили сравнение эффективности eBoostr с ReadyBoost и результаты не однозначны, хоть и в пользу eBoostr. Прямой перенос исследований, проводимых в интернете, на компьютер с другой конфигурацией невозможен. Значит, стоит провести свою проверку.
В состав eBoostr входит программа измерения скорости первого запуска выбранного приложения. Воспользуемся любезностью разработчиков программы.
Для начала, общий тест производительности в eBoostr:
- Скорость чтения с системного диска VelociRaptor - 37 Мбайт/сек.
- Скорость чтения через кэш - 110 Мбайт/сек.
В три раза быстрее. Довольно много, но как это феноменальное ускорение проявится во времени запуска реальных приложений?
В таблице указано время прямого доступа, без кэширования, время с кэшированием, процент использования кэш-файла на SSD и эффективность от использования eBoostr. Время указывается за пять запусков теста, поэтому не пугайтесь большим числам.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Компрессия
Файловая система NTFS позволяет хранить файлы в сжатом виде. Степень компрессии не очень высокая и не может проявить себя на файлах мультимедиа (сжатый звук, видео), но большинство файлов в современном компьютере сжимаются весьма пристойно. Если вы думаете, что компрессию включают исключительно ради экономии места, то это заблуждение.
Да, сжимание файлов экономит место, но еще и повышает производительность дисковой системы, ведь придется считывать меньший объем данных. Дополнительные затраты на распаковку незначительны и уже для 486-го компьютера расход процессорного времени на декомпрессию был меньше, чем разница времен считывания обычного файла и его сжатой версии. По экономии места вспоминается такое древнее сравнение - при установке Windows NT с настройкой компрессии системного диска, на него удается записать больше данных, чем на обычный несжатый диск без установленного Windows NT.
Чтобы не возвращаться, рекомендация по включению компрессии системного диска для Windows 7:
При загрузке нажать F8, попадем в меню, выбрать "восстановление загрузки системы", войти в систему и выполнить следующую последовательность команд: X:\Windows\System32\>cd c:\Windows\System32\ X:\Windows\System32\>c: C:\Windows\System32\>compact /c /a /i /s:c:\ Подробнее в нашей Конференции. |
Для HDD вопрос разумности включения компрессии уже многократно рассмотрен в просторах интернета и интереса не представляет. Понятно, что ускорение небольшое, экономия дискового пространства давно неактуальна и связываться с 'экзотикой' нет никакой нужды. Но это HDD, а вот у SSD свои приоритеты.
Компрессия и SSD
Начнем с основного. В спецификации ряда SSD указывается скорость чтения/записи порядка 285/275 Мбайт/сек (чтение/запись). У SSD Intel та же формула выглядит как 230/70. Отсюда следует, что продукция Intel медленнее? Ну да, конечно.
В таких 'умных' SSD применяется компрессия данных, аналогичная подобному режиму файловой системы NTFS. Если на такой SSD подавать данные, которые плохо сжимаются, то он покажет далеко не ‘285/275’. Воспользуемся документацией фирмы OCZ - до 285/275 еще ооочень далеко. Кхе, кхе, а откуда же дровишки? Это предположение легко доказывается и иных прочтений нет - в подобных SSD применяется компрессия данных.
Что интересно, тестирование в различных программах может дать и 285/275 и, скажем, 170/35. Всё зависит от программы. Чтобы понять проблему, обратимся к недавней истории – к HDD. Итак, в HDD компрессия не используется и данные записываются в том виде и размере, что приходят в командах записи. Поэтому программам нет какого-то смысла генерировать какие-то специальные шаблоны для тестирования. Обычно, он бывает тривиальным – либо одни нули, либо одни единицы, другие и "необычные" варианты встречаются реже.
Что же произойдет при работе с SSD, у которого включена компрессия? Файлы очень хорошо сожмутся, в несколько раз. Ну, а, коль скоро, размер файла стал меньше, то на его запись (и считывание) придется тратить меньшее время. Плюс к тому, у SSD появляется больше свободного места. Это хорошо? Несомненно, ДА, но есть подводные камни.
Во-первых, сжатые файлы могут обладать большим размером, чем их первоначальный, но это мелочи. Во-вторых, размер файла не соответствует его сжатой версии в SSD, что требует более сложного транслятора. В-третьих, и это уже серьезно, при модификации части файла, буквально 'пары байт' придется производить пережатие нескольких секторов с их последующей перезаписью. Если при этом действии размер данных изменился в бо́льшую сторону и сжатый вариант не уложился в существующее количество секторов, то их число будет увеличено. Проблема даже не в сложных 'телодвижениях' контроллера SSD, а в неэффективном использовании NAND - ведь в вновь добавленном секторе полезную информацию будет нести только ‘пара байт’, а остальное просто пропадет.
Да уж, процедура 'сборки мусора' для таких SSD - далеко не тривиальная операция. Например, у Crucial RealSSD-C300 явно присутствует режим фонового упорядочивания информации. По наблюдениям пользователей таких SSD, сразу после записи могут наблюдаться провалы в скорости чтения, но стоит дать ему спокойно полежать несколько часов (5-10), и эти дефекты исчезают сами собой.
Компрессию можно включить в файловой системе и получить такой же эффект ускорения, при этом не забивая SSD ненужной деятельностью (кстати, 'сборка мусора' явно подразумевает операции по переносу данных, что снижает ресурс накопителя) ... но вот беда, режим компрессии в SSD не отключается.
реклама
Лента материалов раздела
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
Комментарии, содержащие оскорбления, нецензурные выражения (в т.ч. замаскированный мат), экстремистские высказывания, рекламу и спам, удаляются независимо от содержимого, а к их авторам могут применяться меры вплоть до запрета написания комментариев и, в случае написания комментария через социальные сети, жалобы в администрацию данной сети.
Комментарии Правила