GD Star Rating
loading...

Насколько актуальная данная пикча? Хотел бы послушать мнения признанных экспертов про SSD вообще

Hardblog.net - linux nix windows Image #1203563, 714.2 KB

Tagged with →  

34 Responses to Насколько актуальная данная пикча?

  1. VeDoc:

    На больших объемах справедливо. То есть кино дешевле с рейда смотреть.
    Но по причине значительно более шустрого рандомного доступа ссд оголтело нагибают при работе с горой мелких файлов. Так что в зависимости для каких целей использовать.

  2. ниMr:

    фигня. В линейном чтении большого файла пара винтов может и обгонят дешевый SSD, хотя до того же Vertex 3 им один фиг никогда не подняться, в любых вариантах. Но как только затрагиваются более мелкие файлы и сегментация, винты сосали, сосут и сосать будут.
    Кстати, бенчмарк по сути говно, раз так криво скорость высчитывает. Даже виндовс и тот разницу видит.

  3. ниMr:

    чего вон с этим, например не сравнили? он тоже около 4-5 тысяч стоит. Справа там циферки есть, очень говорящие. Да и собственно на этом сайте у Vertex3 стоит 2820 очков.

  4. LlBlack:

    жуткая фигня. Во-первых сравнили непонятно какой древности SSD и это не говоря о его характеристиках.
    Во-вторых, даже этот говняный SSD в реальном компе будет работать быстрее чем два HDD в RAID, потому как вся суть SSD не в скорости записи/чтения, а в скорости доступа.

    да..как написал блогер выше попробуй сравнить HDD в RAID с Vertex3

  5. NuMar:

    картинка недоумком сделана 😉 сначала он сравнивает линейную скорость, а потом пишет про кеш браузера, который ничего общего с этим не имеет.
    и “гемор по отключению дефрагментации” – сейчас винда при установке на ССД сама выключает всё что нужно.

    не слушай дебилов, вкратце. под систему – всегда ссд
    под хранение кино – и без рейдов хватит любого харда.

  6. 6zer0:

    Отвечу на вопросы про IOPS у любых носителей, типы RAID и их отличия, объясню как считать IOPS на запись и чтение в любом типе RIAD.

    Бесплатно, АКЦИЯ!

  7. UPzer0:

    Ко всему сказанному предыдущими ораторами добавлю, что надо быть хз кем, чтобы в 2011 брать за полторы тысячи сигейт на 80гб десятой серии.
    Ну и, конечно фиг его знает вообще, что там этот Disk Mark меряет.

  8. Lgoev:

    ок

    HP p212 FW v3.3 + 3 x HP по 146 10K SAS в RAID5
    Какая должна быть скорость рандомного чтения блоками по 8/16 байт?

  9. Lgoev:

    килобайт естественно

  10. UPzer0:

    Посчитать это не так уж и сложно, даже без учёта затрат времени на передвижение головок – в среднем надо будет ждать полоборота, пока под винчестером не окажется нужный кусок данных, полоборота – 3мс, получаем ~333 блока в секунду, или, для 4КБ-блоков – 1.33МБ/с. Это оценка сверху, выше этой скорости никак не прыгнуть (если не учитывать NCQ), да и она недостижима, потому что на сдвиг головок, обработку запросов и прочую хрень тоже уходит какое-то время.

  11. UPzer0:

    А насчёт
    1) Теоретически, с зеркальным рейдом скорость могла бы быть в пару раз выше, за счёт распараллеливания операций чтения. А может оказаться и медленнее в полтора раза за счёт того, что один и тот же блок надо считать с двух дисков (для проверки целостности данных), а у разных дисков может быть разная геометрия (т.е. при случайном чтении на дорожках разница между углами предыдущего считанного и следующего считанного блоков на одном винчестере может оказаться, например, 1/4 оборота, а на другом – 3/4 оборота, в результате общее время ожидания будет 3/4 оборота).
    2) По тем же причинам, на raid5 может присутствовать аналогичное падение производительности – в зависимости от количества дисков в массиве, задержка для чтения каждого блока будет стремиться к целому обороту.

  12. 6zer0:

    есть формулы для расчета максмального числа IOPS на диск, но нам они не понадобятся, т.к. известно, что 15K-диск SAS/SCSI/FC дает порядка 240 IOPS, 10K – 180 IOPS, 7.2K SATA – 75 IOPS. Вы указали, что у вас ТРИ диска, но не указали какой там RAID (уровень), а это критически важно для расчета IOPS.

    При этом не следует забывать, что в расчет лучше закладывать нагрузку на диск в размере ~75% его максимальных возможностей.

    Теперь по скорости обмена – почему-то многие этого не понимают или как-то мешают мягкое с теплым. Дисковая подсистема характеризуется скоростью информационного обмена по двум параметрам – по IOPS (число операций/сек.) и bandwidth (пропускная способность в байтах/сек). Обычно bandwidth нас мало волнует, т.к. работа абсолютного большинства систем требует множественных мелких операций.

    К примеру, если ваши три диска 10K слеплены в RAID5 – то на чистой системы (без учета кэшей и прочего – а именно так сайзятся дисковые подсистемы) вы не получите более 180*3/4 = 135 IOPS на запись.

    P.S. Боюсь, что версии фирвари чего-бы то ни было к нашему разговору не применимы.

  13. 6zer0:

    какая-то ерунда, не знаю откуда взято то, что вы написали.

    1) При чтении НИКОГДА не читаются два блока, чтобы их сравнить. Более того – даже если у вас зеркало, тогда грамотные RAID в два раза ускоряют чтение. Упрощенно – читают с одного диска четные, а с другого нечетные блоки. А вы все перевернулись с точностью наоборот – с ног на голову. И никто не оперируе оборотвами и временами подлета головок, это излишне.

    2) тут вообще не понял – ерунда какая-то.

  14. UPzer0:

    > При чтении НИКОГДА не читаются два блока, чтобы их сравнить

    Так я же говорю – теоретически 🙂

    > даже если у вас зеркало, тогда грамотные RAID в два раза ускоряют чтение. Упрощенно — читают с одного диска четные, а с другого нечетные блоки

    Так я и написал, что могла бы быть в пару раз выше. Это всё теоретические измышления, дополнение к основному комментарию 🙂

    > тут вообще не понял — ерунда какая–то.

    Ну если у нас параноидальный контроллер, то логично, что для чтения одного блока с RAID5 массива надо считать блок чётности, в создании которого он участвовал, плюс все блоки, участвовавшие в создании этого блока чётности. При линейном чтении это особой роли не играет, а при случайном – придётся ждать, пока не подлетит нужное место дорожки на каждом винчестере, и, с увеличением количества винчестеров, среднее время ожидания будет стремиться к одному обороту.
    Но опять же, это всё теоретически, а на самом деле контроллеры, может быть, и не делают параноидальные.

  15. UPzer0:

    > И никто не оперируе оборотвами и временами подлета головок, это излишне.

    Тем не менее, ваши числа из справочника (известно, что 15K–диск SAS/SCSI/FC дает порядка 240 IOPS, 10K — 180 IOPS, 7.2K SATA — 75 IOPS) не сильно отличаются от моих посчитанных по оборотам (15к оборотов в минуту – 250 оборотов в секунду; в идеале, без учёта времени подлёта головок, получаем в среднем 2/1000 секунды на блок – а с учётом времени подлёта головок, возможно, как раз и выйдет в среднем ~4/1000 секунды на блок).

  16. UPzer0:

    Кстати, уж к записи-то мои теоретические измышления точно применимы, потому что и в зеркале, и в raid5 для записи блока надо записать по блоку на каждый винчестер в массиве.

  17. 6zer0:

    так есть формулы расчета, да и они не нужны – т.к. есть четкие данные, полученные опытным путем.

  18. 6zer0:

    1) просто “может оказаться медленней” – неверно. Т.к. НИКОГДА не читается два блока для сравнения. Каждый уникальный блок читается лишь с одного диска;

    2) про RAID5 что-то у тебя какая-то ерундистика. Чтобы считать один байт с RAID5 нужно просто считать ОДИН блок в составе которого есть этот байт. И ВСЕ. Никаких “для чтения одного блока с RAID5 массива надо считать блок чётности, в создании которого он участвовал, плюс все блоки, участвовавшие в создании этого блока чётности“.

    Про подлеты головок, про seek и латентность рекомендую забыть – т.к. мы уже оперируем имеющимся числом IOPS на каждый диск. А то получается, что мы разговариваем о том, как делать майонез и оперируем не лимонной кислотой и желтками с солью, а молекулярной этих веществ.

  19. 6zer0:

    уж к записи–то мои теоретические измышления точно применимы, потому что и в зеркале, и в raid5 для записи блока надо записать по блоку на каждый винчестер в массиве” – не хочу расстраивать, но ты неправильно представляешь себе работу RAID. Все намного сложнее и совсем не так (:

    Для записи 1 байта на RAID10 нужно записать этот байт в нужный блок на один из дисков и на его зеркальную копию (вне зависимости от кол-ва дисков в RAID).

    Для записи 1 байта на RAID5 нужно прочитать нужный блок с диска и блок с контрольной суммой с другого диска. После чего записать обратно на один из дисков блок данных (с этим одним новым байтом), а на другой диск – контрольную сумму (вне зависимости от кол-ва дисков в RAID).

  20. UPzer0:

    > Для записи 1 байта на RAID5 нужно прочитать нужный блок с диска и блок с контрольной суммой с другого диска. После чего записать обратно на один из дисков блок данных (с этим одним новым байтом), а на другой диск — контрольную сумму (вне зависимости от кол–ва дисков в RAID).

    Да, это уже я ступил. Но моя исходная, неверная оценка (считать по блоку параллельно с N дисков) даже оказалась оптимистичной по сравнению с реальностью (считать по блоку параллельно с 2 дисков, затем записать по блоку параллельно на 2 диска; при этом, записать обычный блок мы можем раньше чтения контрольного, но записать контрольный – только после чтения и обычного, и контрольного). Учитывая то, что блины на месте не стоят – вроде бы, получается, что на запись уйдёт в среднем 1.75 оборота.

  21. UPzer0:

    > Т.к. НИКОГДА не читается два блока для сравнения. Каждый уникальный блок читается лишь с одного диска;

    Так это ведь уже детали реализации – может быть, используются где-то параноидальные контроллеры, где зеркальность нужна не только для защиты от падения винчестера, но и для защиты от искажения данных на винчестере. А может быть, и не используются.

    > про RAID5 что–то у тебя какая–то ерундистика

    Так это опять же для гипотетических параноидальных контроллеров в вакууме 🙂

    > А то получается, что мы разговариваем о том, как делать майонез и оперируем не лимонной кислотой и желтками с солью, а молекулярной этих веществ.

    Вы ответили человеку, каких результатов стоит ожидать в реальности, я объяснил, выше каких результатов и почему нельзя подняться даже в теории, оба подхода интересны 🙂

  22. UPzer0:

    Ну и, кстати, это сразу объясняет, почему флэш-диски быстрее. Потому что у того, что последние тридцать лет называют винчестерами (а заодно и у дискет, и у оптических дисков) – есть блины, которые крутятся на постоянной (по понятным причинам вращение нельзя приостановить в нужный момент) и не такой уж высокой скоростью. Отсюда сразу берётся ограничение снизу на время доступа, ограничение сверху на IOPS, и становится понятно, почему же SSD рулят, а винчестеры так рулить никогда не смогут, хоть ты тресни.

  23. Lgoev:

    длинная у вас получилась полемика

    я указал, что 3 диска в 5ом RAID

    мне надо прикинуть рандомное чтение 8 и 16К блоков, вернее какой потолок можно выжать

  24. UPzer0:

    По проверенным практикой данным от6zer0 – 135 операций в секунду на запись, или, для 8КБ-блоков – около 1МБ/с. Хотя есть подозрение, что6zer0 не учёл, что запись на RAID5 – дело более затратное (как он потом расписал), чем на простой одиночный винчестер.
    По моим теоретическим измышлениям – выше, чем 333 случайных операции в секунду на чтение (для 8КБ-блоков – около 2.5МБ/с) и 100 случайных операций в секунду на запись (для 8КБ-блоков – около 800КБ/с) в принципе не получится выжать из идеи хранения данных на цилиндрических дорожках блинов, вращающихся со скоростью 10крпм. В реальной жизни всё будет ещё немного хуже.

  25. YrGreen:

    Но главное..
    ТИ
    ШИ
    НА

  26. Lgoev:

    мерялось IO-meter
    была производительность в районе 0.7-2МБ/с на почти забитом диске
    после некоторых танцев 120МБ/c, но это на пустом диске, невозможно предсказать падение скорости в зависимости от забитого объема

  27. UPzer0:

    > после некоторых танцев 120МБ/c,

    Эээ, так ты про случайный доступ спрашиваешь или про прямое чтение?
    Вся соль всех этих писькомерок с маленькими блоками – что считываем случайный маленький блок, потом ещё один случайный, потом ещё один…
    А считать блок, потом следующий, потом следующий – тут особого ума не надо, и это от размеров блоков особо не зависит.

    > но это на пустом диске, невозможно предсказать падение скорости в зависимости от забитого объема

    Если мы говорим об измерении скорости работы винчестера, то нет таких понятий, как пустота и забитость. На винчестере хранятся нолики и единички; и совершенно всё равно, что там эти нолики-единички означают.
    Так что то ли ты меряешь вообще не скорость винчестера, а не пойми что; то ли на “почти забитом диске” параллельно с программой для измерения у тебя ещё какие-то приложения активно пользовались диском.

  28. 6zer0:

    опять же! НИКОМУ НЕ НУЖНЫ обороты, ни-ко-му!

    Мы считаем нагрузку на подсистему очень просто – берем, например 100 heavy-юзеров Outlook с 0,8 IOPS на каждого с профилем нагрузки read/write = 60/40 и считаем:

    [1] Нам понадобится всего 800 IOPS, где rd = 480 IOPS и rw = 320 IOPS;
    [2] Выбираем, к примеру, RAID5 – который из-за схемы своей работы (я ее описал здесь) на каждый 1 IOPS записи генерит 4 IOPS;
    [3] Простой арифметикой получаем нужное кол-во 480+4*320=1760 IOPS на дисковую подсистему;
    [4] Выбираем диски SAS 15K с 240 IOPS max, но мы не хотим их грузить выше 75% и предполагаем, что каждый диск должен выполнять не более 240*75%=180 IOPS;
    [5] ИТОГ: в RAID5 нам понадобится 1760/180=~10 дисков 15K.

    Вот так сайзятся дисковые подсистемы, расчет упрощенный, но вполне точный.

  29. 6zer0:

    тут мы сталкиваемся с паттернами работы. Самый сложный паттер для RIAD – рандомная запись мелкими блоками. Самый простой – последовательное чтение.

    Теперь по размеру блока: при маленьких блоках мы упираемся в IOPS (блины крутятся, головки бегают – число операций ограничено механически), при больших (к примеру последовательно чтение мегабайтным блоком) в пропускную способность интерфейса диска, его кэша и пр.

    Что сделать сайзинг системы нужно знать:
    1. Нагрузку – требуемые IOPS на чтение и IOPS на запись и размер блока;
    2. Какой тип RAID хочется использовать (тут все зависит от многих факторах, могу их привести).

    Дальше мы считаем нужное число дисков, все.

  30. UPzer0:

    Ну только исходный вопрос от Lgoev не о том был 🙂

  31. Lgoev:

    в общем пиздит безбожно этот IOmeter,
    но судя по ораклу присрост таки есть, раза в 3

    единички/нолики и рандомное/последовательно – это понятно

    про забитость я говорил относительно того, что рандомное чтение будет происходить дальше от центра диска физически, а как это все в 5ом рейде по блинам размазано не понятно

  32. UPzer0:

    > но судя по ораклу присрост таки есть, раза в 3

    Прирост от удаления всей инфы с диска?
    Ну и после дефрагментации такой же прирост будет. Оракл-то случайно работает не со всем диском, а только с той частью, где лежат его данные. Если на сильно фрагментированном разделе эти данные были равномерно размазаны по всему винчестеру, то после дефрагментации (или форматирования и установки минимально необходимого набора заново) они будут локализованы уже в более-менее узкой области, а это значит – и головки сдвигать на меньшее расстояние, и в кэше чаще будут оказываться нужные данные.

    > в общем пиздит безбожно этот IOmeter,

    Если 120МБ/с взято из IOmeter – то почему же пиздит? Просто, судя по всему, замеряет скорость линейного чтения.

  33. Lgoev:

    >>Просто, судя по всему, замеряет скорость линейного чтения.
    да нет стояло random 100%

    >>после дефрагментации такой прирост будет
    ну как вариант

  34. UPzer0:

    > да нет стояло random 100%

    Ну может тогда из кэша данные подтягивались, или хз.

    120МБ/с – как раз где-то в этом районе (100-150) линейная скорость чтения у домашних (7200) винчестеров последние несколько лет.

Добавить комментарий