Предлагаю обсудить материал
Страница 1 из 1
Обсуждение тестирования трех накопителей Crucial m4 128 Gb в режимах RAID0 и RAID5
#2
Отправлено 16 Январь 2012 - 15:56
2S_A_V:
1. тестировать SSD с очередью больше "1" моветон. Иначе выйдет тест для серверных приложений, которые обычному пользователю 'даром не нать' и только создают путаницу в голове.
Почему 1? Устройства быстрые, win не успевает накопить очередь. Это не мои мысли, сказал один умный мужик ... и я с ним согласен.
2а. Видать, размер stripe выбирался по чтению? При этом оценивалась загрузка процессора? Ой, вовсе не просто так в HAB был добавлен столбец CPU Usage. Доходило до глупого, приходилось УВЕЛИЧИВАТЬ stripe при увеличении кол-ва дисков, причем HDD. А на SSD всё хуже.
2б. stripe означает расслоение потока в блоки по размеру stripe. Это означает, в диск отправляется множество запросов, а контроллер там не шибко быстрый. Сюда плюсуем скрытые проблемы с буфферизацией чтения и явные проблемы с отложенной записью. Ресурс накопителя и внутренняя фрагментация будет ... понятно.
Лично у меня stripe 32K (на паре этих SSD).
3.
ATTO Disk Benchmark v2.46
Настройки: Total Length = 256 Mb, Queue Depth = 4.
Во-первых, "Queue Depth = 4", т.е. результаты не интересны,во вторых не отключено кеширование чтения в RST(скорее всего). К слову, это кеширование уменьшает IOPS чтения мелких блоков раза в два.
4.
"Как уже было сказано выше, отсутствие поддержки TRIM в RAID приводит к падению скорости чтения после заполнения массива информацией. Провалы образуются только на тех участках, в которые после создания массива производилась запись. И остаются там, даже после удаления записанной информации. Давайте посмотрим, насколько велики эти провалы.
Начнём с конфигурации из двух накопителей в режиме RAID0, подключенных к портам SATA3. Провалы скорости достигают 30%."

(!!!!!!!!!!!!)
Там, где информации нет транслятор возращает фигню, а не информацию. Т.е. только там, где, цитирую, "Провалы скорости достигают 30%" находится информация. В остальных местах программа возращает дурь.
Кроме того, следует четко различать два понятия - "на диске находится информация" и "на диск недавно записана информация". Разница в GC, причем существенная.
1. тестировать SSD с очередью больше "1" моветон. Иначе выйдет тест для серверных приложений, которые обычному пользователю 'даром не нать' и только создают путаницу в голове.
Почему 1? Устройства быстрые, win не успевает накопить очередь. Это не мои мысли, сказал один умный мужик ... и я с ним согласен.
2а. Видать, размер stripe выбирался по чтению? При этом оценивалась загрузка процессора? Ой, вовсе не просто так в HAB был добавлен столбец CPU Usage. Доходило до глупого, приходилось УВЕЛИЧИВАТЬ stripe при увеличении кол-ва дисков, причем HDD. А на SSD всё хуже.
2б. stripe означает расслоение потока в блоки по размеру stripe. Это означает, в диск отправляется множество запросов, а контроллер там не шибко быстрый. Сюда плюсуем скрытые проблемы с буфферизацией чтения и явные проблемы с отложенной записью. Ресурс накопителя и внутренняя фрагментация будет ... понятно.
Лично у меня stripe 32K (на паре этих SSD).
3.
ATTO Disk Benchmark v2.46
Настройки: Total Length = 256 Mb, Queue Depth = 4.
Во-первых, "Queue Depth = 4", т.е. результаты не интересны,во вторых не отключено кеширование чтения в RST(скорее всего). К слову, это кеширование уменьшает IOPS чтения мелких блоков раза в два.
4.
"Как уже было сказано выше, отсутствие поддержки TRIM в RAID приводит к падению скорости чтения после заполнения массива информацией. Провалы образуются только на тех участках, в которые после создания массива производилась запись. И остаются там, даже после удаления записанной информации. Давайте посмотрим, насколько велики эти провалы.
Начнём с конфигурации из двух накопителей в режиме RAID0, подключенных к портам SATA3. Провалы скорости достигают 30%."

(!!!!!!!!!!!!)
Там, где информации нет транслятор возращает фигню, а не информацию. Т.е. только там, где, цитирую, "Провалы скорости достигают 30%" находится информация. В остальных местах программа возращает дурь.
Кроме того, следует четко различать два понятия - "на диске находится информация" и "на диск недавно записана информация". Разница в GC, причем существенная.
#3
Отправлено 17 Январь 2012 - 18:07
serj
1. Были использованы бенчмарки, тестирующие как с очередью, так и без. Чтобы кадый мог выбрать то, что ему важнее/нужнее.
2а. Размер stripe выбирался на основе трех HDD-подтестов из PCMark05. Последних из них (Virus Scan) зависит в том числе и от нагрузки на CPU. Конечно эта нагрузка тоже оценивалась, но даже со stripe=4К дисковые операции не создавали существенной нагрузки на разогнанный Core i7-2600K. А даже если бы и создавали, я бы предпочел разогнать процессор еще сильнее (например, до стабильных на воздухе 5.0-5.1 ГГц), вместо того, чтобы пожертвовать показателями в бенчмарках, используя больший размер stripe. Я не утверждаю, что всем и на любых конфигурация надо использовать именно 8К, но свой выбор обосновал приведенными в материале цифрами.
2б. По ресурсу я уже высказал свое мнение в одном из прошлых обзоров: "Трех лет гарантии вполне достаточно, чтобы не боятся преждевременного выхода из строя накопителя. За это время наверняка выйдет что-то новое и еще более быстрое, а проблема исчерпания ресурсов пускай волнует тех, кто покупает "железо" на вторичном рынке."
По остальному - но ведь показатели в бенчмарках все равно выше с небольшим stripe, значить и все перечисленные проблемы (множество запросов, проблемы с буфферизацией чтения и отложенной записью) наверное не столь критичны.
3. Это дефолтные настройки ATTO. При выборе любых других результаты станет невозможно сравнивать с множеством других, доступных в сети и полученных так же на дефолтных настройках.
В RST включал только write back cache, кэширование чтения не менял.
4. "Провалы" по чтению были видны во всех бенчмарках. Для наглядности я привел в качестве примера скрины только из тех, которые могут строить график. Получаетя что все они "возвращают дурь"? А чем тогда тестировать сравнение производительности только что созданного массива с бывшим в использовании?
Я всего лишь заметил и измерил разницу, а так же предложил средство для восстановления максимальных показателей в бенчмарках (пересборка массива с ручным запуском TRIM на каждом накопителе). В других же материалах об этом предпочитают просто умалчивать, как будто никакой разницы и нет вовсе.
> "на диске находится информация" и "на диск недавно записана информация". Разница в GC, причем существенная.
Конечно я не ждал пока GC отработает. Время между запуском бенчмарков не превышало нескольких минут.
1. Были использованы бенчмарки, тестирующие как с очередью, так и без. Чтобы кадый мог выбрать то, что ему важнее/нужнее.
2а. Размер stripe выбирался на основе трех HDD-подтестов из PCMark05. Последних из них (Virus Scan) зависит в том числе и от нагрузки на CPU. Конечно эта нагрузка тоже оценивалась, но даже со stripe=4К дисковые операции не создавали существенной нагрузки на разогнанный Core i7-2600K. А даже если бы и создавали, я бы предпочел разогнать процессор еще сильнее (например, до стабильных на воздухе 5.0-5.1 ГГц), вместо того, чтобы пожертвовать показателями в бенчмарках, используя больший размер stripe. Я не утверждаю, что всем и на любых конфигурация надо использовать именно 8К, но свой выбор обосновал приведенными в материале цифрами.
2б. По ресурсу я уже высказал свое мнение в одном из прошлых обзоров: "Трех лет гарантии вполне достаточно, чтобы не боятся преждевременного выхода из строя накопителя. За это время наверняка выйдет что-то новое и еще более быстрое, а проблема исчерпания ресурсов пускай волнует тех, кто покупает "железо" на вторичном рынке."
По остальному - но ведь показатели в бенчмарках все равно выше с небольшим stripe, значить и все перечисленные проблемы (множество запросов, проблемы с буфферизацией чтения и отложенной записью) наверное не столь критичны.
3. Это дефолтные настройки ATTO. При выборе любых других результаты станет невозможно сравнивать с множеством других, доступных в сети и полученных так же на дефолтных настройках.
В RST включал только write back cache, кэширование чтения не менял.
4. "Провалы" по чтению были видны во всех бенчмарках. Для наглядности я привел в качестве примера скрины только из тех, которые могут строить график. Получаетя что все они "возвращают дурь"? А чем тогда тестировать сравнение производительности только что созданного массива с бывшим в использовании?
Я всего лишь заметил и измерил разницу, а так же предложил средство для восстановления максимальных показателей в бенчмарках (пересборка массива с ручным запуском TRIM на каждом накопителе). В других же материалах об этом предпочитают просто умалчивать, как будто никакой разницы и нет вовсе.
> "на диске находится информация" и "на диск недавно записана информация". Разница в GC, причем существенная.
Конечно я не ждал пока GC отработает. Время между запуском бенчмарков не превышало нескольких минут.
#4
Отправлено 17 Январь 2012 - 19:46
"Для наглядности я привел в качестве примера скрины только из тех, которые могут строить график. Получаетя что все они "возвращают дурь"? А чем тогда тестировать сравнение производительности только что созданного массива с бывшим в использовании?"
Так, вторая попытка.
В SSD есть транслятор(обобщенное понятие), который ставит в соответствие логический номер сектора, видимый во вне, и физический номер сектора в микросхемах Flash.
Если информация в диске есть, т.е. в диск записали данные, то транслятор устанавливает соответствие и контроллер выполняет вычитывание и преобразование (декомпрессию) данных. На вычитывание и декомпрессию требуются 'усилия' (время и процессорная мощность).
Если информации на диске нет (чистый диск или использовался TRIM), то транслятор возвращает FALSE и контроллер НИЧЕГО НЕ ДЕЛАЕТ. Он, как-бы, не сможет ничего сделать, отсутствуют целевые сектора Flash.
В результате, если в диске данные есть, то тест покажет (какую-то) скорость чтения. Если данные в запрошенных секторах отсутствуют, то программа вернет скорость ковыряния в носу контроллера и интерфейса передачи данных, т.е. дурь. Эта дурь имеет такую-же полезную нагрузку, как режим burst для обычных HDD. (т.е. 'понятно')
"А чем тогда"? - я видел много тестов, и не скажу, что они мне нравятся. И чем больше смотрю, тем больше не нравятся.
Практически все тесты написаны и ориентированы на HDD, а SSD - это совсем другое, совершенно другое.
По остальному - аргументы я привел, они серьезные.
Так, вторая попытка.
В SSD есть транслятор(обобщенное понятие), который ставит в соответствие логический номер сектора, видимый во вне, и физический номер сектора в микросхемах Flash.
Если информация в диске есть, т.е. в диск записали данные, то транслятор устанавливает соответствие и контроллер выполняет вычитывание и преобразование (декомпрессию) данных. На вычитывание и декомпрессию требуются 'усилия' (время и процессорная мощность).
Если информации на диске нет (чистый диск или использовался TRIM), то транслятор возвращает FALSE и контроллер НИЧЕГО НЕ ДЕЛАЕТ. Он, как-бы, не сможет ничего сделать, отсутствуют целевые сектора Flash.
В результате, если в диске данные есть, то тест покажет (какую-то) скорость чтения. Если данные в запрошенных секторах отсутствуют, то программа вернет скорость ковыряния в носу контроллера и интерфейса передачи данных, т.е. дурь. Эта дурь имеет такую-же полезную нагрузку, как режим burst для обычных HDD. (т.е. 'понятно')
"А чем тогда"? - я видел много тестов, и не скажу, что они мне нравятся. И чем больше смотрю, тем больше не нравятся.
Практически все тесты написаны и ориентированы на HDD, а SSD - это совсем другое, совершенно другое.
По остальному - аргументы я привел, они серьезные.
Поделиться темой:
Страница 1 из 1