The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Тестирование SSD Intel x25m в Linux

08.01.2010 14:10

Проведено тестирование производительности твердотельного диска (Solid State Disk) Intel X25-m G1. Тестирование проводилось при помощи утилиты iozone, на системе с Linux ядром 2.6.31.6 и Файловой системой ext3 с параметрами по умолчанию. Для уменьшения влияния планировщика ввода-вывода на результаты тестирование проводилось в режиме с elevator=noop. Для отключения файловых кешей Linux использовались опции "iozone -o -I". Эти опции приводят к установке флагов O_SYNC и O_DIRECT при открытии файлов

Показана зависимость скорости чтения-записи от размера файла и размера запрашиваемого блока. Так же продемонстрирована зависимость скорости работы диска от количества одновременно запущенных процессов. Результаты тестирования демонстрируют основные преимущества твердотельных накопителей в сравнении с традицонными HDD.

  1. Главная ссылка к новости (http://www.setupc.ru/wiki/moin...)
Автор новости: aospan
Тип: яз. русский / Обобщение
Короткая ссылка: https://opennet.ru/24935-ssd
Ключевые слова: ssd, flash, benchmark, disk
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (39) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, XoRe (ok), 15:02, 08/01/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Очень интересно, спасибо за статью.
    Форониксу есть на кого равняться)
     
     
  • 2.2, _Vitaly_ (ok), 15:19, 08/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    http://www.anandtech.com/storage/

    IMHO там более полные и понятные выкладки.

     
     
  • 3.4, XoRe (ok), 15:45, 08/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >http://www.anandtech.com/storage/
    >
    >IMHO там более полные и понятные выкладки.

    Буду рад увидеть тут новость с сылкой на статью оттуда)

     
     
  • 4.7, anonymous (??), 19:03, 08/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем? Синтетические тесты в стиле фороникса, только под офтопик.
    немного приправленоа маркетинговым булщитом.
    После тестов должны быть видны достоинства и недостатки.
    если недостатков нет, то это тупая заказуха.
     
     
  • 5.27, XoRe (ok), 20:00, 09/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >А зачем? Синтетические тесты в стиле фороникса, только под офтопик.
    >немного приправленоа маркетинговым булщитом.
    >После тестов должны быть видны достоинства и недостатки.
    >если недостатков нет, то это тупая заказуха.

    Если честно, я даже не смотрел на эти "Kbytes/sec".
    Я смотрел на зависимость скорости от размера блока данных, от размера копируемого файла, от количества одновременных процессов.
    Именно от этих параметров зависит скорость работы приложений, работающих с файлами.

    Но не все это понимают.
    Например, судя по статье, разница между блоком в 4кб и 128кб различается в разы.
    Что это означает на практике?
    Это значит, что  можно увеличить быстродействие какой-то системы на десятки или сотни процентов, прописав оптимальные значения.
    Без затрат средств на обновление аппаратного обеспечения.

    А "Kbytes/sec" - это да, это сферично.
    Если быстродействие упирается именно в этот показатель, тут только менять дисковую подсистему.

     
  • 4.18, _Vitaly_ (ok), 01:19, 09/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Больше месяца прошло. Это уже какой-то некропостинг получится :)

    Видимо, не все знают про anandtech, вот и изобретают SSD-велосипеды.

     
     
  • 5.26, XoRe (ok), 19:35, 09/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Больше месяца прошло. Это уже какой-то некропостинг получится :)
    >
    >Видимо, не все знают про anandtech, вот и изобретают SSD-велосипеды.

    Согласен.
    Я вот про этот сайт не знал.
    Буду рад увидеть тут новости про интересные и полезные статьи оттуда)

     

  • 1.3, Аноним (-), 15:34, 08/01/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    быстрее чем на винде. круто
     
     
  • 2.6, аноним (?), 18:49, 08/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Чего в этом удивительного?
     

  • 1.5, pavlinux (ok), 17:23, 08/01/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ура Ultra320SCSI Рулит, 93 Mb/sec на запись!!!

    Интересно другое...

    > max UDMA/133

    А скорость на чтение в тесте 240Mb/sec., чёй-то неувязочка...

     
     
  • 2.8, anonymous (??), 19:07, 08/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >А скорость на чтение в тесте 240Mb/sec., чёй-то неувязочка...

    SATA-II 3Gbps где неувязка?
    в диагноститеском сообщении драйвера, что он может общаться с девайсом ata командами?


     
     
  • 3.9, pavlinux (ok), 19:44, 08/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>А скорость на чтение в тесте 240Mb/sec., чёй-то неувязочка...
    >
    >SATA-II 3Gbps где неувязка?
    >в диагноститеском сообщении драйвера, что он может общаться с девайсом ata командами?
    >

    SATA link up 3.0 Gbps - рекламная фишка, ПиаР, понты, дайте денег, мы крутые как яйцы бобра...

    Во первых там БИТ/сек., как в сетевушке, т.е. в 8 раз меньше - 3e9/8 = 375 Mb/sec.
    Во вторых, это скорость на проводе, - между чипсетом и контроллером на диске.
    По обе стороны провода идут кодирование, ECC, latency и прочие полезные фишки.  
    Далее идут добавки от чипсетов, оператифки, и наконец, добивает всё OСь.
    Планировщики ввода/вывода, планировщики задач, сискалы... и т.п.
    За счёт больших кэшей, можно добиться реальных 50% скорости, от рекламных.
    За счёт рисования бенчмарков, можно добиться реальных 75% скорости, от рекламных.

    В реальности 10-15% при записи, ну и до 40% на чтение.
    Бенчмарки дело третье... из этого бенча http://www.setupc.ru/wiki/moin.cgi/ssd_test_x25m?action=AttachFile&do=get&tar
    random read везде быстрее :), 1 из 2-х - либо пиз...т, либо random number generator плохой.

     
     
  • 4.10, Аноним (-), 20:57, 08/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Если не секрет - что идёт лишнего "от чипсетов, оператифки" по SATA шине ? ECC идёт отдельно от кодирования ? Что добивает ОСь ? Что вы курили когда писали этот пост ?
     
  • 4.11, pro100master (ok), 21:00, 08/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >SATA link up 3.0 Gbps - рекламная фишка, ПиаР, понты, дайте денег, мы крутые как яйцы >бобра...
    >Во первых там БИТ/сек., как в сетевушке, т.е. в 8 раз меньше - 3e9/8 = 375 Mb/sec.
    >Во вторых, это скорость на проводе, - между чипсетом и контроллером на диске.
    >По обе стороны провода идут кодирование, ECC, latency и прочие полезные фишки.  
    >Далее идут добавки от чипсетов, оператифки, и наконец, добивает всё OСь.

    глупости вы пишите. На той же самой сетевухе, маркированной 1ГБ, вы этот ГигаБит и получите. Не верите? Отключите qos udp, icmp и проверьте :))) И нет там никаких наводок видимых. Маркировка даётся уже с учетом всех "наводок", "latency и прочие полезные фишки".

    По теме. Согласен, что цифры бесполезные. Почему? Честно? Ну да, на сервер самое милое дело ssd врубить, чтобы через 3 месяца в субботу вечером внезапно клиенты начали звонить - место кончилось :)))

     
     
  • 5.15, pavlinux (ok), 00:41, 09/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Маркировка даётся уже с учетом всех "наводок", "latency и прочие полезные фишки".

    Ага ага... :)
    Маркировка даётся с учётом стандартов.
    Многие сетевухи на 10/100 давно уже умеют и 130Mb и 160Mb,
    гигабитный Интел может 1.12Gb, а Noname RTL8169 еле 750 поднимает, попадаются на оборот...

    >
    > Ну да, на сервер самое милое дело ssd врубить, чтобы через 3 месяца в субботу
    >вечером внезапно клиенты начали звонить - место кончилось :)))

    Их туда врубают для кэшей, свопов, $TMPDIR, и прочего часто обновляющесяго...  


     
     
  • 6.39, ABorland (?), 06:24, 19/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    хотел бы я посмотреть на сервер у которого каталог /tmp на ssd
    и как он через год зависнет по причине исчерпания ресурса перезаписываний
     
  • 4.12, User294 (ok), 21:46, 08/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Во первых там БИТ/сек., как в сетевушке, т.е. в 8 раз меньше -

    Эпик фэйл! Вот уж от кого не ожидал... oO. Павлин, а ты про кодирование 8 к 10 в SATA интерфейсе никогда не слышал? Хорошо бы услышать было, при том - *до* проведения столь кульных вычислений :P.

     
     
  • 5.16, pavlinux (ok), 00:46, 09/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> Во первых там БИТ/сек., как в сетевушке, т.е. в 8 раз меньше -
    >
    >Эпик фэйл! Вот уж от кого не ожидал... oO. Павлин, а ты
    >про кодирование 8 к 10 в SATA

    Не в 8 к 10, а 8B/10B... что не легче, значит SATA быстрый модем :) -  8 бит данных, 1 чётность., 1 стоповый.  

     
     
  • 6.30, Aleksey Salow (ok), 07:02, 10/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Во первых там БИТ/сек., как в сетевушке, т.е. в 8 раз меньше -
    >>
    >>Эпик фэйл! Вот уж от кого не ожидал... oO. Павлин, а ты
    >>про кодирование 8 к 10 в SATA
    >
    >Не в 8 к 10, а 8B/10B... что не легче, значит SATA
    >быстрый модем :) -  8 бит данных, 1 чётность., 1
    >стоповый.

    Мне вот интересно, это только я один догадался в википедию заглянуть и почитать что собой представляет 8b/10b кодирование?

    http://en.wikipedia.org/wiki/8b/10b_encoding

    PS павлинух - мимо утки.
    PPS  Lindemidux  - тоже мимо

     
     
  • 7.34, pavlinux (ok), 15:22, 10/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >>>про кодирование 8 к 10 в SATA
    >>
    >>Не в 8 к 10, а 8B/10B... что не легче, значит SATA
    >>быстрый модем :) -  8 бит данных, 1 чётность., 1
    >>стоповый.
    >
    >Мне вот интересно, это только я один догадался в википедию заглянуть и
    >почитать что собой представляет 8b/10b кодирование?
    >http://en.wikipedia.org/wiki/8b/10b_encoding
    >

    Ну и чё ты выпиндрился...
    Мы эти кодирования ещё в децком саду проходили, Википедии тогда не было, по "Теории информации"
    И ваще, задолбали своей Википедией, у самих мозг остался?!

    Не, коль такой вумный, нарисуй закодированую строку из 4 байт

      8B
    11111111    -
    10101010    -
    10100111    -
    11001101    -

    А таком виде - ~|________|~, где: "_|~" - малый потенциал, пусть будет 0, "~|_" - 1,

     
     
  • 8.35, Aleksey Salow (ok), 16:56, 10/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Остынь павлинух Мы тоже проходили, и что с этого Просто если я пишу что-то в ч... текст свёрнут, показать
     
  • 4.22, Lindemidux (??), 15:49, 09/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ути-пути толстенький, читай спецификацию SATA, там 2 бита служебных специально для этих целей.
     
     
  • 5.23, pavlinux (ok), 16:46, 09/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Ути-пути толстенький, читай спецификацию SATA, там 2 бита служебных специально для этих
    >целей.

    Так по проводу они всё равно летают, от чипсета до диска?!

     
     
  • 6.24, User294 (ok), 16:57, 09/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Так по проводу они всё равно летают, от чипсета до диска?!

    Павлин, не тормози, 2 лишних бита - именно для передачи по проводу и есть.

     
  • 4.29, Aleksey Salow (ok), 06:54, 10/01/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >SATA link up 3.0 Gbps - рекламная фишка, ПиаР, понты, дайте денег,
    >мы крутые как яйцы бобра...

    Иногда лучше жевать.

    >Во первых там БИТ/сек., как в сетевушке, т.е. в 8 раз меньше
    >- 3e9/8 = 375 Mb/sec.

    Вообще-то в 10. В sata пользуют 8b/10b кодирование

    >Во вторых, это скорость на проводе, - между чипсетом и контроллером на
    >диске.

    Угу.

    >По обе стороны провода идут кодирование, ECC, latency и прочие полезные фишки.

    Там синхронный канал, так что latency там фиксировано и никакой роли при потоковой передаче не играет. ecc там нет вроде как (его не было в pata, и тут скорее всего нет).

    >Далее идут добавки от чипсетов, оператифки, и наконец, добивает всё OСь.

    Вы почитайте что такое dma и bus master. Посчитайте сколько ваша оперативка пропустить через себя может. Мелочи это всё.

    >Планировщики ввода/вывода, планировщики задач, сискалы... и т.п.

    Он такой тормознутый?

     
  • 2.13, User294 (ok), 21:49, 08/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> max UDMA/133
    >А скорость на чтение в тесте 240Mb/sec., чёй-то неувязочка...

    Думаешь, это сообщение в данном случае несет глубокий физический смысл? А я думал глубокий физический смысл - в 3GBps линке, сырая скорость которого 300Мбайт в секунду...


     
     
  • 3.17, pavlinux (ok), 00:51, 09/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>> max UDMA/133
    >>А скорость на чтение в тесте 240Mb/sec., чёй-то неувязочка...
    >
    >Думаешь, это сообщение в данном случае несет глубокий физический смысл? А я
    >думал глубокий физический смысл - в 3GBps линке, сырая скорость которого
    >300Мбайт в секунду...

    Хоть сырая, хоть мокрая .... ну не будет девайс писать 120Gb SQL базу или 5 BR-ROM со скоростью 300Mb/s, хоть ты пукни...
    Такие скорости у 15000 rpm SAS на на оптике...


      

     
     
  • 4.25, User294 (ok), 17:01, 09/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Хоть сырая, хоть мокрая .... ну не будет девайс писать 120Gb SQL
    >базу или 5 BR-ROM со скоростью 300Mb/s, хоть ты пукни...

    А где там скорость в 300Мб/с была? Это скорость (сферического) потока (в вакууме) со всеми командами, максимальная из того что возможно в теории по этому интерфейсу. Ессно в реальном случае будет куча оверхеда и реальная скорость будет 200 с чем-то. При условии что девайс со своей стороны не тормозит.

    >Такие скорости у 15000 rpm SAS на на оптике...

    Ты хочешь сказать что у них скорость записи на блины выше 300 мегов в секунду у в случае SAS с обычным SATAшным физическим уровнем упирается именно в него а не в тормознутую механику? Тем более что если твой 15000 RPMовый не дай боже заложит пару seek'ов - ждать придется МИЛЛИСЕКУНДЫ на каждый seek. Как и в старые добрые времена. Ну механика же. А вот флеш - знаешь, адрес куда запись происходит сменить это не физические головы в другой конец диска загнать. Да и при чтении такая же байда. Отсюда и потенциальный выигрыш.

     
     
  • 5.28, pavlinux (ok), 20:37, 09/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Ты хочешь сказать что у них скорость записи на блины выше 300 мегов

    Это ты сказать хочешь, а мне на интерфейс насрать, но если прикалывает

    FC SAS = 4Gb/s, SAS-II = 6Gb/s, FC SAS-II 8Gb/s - см. Qlogic 2560

    А реальная скорость записи у FC SAS диска 105Mb/s
    На чтение да, уже проигрывают ... со счётом 1:2


    > Отсюда и потенциальный выигрыш.

    Где выигрыш? Йопнулся что ля ... 60 Mb/s на запись????
    У мня дома старый ASC 29320A и Maxtor Atlas II на 15k,  и то даёт
    93 Mb/s WRITE
    84 Mb/s RANDOM WRITE

     
     
  • 6.36, User294 (ok), 21:30, 10/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Это ты сказать хочешь, а мне на интерфейс насрать, но если прикалывает
    > FC SAS = 4Gb/s, SAS-II = 6Gb/s, FC SAS-II 8Gb/s -
    >см. Qlogic 2560

    Это гигаБиты? А то SATA с 6Гбит уже на подходе.

    >А реальная скорость записи у FC SAS диска 105Mb/s

    А что, 105 мб/сек считается чем-то крутым? Столько нынче SOHOвские диски выжимают. У 15 000 rpm основной выигрыш в времени seek, в общем то. Как бы чем быстрее диски крутятся тем быстрее после загона головы в нужное место нужный сектор под ней пролетит.

    >Где выигрыш?

    При нагрузке с большой фрагментацией?

    >Йопнулся что ля ... 60 Mb/s на запись????
    >У мня дома старый ASC 29320A и Maxtor Atlas II на 15k,
    > и то даёт
    >93 Mb/s WRITE
    >84 Mb/s RANDOM WRITE

    Заставь диски гонять головы туда-сюда соответствующей нагрузкой и посмотри что останется от этих мегов в секунду :).Чудес не бывает - механический прогон голов тудаю-сюда время требует, а у флешатины гонять нечего, адрес сменить быстро. А запись у флеша тоормзная, ты как к ней избирательно прикопался, да? Разумеется, если нагрузка с интненсивной записью, не очень фрагментированная и в большом объеме - лучше флеш не юзать. А то еще и протрется чего доброго до дыр - циклов перезаписи оно выдерживает не так уж и много :)

     

  • 1.14, rstone (??), 21:54, 08/01/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В версии G1 вроде TRIM  не поддерживался .
    Вопрос к автору : со временем нет ухудшения  в скорости записи ?

     
     
  • 2.20, aospan (?), 12:22, 09/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Да, в G1 нету TRIM ... постараюсь в ближайшее время погонять G2.

    За скоростью понаблюдаю в процессе эксплуатации. Пока только тесты гонял ... :)

     

  • 1.19, ua9oas (?), 07:17, 09/01/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
      Интересно, а как результаты тестов этой вещи будут отличаться, если ядро и файловая система будут использоваться более новые? А то ведь и ext4 достаточно давно существует и ядро 2.6.32 и даже релизы 2.6.33 разные во всю уже существуют и я читал, что все это имеет немало усовершенствований (прогресс) по сравнению с тем, что тут приведено
     
     
  • 2.21, aospan (?), 12:26, 09/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ок, попробую с более новым ядром. Теоретически ничего не должно поменяться - в тесте влияние ядра сведено к минимуму, да и показанные результаты очень близки к заявленным производителем ( 250 МБ/сек на чтение и 70 МБ/сек на запись ).
     

  • 1.31, rstone (??), 11:23, 10/01/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    SSDSA2SH064G1GC ( X25E , Kingston OEM , 64G  )  , FW 8790
    RANDOM READ TESTS .

    10 Files ( 1 GB each) and 10 reading processes
    CFQ          20046 KBps
    Deadline     49169 KBps

    4 Files ( 1 GB each) and 4  reading processes
    CFQ       48966 KBps
    Deadline      50697 KBps

    1 FILE ( 50 GB ) and one reader process
    CFQ         78849 KBps
    Deadline 79203 KBps

    Centos 5.2 , iosched/fifobatch set to 1 .

     
     
  • 2.32, rstone (??), 11:27, 10/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >SSDSA2SH064G1GC ( X25E , Kingston OEM , 64G  )  ,
    >FW 8790
    >RANDOM READ TESTS .

    record size = 50 kb , ( специфика нашей аппликации )  


     
  • 2.33, aospan (?), 12:18, 10/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Похоже не быстро даже для "record size = 50 kb", хотя x25e вроде как более "продвинутый" относительно x25m. По моим графикам при таком размере блока скорость "random read" около 120 МБ/сек.

    Поглядите, может NCQ отключен (dmesg | grep NCQ) ? Без NCQ скорость чтения заметно падает ( наблюдаю падение с 250 МБ/сек до 180 МБ/сек т.е. примерно -30% ).

     

  • 1.37, edo (ok), 10:08, 12/01/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    я неправильно читаю график или действительно для блоков размером менее 128кб/с random write намного быстре sequential write?
     
     
  • 2.38, aospan (?), 12:35, 12/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    да, так и есть. объясняется это скорее всего тем, что при записи контроллер может писать только блоками по 128 КБ (или более). При этом при последовательной записи если в блоке уже есть данные, то контроллеру необходимо их считать, добавить к ним новые данные и записать обратно.

    При рандомной записи таких ситуаций возникает меньше т.к. есть вероятность, что часть данных будет записана в блок размером 128КБ один раз.

     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру