forum.opennet.ru - "OpenNews: Оценка зависимости производительности MySQL от нас..." (9)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"OpenNews: Оценка зависимости производительности MySQL от нас..."

Форумы Разговоры, обсуждение новостей (Public)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"OpenNews: Оценка зависимости производительности MySQL от нас..."
Сообщение от opennews (ok) on 18-Мрт-08, 19:52
"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.../ Новость: https://www.opennet.ru/opennews/art.shtml?num=14811
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

Оценка зависимости производительности MySQL от настроек аппа..., Konwin, 19:52 , 18-Мрт-08, (1)
Оценка зависимости производительности MySQL от настроек аппа..., Аноним, 23:35 , 18-Мрт-08, (2)

Оценка зависимости производительности MySQL от настроек аппа..., Konwin, 23:56 , 18-Мрт-08, (3)

Оценка зависимости производительности MySQL от настроек аппа..., Wulf, 01:19 , 19-Мрт-08, (4)

Оценка зависимости производительности MySQL от настроек аппа..., Konwin, 09:14 , 19-Мрт-08, (5)

Оценка зависимости производительности MySQL от настроек аппа..., Wulf, 10:27 , 19-Мрт-08, (6)

Оценка зависимости производительности MySQL от настроек аппа..., Konwin, 10:45 , 19-Мрт-08, (8)

Оценка зависимости производительности MySQL от настроек аппа..., Wulf, 11:56 , 19-Мрт-08, (9)

Оценка зависимости производительности MySQL от настроек аппа..., serg1224, 10:41 , 19-Мрт-08, (7)

Сообщения по теме [Сортировка по ответам | RSS]

1. "Оценка зависимости производительности MySQL от настроек аппа..."

Сообщение от Konwin (ok) on 18-Мрт-08, 19:52

Статью читать было лень, но, например, авторизованные курсы Оракл утверждают, что 5-й рейд для СУБД - это убийца производительности....

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Оценка зависимости производительности MySQL от настроек аппа..."

Сообщение от Аноним (??) on 18-Мрт-08, 23:35

так мускул это не оракл
вот например для оракла кэш диска -- зло
а для мускула -- добро

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "Оценка зависимости производительности MySQL от настроек аппа..."

Сообщение от Konwin (ok) on 18-Мрт-08, 23:56

>так мускул это не оракл
>вот например для оракла кэш диска -- зло
>а для мускула -- добро
Если на производительности СУБД сказывается весьма немалая вероятность нахождения горячих блоков на одном диске, то это действительно для любой СУБД, использующей диск
И что вы имеет ввиду под злом кэша диска и какой именно кэш вы имеет ввиду?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "Оценка зависимости производительности MySQL от настроек аппа..."

Сообщение от Wulf (??) on 19-Мрт-08, 01:19

> Если на производительности СУБД сказывается весьма немалая вероятность нахождения горячих блоков на одном диске, то это действительно для любой СУБД, использующей диск
Вообще, насколько я понимаю причина того, что 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 будут другие.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "Оценка зависимости производительности MySQL от настроек аппа..."

Сообщение от Konwin (ok) on 19-Мрт-08, 09:14

>[оверквотинг удален]
>ведется небольшими порциями, то получается низкая производительность.
>
>Кстати, вывод в этой статье простой: если взять хороший RAID, который умеет
>распараллеливать запросы на чтение по дискам и имеет write-back кэш с
>батарейкой, то на read-mostly нагрузке (большинство запросов на запись смогут попасть
>в кэш и длительность fsync() будет стремится к нулю) базы могут
>показывать великолепное быстродействие. mysql в составе LAMP-а на web-сайтах обычно и
>характеризуется такой read-mostly нагрузкой, т.е. применение RAID5 там может быть вполне
>обосновано. В комментариях советают даже отключать в контроллере кэш на чтение
>чтобы увеличить эффективность кэша записи.
Немного поправлю.
По 5-му рейду - избыточные данные пишутся не на один дополнительный диск, а на каждый, иначе невозможно обеспечить возможность потери хотя бы одного диска.
По СУБД - причина в том, что никакой контроллер не в курсе, что за данные вы пишете или читаете. Поэтому есть довольно высокая вероятность, что, например, при объединении таблиц может возникнуть ситуация, что запрашиваемые таблицы находятся на одном диске, т.е. распараллелить чтение невозможно. В зеркале или в стрип + зеркало возможно параллельное чтение соединяемых таблиц, или даже разных частей одной и той таблицы, что повысит производительность.
П.С. Оракл я упоминал исключительно из соображений, что он мне ближе к делу.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "Оценка зависимости производительности MySQL от настроек аппа..."

Сообщение от Wulf (??) on 19-Мрт-08, 10:27

