А если взять один и тот же дорогой и новый контроллер и сравнить на нем скорость записи на raid5 и raid1? ;)
Нервно курит - это, знаете ли, не технический параметр.
Поверьте, хотя бы на слово, нам есть, и что сравнивать, и с чем сравнивать, мы в стоянии подготовить разные стэнды для проверок и сравнений тех или иных технологий.
Cab081 добавил 09.04.2009 в 17:29
Dlag, вот еще к слову" избыточность", я хотел бы обратить ваше внимание на слово "секвенция", и подумать, можно или нельзя его использовать со словом "параллельно".
чтение старого блока и его четности
download.intel.com/design/storage/papers/30094601.pdf
здесь хорошая обрисовка в картинке.
Поясняю - это не "4 операции записи", это "4 обращения к дискам", как у меня и написано, будьте, пожалуйста, внимательнее.
4 просто операции = 2 операции чтения + 2 операции записи
А я разве не упомянул write-back?
Пенальти на одну блочную write операцию на raid5 это 4 обращения к дискам - 2 чтения и 2 записи. Ну, заставьте меня думать, что это быстрее, чем секвенция в 2 записи на raid1.
Cab081 добавил 09.04.2009 в 17:00
Относительно наполнения наших серверов - у компании есть лицензия, компания придерживается законодательства РФ и собственных установленных правил, и про себя могу сказать, что обратного опыта не имею.
По поводу raid3 - он устарел, и я очень давно не видел контроллеров, которые его позволяют.
То, что RAID5 медленнее на запись, чем RAID1, я всегда считал фактом, подтвержденным и логикой, и практикой, честно говоря, удивлен, что мне придется это доказывать.
Программные реализации raid для VDS мы не используем, конечно же, иронию оценил.
Уважаемый, zzeus, слово "инженер" пишется через букву "е", с Вашего позволения.
Любое описание raid'ов 3/5/6 укажет Вам на performance penalty при операциях на запись.
И "пузомерки" это подтверждают. И , кроме того, любой инжЕнер укажет Вам на частое несоответствие показаний "пузомерок" и "реальной" работы. Симуляция нагрузки это вообще отдельная общирная тема, которую тоже можно затронуть.
Cab081 добавил 09.04.2009 в 16:27
Избыточность это свойство RAID, более того это первое слово в аббревиатуре RAID, на избытычности построены все прелести и недостатки RAID'ов. Что Вас так смутило?
Господа, я не претендую на божественную истину. Готов выслушать любые замечания и признать ошибки, безусловно, готов указать и на ваши ошибки, но прошу вас излагаться в более корректной форме.
Добрый день, господа, я инженер компании SpaceWeb, это мои комментарии транслировались сюда, так что, замечания относительно непонимания raid'ов и некоторые другие адресованы мне.
С удовольствием по мере возможности поучаствую в технической дискуссии непосредственно.
Значит, мысль была следующая.
Dlag, то, что Вы называете "растасовкой", в семантике raid называется избыточностью. Цена этой избыточности - множественные обращения к диску, особенно на запись, сложная математика по вычислениям контрольных сумм(которую, правда, на себя берет cpu контроллера) и постоянная работа с дисками для отслеживания корректности контрольных сумм. Общепринято, что использование сложных raid массивов на больших адресных пространствах дает приемущество на чтениях, и снижает скорость на запись(это частично компенсируется функционалом write-back), но современные большие дисковые кэши и эффективное кэширование в ядре ОС приемущества делают сомнительными, сохраняя при этом недостатки сложным raid схем.
Наш парк серверов содержит самые разные конфигурации серверов, мы используем и raid3/5/6, но стараемся придерживаться принципа разумного и достаточного.
Что касается свопа на отдельном диске/raid1/3/5/6/whatever и нагрузки на диски. Операции ввода-ввывода не происходят без участия CPU, ограничение на CPU очевидным образом создает ограничение на операции ввода-вывода. А вот при наличии сложных raid схем мы частично операции на работу с дисковой системой отдаем на откуп raid-контроллера и в некотором смысле не в состоянии ее контролировать. Планировщик в Xen ставит в "правильную" завимость работы и сети и блочных операций от виртуального CPU. В общем смысле это есть в обычной системе, но с случае с Xen'ом это вполне наглядно демонстрируется. LineHost выразил похожую мысль, но сослался на выделенный объем памяти - этого я не заметил.
И повторюсь про своп - мы не хотим поощрять использование свопа у клиентов, так как не существует "быстрого" свопа, своп всегда медленный, колеса от феррари не делают гужевую повозку сильно быстрее. Если система начинает активно свопить и тормозить - уверен, сами прекрасно знаете, - это значит, что неплохо бы добавить памяти, а не купить себе диск побыстрее.
