GD Star Rating
loading...
loading...
Насколько актуальная данная пикча? Хотел бы послушать мнения признанных экспертов про SSD вообще
Новости IT
- В 2015 году Kodak планируют запустить собственную линейку смартфонов на базе Android
- Xiaomi стали третьим крупнейшим производителем смартфонов в мире
- Во время конференции Google I/O поисковой гигант может продемонстрировать приставку Android TV
- Intel не выпустят процессоры следующего поколения Broadwell до начала 2015 года
- Google хотят унифицировать дизайн мобильных приложений с помощью новой программы “Quantum Paper”
- 18 июня Amazon могут представить свой первый 3D смартфон
- Transcend анонсировали дополнительные карты памяти JetDrive Lite для MacBook Air и Retina MacBook Pro
- Samsung считают, что судебные иски Apple должны быть нацелены не на их компанию, а на Google
- Epson представили второе поколение своих умных очков на базе ОС Android – Moverio BT-200
- Lenovo выпустили свои первые 279-долларовые Chromebook, ориентированные на потребительский рынок
Последние опубликованные
- Насколько реально вернуть домен уведенный сквоттером?
- Как у Вас дела обстоят с документацией, её структурированием и хранением?
- Градации web-разработчика в Украине,
- строки по baseline
- новая или вторая видеокарта ?
- psd макет для wordpress
- Помогите с SSL
- Как мне постить с приложения в Действия?
- сколько может стоить подобный ?
- Online консультант
- трехмерная модель челюсти
- box-shadow и Opera
- Request limit exceeded (64), referer:
- Парни, а чем вы вдски админите?
- Выбор роутера
Последние прочитанные
На больших объемах справедливо. То есть кино дешевле с рейда смотреть.
Но по причине значительно более шустрого рандомного доступа ссд оголтело нагибают при работе с горой мелких файлов. Так что в зависимости для каких целей использовать.
фигня. В линейном чтении большого файла пара винтов может и обгонят дешевый SSD, хотя до того же Vertex 3 им один фиг никогда не подняться, в любых вариантах. Но как только затрагиваются более мелкие файлы и сегментация, винты сосали, сосут и сосать будут.
Кстати, бенчмарк по сути говно, раз так криво скорость высчитывает. Даже виндовс и тот разницу видит.
чего вон с этим, например не сравнили? он тоже около 4-5 тысяч стоит. Справа там циферки есть, очень говорящие. Да и собственно на этом сайте у Vertex3 стоит 2820 очков.
жуткая фигня. Во-первых сравнили непонятно какой древности SSD и это не говоря о его характеристиках.
Во-вторых, даже этот говняный SSD в реальном компе будет работать быстрее чем два HDD в RAID, потому как вся суть SSD не в скорости записи/чтения, а в скорости доступа.
да..как написал блогер выше попробуй сравнить HDD в RAID с Vertex3
картинка недоумком сделана 😉 сначала он сравнивает линейную скорость, а потом пишет про кеш браузера, который ничего общего с этим не имеет.
и “гемор по отключению дефрагментации” – сейчас винда при установке на ССД сама выключает всё что нужно.
не слушай дебилов, вкратце. под систему – всегда ссд
под хранение кино – и без рейдов хватит любого харда.
Отвечу на вопросы про IOPS у любых носителей, типы RAID и их отличия, объясню как считать IOPS на запись и чтение в любом типе RIAD.
Бесплатно, АКЦИЯ!
Ко всему сказанному предыдущими ораторами добавлю, что надо быть хз кем, чтобы в 2011 брать за полторы тысячи сигейт на 80гб десятой серии.
Ну и, конечно фиг его знает вообще, что там этот Disk Mark меряет.
ок
HP p212 FW v3.3 + 3 x HP по 146 10K SAS в RAID5
Какая должна быть скорость рандомного чтения блоками по 8/16 байт?
килобайт естественно
Посчитать это не так уж и сложно, даже без учёта затрат времени на передвижение головок – в среднем надо будет ждать полоборота, пока под винчестером не окажется нужный кусок данных, полоборота – 3мс, получаем ~333 блока в секунду, или, для 4КБ-блоков – 1.33МБ/с. Это оценка сверху, выше этой скорости никак не прыгнуть (если не учитывать NCQ), да и она недостижима, потому что на сдвиг головок, обработку запросов и прочую хрень тоже уходит какое-то время.
А насчёт
1) Теоретически, с зеркальным рейдом скорость могла бы быть в пару раз выше, за счёт распараллеливания операций чтения. А может оказаться и медленнее в полтора раза за счёт того, что один и тот же блок надо считать с двух дисков (для проверки целостности данных), а у разных дисков может быть разная геометрия (т.е. при случайном чтении на дорожках разница между углами предыдущего считанного и следующего считанного блоков на одном винчестере может оказаться, например, 1/4 оборота, а на другом – 3/4 оборота, в результате общее время ожидания будет 3/4 оборота).
2) По тем же причинам, на raid5 может присутствовать аналогичное падение производительности – в зависимости от количества дисков в массиве, задержка для чтения каждого блока будет стремиться к целому обороту.
есть формулы для расчета максмального числа 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. Боюсь, что версии фирвари чего-бы то ни было к нашему разговору не применимы.
какая-то ерунда, не знаю откуда взято то, что вы написали.
1) При чтении НИКОГДА не читаются два блока, чтобы их сравнить. Более того – даже если у вас зеркало, тогда грамотные RAID в два раза ускоряют чтение. Упрощенно – читают с одного диска четные, а с другого нечетные блоки. А вы все перевернулись с точностью наоборот – с ног на голову. И никто не оперируе оборотвами и временами подлета головок, это излишне.
2) тут вообще не понял – ерунда какая-то.
> При чтении НИКОГДА не читаются два блока, чтобы их сравнить
Так я же говорю – теоретически 🙂
> даже если у вас зеркало, тогда грамотные RAID в два раза ускоряют чтение. Упрощенно — читают с одного диска четные, а с другого нечетные блоки
Так я и написал, что могла бы быть в пару раз выше. Это всё теоретические измышления, дополнение к основному комментарию 🙂
> тут вообще не понял — ерунда какая–то.
Ну если у нас параноидальный контроллер, то логично, что для чтения одного блока с RAID5 массива надо считать блок чётности, в создании которого он участвовал, плюс все блоки, участвовавшие в создании этого блока чётности. При линейном чтении это особой роли не играет, а при случайном – придётся ждать, пока не подлетит нужное место дорожки на каждом винчестере, и, с увеличением количества винчестеров, среднее время ожидания будет стремиться к одному обороту.
Но опять же, это всё теоретически, а на самом деле контроллеры, может быть, и не делают параноидальные.
> И никто не оперируе оборотвами и временами подлета головок, это излишне.
Тем не менее, ваши числа из справочника (известно, что 15K–диск SAS/SCSI/FC дает порядка 240 IOPS, 10K — 180 IOPS, 7.2K SATA — 75 IOPS) не сильно отличаются от моих посчитанных по оборотам (15к оборотов в минуту – 250 оборотов в секунду; в идеале, без учёта времени подлёта головок, получаем в среднем 2/1000 секунды на блок – а с учётом времени подлёта головок, возможно, как раз и выйдет в среднем ~4/1000 секунды на блок).
Кстати, уж к записи-то мои теоретические измышления точно применимы, потому что и в зеркале, и в raid5 для записи блока надо записать по блоку на каждый винчестер в массиве.
так есть формулы расчета, да и они не нужны – т.к. есть четкие данные, полученные опытным путем.
1) просто “может оказаться медленней” – неверно. Т.к. НИКОГДА не читается два блока для сравнения. Каждый уникальный блок читается лишь с одного диска;
2) про RAID5 что-то у тебя какая-то ерундистика. Чтобы считать один байт с RAID5 нужно просто считать ОДИН блок в составе которого есть этот байт. И ВСЕ. Никаких “для чтения одного блока с RAID5 массива надо считать блок чётности, в создании которого он участвовал, плюс все блоки, участвовавшие в создании этого блока чётности“.
Про подлеты головок, про seek и латентность рекомендую забыть – т.к. мы уже оперируем имеющимся числом IOPS на каждый диск. А то получается, что мы разговариваем о том, как делать майонез и оперируем не лимонной кислотой и желтками с солью, а молекулярной этих веществ.
“уж к записи–то мои теоретические измышления точно применимы, потому что и в зеркале, и в raid5 для записи блока надо записать по блоку на каждый винчестер в массиве” – не хочу расстраивать, но ты неправильно представляешь себе работу RAID. Все намного сложнее и совсем не так (:
Для записи 1 байта на RAID10 нужно записать этот байт в нужный блок на один из дисков и на его зеркальную копию (вне зависимости от кол-ва дисков в RAID).
Для записи 1 байта на RAID5 нужно прочитать нужный блок с диска и блок с контрольной суммой с другого диска. После чего записать обратно на один из дисков блок данных (с этим одним новым байтом), а на другой диск – контрольную сумму (вне зависимости от кол-ва дисков в RAID).
> Для записи 1 байта на RAID5 нужно прочитать нужный блок с диска и блок с контрольной суммой с другого диска. После чего записать обратно на один из дисков блок данных (с этим одним новым байтом), а на другой диск — контрольную сумму (вне зависимости от кол–ва дисков в RAID).
Да, это уже я ступил. Но моя исходная, неверная оценка (считать по блоку параллельно с N дисков) даже оказалась оптимистичной по сравнению с реальностью (считать по блоку параллельно с 2 дисков, затем записать по блоку параллельно на 2 диска; при этом, записать обычный блок мы можем раньше чтения контрольного, но записать контрольный – только после чтения и обычного, и контрольного). Учитывая то, что блины на месте не стоят – вроде бы, получается, что на запись уйдёт в среднем 1.75 оборота.
> Т.к. НИКОГДА не читается два блока для сравнения. Каждый уникальный блок читается лишь с одного диска;
Так это ведь уже детали реализации – может быть, используются где-то параноидальные контроллеры, где зеркальность нужна не только для защиты от падения винчестера, но и для защиты от искажения данных на винчестере. А может быть, и не используются.
> про RAID5 что–то у тебя какая–то ерундистика
Так это опять же для гипотетических параноидальных контроллеров в вакууме 🙂
> А то получается, что мы разговариваем о том, как делать майонез и оперируем не лимонной кислотой и желтками с солью, а молекулярной этих веществ.
Вы ответили человеку, каких результатов стоит ожидать в реальности, я объяснил, выше каких результатов и почему нельзя подняться даже в теории, оба подхода интересны 🙂
Ну и, кстати, это сразу объясняет, почему флэш-диски быстрее. Потому что у того, что последние тридцать лет называют винчестерами (а заодно и у дискет, и у оптических дисков) – есть блины, которые крутятся на постоянной (по понятным причинам вращение нельзя приостановить в нужный момент) и не такой уж высокой скоростью. Отсюда сразу берётся ограничение снизу на время доступа, ограничение сверху на IOPS, и становится понятно, почему же SSD рулят, а винчестеры так рулить никогда не смогут, хоть ты тресни.
длинная у вас получилась полемика
я указал, что 3 диска в 5ом RAID
мне надо прикинуть рандомное чтение 8 и 16К блоков, вернее какой потолок можно выжать
По проверенным практикой данным от6zer0 – 135 операций в секунду на запись, или, для 8КБ-блоков – около 1МБ/с. Хотя есть подозрение, что6zer0 не учёл, что запись на RAID5 – дело более затратное (как он потом расписал), чем на простой одиночный винчестер.
По моим теоретическим измышлениям – выше, чем 333 случайных операции в секунду на чтение (для 8КБ-блоков – около 2.5МБ/с) и 100 случайных операций в секунду на запись (для 8КБ-блоков – около 800КБ/с) в принципе не получится выжать из идеи хранения данных на цилиндрических дорожках блинов, вращающихся со скоростью 10крпм. В реальной жизни всё будет ещё немного хуже.
Но главное..
ТИ
ШИ
НА
мерялось IO-meter
была производительность в районе 0.7-2МБ/с на почти забитом диске
после некоторых танцев 120МБ/c, но это на пустом диске, невозможно предсказать падение скорости в зависимости от забитого объема
> после некоторых танцев 120МБ/c,
Эээ, так ты про случайный доступ спрашиваешь или про прямое чтение?
Вся соль всех этих писькомерок с маленькими блоками – что считываем случайный маленький блок, потом ещё один случайный, потом ещё один…
А считать блок, потом следующий, потом следующий – тут особого ума не надо, и это от размеров блоков особо не зависит.
> но это на пустом диске, невозможно предсказать падение скорости в зависимости от забитого объема
Если мы говорим об измерении скорости работы винчестера, то нет таких понятий, как пустота и забитость. На винчестере хранятся нолики и единички; и совершенно всё равно, что там эти нолики-единички означают.
Так что то ли ты меряешь вообще не скорость винчестера, а не пойми что; то ли на “почти забитом диске” параллельно с программой для измерения у тебя ещё какие-то приложения активно пользовались диском.
опять же! НИКОМУ НЕ НУЖНЫ обороты, ни-ко-му!
Мы считаем нагрузку на подсистему очень просто – берем, например 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.
Вот так сайзятся дисковые подсистемы, расчет упрощенный, но вполне точный.
тут мы сталкиваемся с паттернами работы. Самый сложный паттер для RIAD – рандомная запись мелкими блоками. Самый простой – последовательное чтение.
Теперь по размеру блока: при маленьких блоках мы упираемся в IOPS (блины крутятся, головки бегают – число операций ограничено механически), при больших (к примеру последовательно чтение мегабайтным блоком) в пропускную способность интерфейса диска, его кэша и пр.
Что сделать сайзинг системы нужно знать:
1. Нагрузку – требуемые IOPS на чтение и IOPS на запись и размер блока;
2. Какой тип RAID хочется использовать (тут все зависит от многих факторах, могу их привести).
Дальше мы считаем нужное число дисков, все.
Ну только исходный вопрос от Lgoev не о том был 🙂
в общем пиздит безбожно этот IOmeter,
но судя по ораклу присрост таки есть, раза в 3
единички/нолики и рандомное/последовательно – это понятно
про забитость я говорил относительно того, что рандомное чтение будет происходить дальше от центра диска физически, а как это все в 5ом рейде по блинам размазано не понятно
> но судя по ораклу присрост таки есть, раза в 3
Прирост от удаления всей инфы с диска?
Ну и после дефрагментации такой же прирост будет. Оракл-то случайно работает не со всем диском, а только с той частью, где лежат его данные. Если на сильно фрагментированном разделе эти данные были равномерно размазаны по всему винчестеру, то после дефрагментации (или форматирования и установки минимально необходимого набора заново) они будут локализованы уже в более-менее узкой области, а это значит – и головки сдвигать на меньшее расстояние, и в кэше чаще будут оказываться нужные данные.
> в общем пиздит безбожно этот IOmeter,
Если 120МБ/с взято из IOmeter – то почему же пиздит? Просто, судя по всему, замеряет скорость линейного чтения.
>>Просто, судя по всему, замеряет скорость линейного чтения.
да нет стояло random 100%
>>после дефрагментации такой прирост будет
ну как вариант
> да нет стояло random 100%
Ну может тогда из кэша данные подтягивались, или хз.
120МБ/с – как раз где-то в этом районе (100-150) линейная скорость чтения у домашних (7200) винчестеров последние несколько лет.