>Немного поправлю.
>По 5-му рейду - избыточные данные пишутся не на один дополнительный диск,
>а на каждый, иначе невозможно обеспечить возможность потери хотя бы одного
>диска.
на один. учите матчасть. n-1 диск пишется как RAID0. на избыточный диск пишется сложенная по XOR информация с остальных. Другое дело, что в отличии от RAID4, избыточная информация периодически смещается по дискам чтобы равномерно "размазать" дополнительную нагрузку на ее поддержание в актуальном состоянии.
>По СУБД - причина в том, что никакой контроллер не в курсе,
>что за данные вы пишете или читаете. Поэтому есть довольно высокая
>вероятность, что, например, при объединении таблиц может возникнуть ситуация, что запрашиваемые
>таблицы находятся на одном диске, т.е. распараллелить чтение невозможно. В зеркале
>или в стрип + зеркало возможно параллельное чтение соединяемых таблиц, или
>даже разных частей одной и той таблицы, что повысит производительность.
автор статьи тестил в 64 параллельных потока. при одном потоке у него получалось медленно.
>П.С. Оракл я упоминал исключительно из соображений, что он мне ближе к
>делу.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

7. "Оценка зависимости производительности MySQL от настроек аппа..."

Сообщение от serg1224 (ok) on 19-Мрт-08, 10:41

>Кстати, вывод в этой статье простой: если взять хороший RAID, который умеет
>распараллеливать запросы на чтение по дискам и имеет write-back кэш с
>батарейкой, то на read-mostly нагрузке (большинство запросов на запись смогут попасть
>в кэш и длительность fsync() будет стремится к нулю) базы могут
>показывать великолепное быстродействие.
Это не "хороший", это нормальный RAID-контроллер, а не какое-нибудь фуфло типа Promise.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

8. "Оценка зависимости производительности MySQL от настроек аппа..."

Сообщение от Konwin (ok) on 19-Мрт-08, 10:45

>на один. учите матчасть. n-1 диск пишется как RAID0. на избыточный диск
>пишется сложенная по XOR информация с остальных. Другое дело, что в
>отличии от RAID4, избыточная информация периодически смещается по дискам чтобы равномерно
>"размазать" дополнительную нагрузку на ее поддержание в актуальном состоянии.
Мат часть надо учить не мне - в 5-м рейде информация о контрольной сумме записывается на все диски, а не на один. На один пишется в рейде уровня 3 и 4.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

9. "Оценка зависимости производительности MySQL от настроек аппа..."

Сообщение от Wulf (??) on 19-Мрт-08, 11:56

