"Evaluating IO subsystem performance for MySQL Needs (http://www.mysqlperformanceblog.com/2008/03/05/evaluating-io.../)" - оценка зависимости производительности MySQL от настроек аппаратного RAID5.URL: http://www.mysqlperformanceblog.com/2008/03/05/evaluating-io.../
Новость: http://www.opennet.me/opennews/art.shtml?num=14811
Статью читать было лень, но, например, авторизованные курсы Оракл утверждают, что 5-й рейд для СУБД - это убийца производительности....
так мускул это не оракл
вот например для оракла кэш диска -- зло
а для мускула -- добро
>так мускул это не оракл
>вот например для оракла кэш диска -- зло
>а для мускула -- доброЕсли на производительности СУБД сказывается весьма немалая вероятность нахождения горячих блоков на одном диске, то это действительно для любой СУБД, использующей диск
И что вы имеет ввиду под злом кэша диска и какой именно кэш вы имеет ввиду?
> Если на производительности СУБД сказывается весьма немалая вероятность нахождения горячих блоков на одном диске, то это действительно для любой СУБД, использующей дискВообще, насколько я понимаю причина того, что RAID5 является database killer-ом является факт, что для записи 1-го байта вам надо прочитать минимум по 1-му блоку с n-1 диска и записать после этого измененные блоки на 2 диска, где n-число дисков в RAID. Это нужно для обновления избыточного диска. а если учесть, что в базах запись и ведется небольшими порциями, то получается низкая производительность.
Кстати, вывод в этой статье простой: если взять хороший RAID, который умеет распараллеливать запросы на чтение по дискам и имеет write-back кэш с батарейкой, то на read-mostly нагрузке (большинство запросов на запись смогут попасть в кэш и длительность fsync() будет стремится к нулю) базы могут показывать великолепное быстродействие. mysql в составе LAMP-а на web-сайтах обычно и характеризуется такой read-mostly нагрузкой, т.е. применение RAID5 там может быть вполне обосновано. В комментариях советают даже отключать в контроллере кэш на чтение чтобы увеличить эффективность кэша записи.
> И что вы имеет ввиду под злом кэша диска и какой именно кэш вы имеет ввиду?
Анонимус, очевидно находится во власти заблуждения, что open source всегда эффективно использует все доступные hardware ресурсы, а проприетарный софт - наоборот :-). Конечно, выводы для mysql-я будут верны и для oracle, только цифры Requests/sec будут другие.
>[оверквотинг удален]
>ведется небольшими порциями, то получается низкая производительность.
>
>Кстати, вывод в этой статье простой: если взять хороший RAID, который умеет
>распараллеливать запросы на чтение по дискам и имеет write-back кэш с
>батарейкой, то на read-mostly нагрузке (большинство запросов на запись смогут попасть
>в кэш и длительность fsync() будет стремится к нулю) базы могут
>показывать великолепное быстродействие. mysql в составе LAMP-а на web-сайтах обычно и
>характеризуется такой read-mostly нагрузкой, т.е. применение RAID5 там может быть вполне
>обосновано. В комментариях советают даже отключать в контроллере кэш на чтение
>чтобы увеличить эффективность кэша записи.Немного поправлю.
По 5-му рейду - избыточные данные пишутся не на один дополнительный диск, а на каждый, иначе невозможно обеспечить возможность потери хотя бы одного диска.По СУБД - причина в том, что никакой контроллер не в курсе, что за данные вы пишете или читаете. Поэтому есть довольно высокая вероятность, что, например, при объединении таблиц может возникнуть ситуация, что запрашиваемые таблицы находятся на одном диске, т.е. распараллелить чтение невозможно. В зеркале или в стрип + зеркало возможно параллельное чтение соединяемых таблиц, или даже разных частей одной и той таблицы, что повысит производительность.
П.С. Оракл я упоминал исключительно из соображений, что он мне ближе к делу.
>Немного поправлю.
>По 5-му рейду - избыточные данные пишутся не на один дополнительный диск,
>а на каждый, иначе невозможно обеспечить возможность потери хотя бы одного
>диска.на один. учите матчасть. n-1 диск пишется как RAID0. на избыточный диск пишется сложенная по XOR информация с остальных. Другое дело, что в отличии от RAID4, избыточная информация периодически смещается по дискам чтобы равномерно "размазать" дополнительную нагрузку на ее поддержание в актуальном состоянии.
>По СУБД - причина в том, что никакой контроллер не в курсе,
>что за данные вы пишете или читаете. Поэтому есть довольно высокая
>вероятность, что, например, при объединении таблиц может возникнуть ситуация, что запрашиваемые
>таблицы находятся на одном диске, т.е. распараллелить чтение невозможно. В зеркале
>или в стрип + зеркало возможно параллельное чтение соединяемых таблиц, или
>даже разных частей одной и той таблицы, что повысит производительность.автор статьи тестил в 64 параллельных потока. при одном потоке у него получалось медленно.
>П.С. Оракл я упоминал исключительно из соображений, что он мне ближе к
>делу.
>на один. учите матчасть. n-1 диск пишется как RAID0. на избыточный диск
>пишется сложенная по XOR информация с остальных. Другое дело, что в
>отличии от RAID4, избыточная информация периодически смещается по дискам чтобы равномерно
>"размазать" дополнительную нагрузку на ее поддержание в актуальном состоянии.Мат часть надо учить не мне - в 5-м рейде информация о контрольной сумме записывается на все диски, а не на один. На один пишется в рейде уровня 3 и 4.
>>на один. учите матчасть. n-1 диск пишется как RAID0. на избыточный диск
>>пишется сложенная по XOR информация с остальных. Другое дело, что в
>>отличии от RAID4, избыточная информация периодически смещается по дискам чтобы равномерно
>>"размазать" дополнительную нагрузку на ее поддержание в актуальном состоянии.
>Мат часть надо учить не мне - в 5-м рейде информация о контрольной сумме записывается на все диски, а не на один. На один пишется в рейде уровня 3 и 4.Если вы записываете в RAID5 информацию размером в 1 блок, то избыточность вам надо поправить только на 1-м диске а не на всех. но раcпределение этого 1-го блока с избыточностью по дискам в пределах RAID5 массива непостоянно, поэтому и говорят, что "информация о контрольной сумме записывается на все диски".
>Кстати, вывод в этой статье простой: если взять хороший RAID, который умеет
>распараллеливать запросы на чтение по дискам и имеет write-back кэш с
>батарейкой, то на read-mostly нагрузке (большинство запросов на запись смогут попасть
>в кэш и длительность fsync() будет стремится к нулю) базы могут
>показывать великолепное быстродействие.Это не "хороший", это нормальный RAID-контроллер, а не какое-нибудь фуфло типа Promise.