>>на один. учите матчасть. n-1 диск пишется как RAID0. на избыточный диск
>>пишется сложенная по XOR информация с остальных. Другое дело, что в
>>отличии от RAID4, избыточная информация периодически смещается по дискам чтобы равномерно
>>"размазать" дополнительную нагрузку на ее поддержание в актуальном состоянии.
>Мат часть надо учить не мне - в 5-м рейде информация о контрольной сумме записывается на все диски, а не на один. На один пишется в рейде уровня 3 и 4.
Если вы записываете в RAID5 информацию размером в 1 блок, то избыточность вам надо поправить только на 1-м диске а не на всех. но раcпределение этого 1-го блока с избыточностью по дискам в пределах RAID5 массива непостоянно, поэтому и говорят, что "информация о контрольной сумме записывается на все диски".

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	1. "Оценка зависимости производительности MySQL от настроек аппа..."
	Сообщение от Konwin (ok) on 18-Мрт-08, 19:52
	Статью читать было лень, но, например, авторизованные курсы Оракл утверждают, что 5-й рейд для СУБД - это убийца производительности....
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	2. "Оценка зависимости производительности MySQL от настроек аппа..."
	Сообщение от Аноним (??) on 18-Мрт-08, 23:35
	так мускул это не оракл вот например для оракла кэш диска -- зло а для мускула -- добро
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	3. "Оценка зависимости производительности MySQL от настроек аппа..."
	Сообщение от Konwin (ok) on 18-Мрт-08, 23:56
	>так мускул это не оракл >вот например для оракла кэш диска -- зло >а для мускула -- добро Если на производительности СУБД сказывается весьма немалая вероятность нахождения горячих блоков на одном диске, то это действительно для любой СУБД, использующей диск И что вы имеет ввиду под злом кэша диска и какой именно кэш вы имеет ввиду?
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	4. "Оценка зависимости производительности MySQL от настроек аппа..."
	Сообщение от Wulf (??) on 19-Мрт-08, 01:19
	> Если на производительности СУБД сказывается весьма немалая вероятность нахождения горячих блоков на одном диске, то это действительно для любой СУБД, использующей диск Вообще, насколько я понимаю причина того, что 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 будут другие.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	5. "Оценка зависимости производительности MySQL от настроек аппа..."
	Сообщение от Konwin (ok) on 19-Мрт-08, 09:14
	>[оверквотинг удален] >ведется небольшими порциями, то получается низкая производительность. > >Кстати, вывод в этой статье простой: если взять хороший RAID, который умеет >распараллеливать запросы на чтение по дискам и имеет write-back кэш с >батарейкой, то на read-mostly нагрузке (большинство запросов на запись смогут попасть >в кэш и длительность fsync() будет стремится к нулю) базы могут >показывать великолепное быстродействие. mysql в составе LAMP-а на web-сайтах обычно и >характеризуется такой read-mostly нагрузкой, т.е. применение RAID5 там может быть вполне >обосновано. В комментариях советают даже отключать в контроллере кэш на чтение >чтобы увеличить эффективность кэша записи. Немного поправлю. По 5-му рейду - избыточные данные пишутся не на один дополнительный диск, а на каждый, иначе невозможно обеспечить возможность потери хотя бы одного диска. По СУБД - причина в том, что никакой контроллер не в курсе, что за данные вы пишете или читаете. Поэтому есть довольно высокая вероятность, что, например, при объединении таблиц может возникнуть ситуация, что запрашиваемые таблицы находятся на одном диске, т.е. распараллелить чтение невозможно. В зеркале или в стрип + зеркало возможно параллельное чтение соединяемых таблиц, или даже разных частей одной и той таблицы, что повысит производительность. П.С. Оракл я упоминал исключительно из соображений, что он мне ближе к делу.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	6. "Оценка зависимости производительности MySQL от настроек аппа..."
	Сообщение от Wulf (??) on 19-Мрт-08, 10:27
	>Немного поправлю. >По 5-му рейду - избыточные данные пишутся не на один дополнительный диск, >а на каждый, иначе невозможно обеспечить возможность потери хотя бы одного >диска. на один. учите матчасть. n-1 диск пишется как RAID0. на избыточный диск пишется сложенная по XOR информация с остальных. Другое дело, что в отличии от RAID4, избыточная информация периодически смещается по дискам чтобы равномерно "размазать" дополнительную нагрузку на ее поддержание в актуальном состоянии. >По СУБД - причина в том, что никакой контроллер не в курсе, >что за данные вы пишете или читаете. Поэтому есть довольно высокая >вероятность, что, например, при объединении таблиц может возникнуть ситуация, что запрашиваемые >таблицы находятся на одном диске, т.е. распараллелить чтение невозможно. В зеркале >или в стрип + зеркало возможно параллельное чтение соединяемых таблиц, или >даже разных частей одной и той таблицы, что повысит производительность. автор статьи тестил в 64 параллельных потока. при одном потоке у него получалось медленно. >П.С. Оракл я упоминал исключительно из соображений, что он мне ближе к >делу.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	7. "Оценка зависимости производительности MySQL от настроек аппа..."
	Сообщение от serg1224 (ok) on 19-Мрт-08, 10:41
	>Кстати, вывод в этой статье простой: если взять хороший RAID, который умеет >распараллеливать запросы на чтение по дискам и имеет write-back кэш с >батарейкой, то на read-mostly нагрузке (большинство запросов на запись смогут попасть >в кэш и длительность fsync() будет стремится к нулю) базы могут >показывать великолепное быстродействие. Это не "хороший", это нормальный RAID-контроллер, а не какое-нибудь фуфло типа Promise.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	8. "Оценка зависимости производительности MySQL от настроек аппа..."
	Сообщение от Konwin (ok) on 19-Мрт-08, 10:45
	>на один. учите матчасть. n-1 диск пишется как RAID0. на избыточный диск >пишется сложенная по XOR информация с остальных. Другое дело, что в >отличии от RAID4, избыточная информация периодически смещается по дискам чтобы равномерно >"размазать" дополнительную нагрузку на ее поддержание в актуальном состоянии. Мат часть надо учить не мне - в 5-м рейде информация о контрольной сумме записывается на все диски, а не на один. На один пишется в рейде уровня 3 и 4.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	9. "Оценка зависимости производительности MySQL от настроек аппа..."
	Сообщение от Wulf (??) on 19-Мрт-08, 11:56
	>>на один. учите матчасть. n-1 диск пишется как RAID0. на избыточный диск >>пишется сложенная по XOR информация с остальных. Другое дело, что в >>отличии от RAID4, избыточная информация периодически смещается по дискам чтобы равномерно >>"размазать" дополнительную нагрузку на ее поддержание в актуальном состоянии. >Мат часть надо учить не мне - в 5-м рейде информация о контрольной сумме записывается на все диски, а не на один. На один пишется в рейде уровня 3 и 4. Если вы записываете в RAID5 информацию размером в 1 блок, то избыточность вам надо поправить только на 1-м диске а не на всех. но раcпределение этого 1-го блока с избыточностью по дискам в пределах RAID5 массива непостоянно, поэтому и говорят, что "информация о контрольной сумме записывается на все диски".
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору

Архив \| Удалить	Индекс форумов \| Темы \| Пред. тема \| След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 \| 2 \| 3 \| 4 \| 5 ] [Рекомендовать для помещения в FAQ]