Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Гость 123
Guest |
Готовлюсь к сертификации по SQL Server 2000. В документации сказано, что дисковая подсистема сервера перегружена, если значение счётчика "PhysicalDisk: Avg. Disk Queue Length" более чем в 2 раза превышает количество шпинделей жёсткого диска. Возник вопрос - как подсчитать количество шпинделей для различных RAID-массивов? Правильно ли я понимаю: RAID-0 - число шпинделей равно числу дисков в массиве; RAID-1 - число шпинделей равно 1; RAID-10 - число шпинделей равно числу дисков, поделённому на 2; и самый интересный для меня случай - RAID-5 - из числа дисков надо вычесть 1, т.к. на одном диске хранится контрольная сумма? |
31 авг 06, 16:00 [3077748] Ответить | Цитировать Сообщить модератору |
DeColo®es Member Откуда: Москва Сообщений: 5503 Блог |
|
||
31 авг 06, 16:14 [3077839] Ответить | Цитировать Сообщить модератору |
Гость 123
Guest |
Хм. Тогда не могли бы Вы привести пример конфигурации с числом шпинделей больше чем 1? И как тогда понимать такую фразу из BOL: "Most disks have one spindle, although redundant array of inexpensive disks (RAID) devices usually have more."? |
||
31 авг 06, 16:23 [3077912] Ответить | Цитировать Сообщить модератору |
BugsBunny Member Откуда: GMT+5=EST Сообщений: 2414 |
I think you do
? Customers are normally good at identifying processor and memory bottlenecks, but they rarely start a support call with a statement like, “My disk subsystem is a bottleneck.”... |
||||
31 авг 06, 16:26 [3077952] Ответить | Цитировать Сообщить модератору |
WiRuc Member Откуда: Воронеж Сообщений: 1280 |
С чего бы это? Для RAID-0 Disk Queue Length <= Кол-во дисков в рейде * 2, для других типов рейда также можно подсчитать это значение. Но надо помнить, что сам контроллер имеет ограниченное кол-во запросов, которое он может обработать в ед. времени. |
||
31 авг 06, 16:36 [3078051] Ответить | Цитировать Сообщить модератору |
Александр Волок (def1983) Member Откуда: Rotterdam Сообщений: 4959 |
Количество шпинделей - количество физических дисков в данном райд массиве
Райд 10 к примеру. 10 дисков, 10 шпинделей, пороговое значение очереди = 20 |
||
31 авг 06, 16:45 [3078106] Ответить | Цитировать Сообщить модератору |
DeColo®es Member Откуда: Москва Сообщений: 5503 Блог |
Скорее, наоборот - чем больше дисков в массиве, тем он быстрее должен раскидывать очередь! И тем меньше должна быть средняя длина очереди. То есть, сколько бы там дисков не было, если очередь становится больше 2, значит диск (или RAID) УЖЕ не успевает. Конечно, пиковую очередь он раскидает быстро, но запросы не должны толпиться перед таким монстром! Другой вопрос, что в большинстве случаев при росте очереди, bottleneck-ом является не дисковая состема, а архитектура БД. |
||||
31 авг 06, 17:14 [3078312] Ответить | Цитировать Сообщить модератору |
BugsBunny Member Откуда: GMT+5=EST Сообщений: 2414 |
Disk in "Avg.Disk Queue" doesn't mean per one physical disk. As well it doesn't mean "speed". More suitable will be "distance that's needed to be done, if possible -simultaniously"-analogy. So, team of 5 (some RAID) will do 10km in the same time you (single disk) do yours 2. |
||
31 авг 06, 18:03 [3078702] Ответить | Цитировать Сообщить модератору |
Александр Волок (def1983) Member Откуда: Rotterdam Сообщений: 4959 |
По логике, нет, конечно, но не забывайте как microsoft рекомендует вычислять bottleneck. А именно, количество шпинделей * 2. Страйп из 2х дисков, производительность которого в идеале в 2 раза быстрее заркала, например имеет чесные 2 шпинделя. Bottleneck = 2*2=4... Я подозреваю, что ОС значение очереди выявляет не как общую очередь на массиве, а суму очередей на каждом диске массива. Причем, заметьте, что очередь массива может отличаться от сумарной очереди всех дисков в масиве, т.к. очереди в последних уже создает и распределяет контроллер на основании комманд ОС |
||
31 авг 06, 18:13 [3078763] Ответить | Цитировать Сообщить модератору |
DeColo®es Member Откуда: Москва Сообщений: 5503 Блог |
|
||
31 авг 06, 18:14 [3078767] Ответить | Цитировать Сообщить модератору |
DeColo®es Member Откуда: Москва Сообщений: 5503 Блог |
Вполне обоснованное подозрение, что RAID работает быстрее (хотя и не всегда), чем отдельный диск, означает, что он может раскидать более длинную очередь, но никак не то, что он должен её скапливать.
|
||||
31 авг 06, 18:23 [3078814] Ответить | Цитировать Сообщить модератору |
BugsBunny Member Откуда: GMT+5=EST Сообщений: 2414 |
take it easy - _everyone_ makes mistakes time to time. main idea is to learn from them |
||
31 авг 06, 18:23 [3078815] Ответить | Цитировать Сообщить модератору |
WiRuc Member Откуда: Воронеж Сообщений: 1280 |
Вы очень сильно заблуждаетесь:) Дело в том, что Avg.Disk Queue включает в себя и значение Current Disk Queue, т.е. если в Avg. Disk Queue сейчас 2 запроса, то это не значит, что они все сидят в очереди, вполне может быть что они все уже обрабатываются массивом в данный момент. А т.к. RAID может обработать значительно больше, чем одиночный диск, то нормальное значение для Avg. Disk Queue уже становиться равным 2*кол-во дисков в массиве. |
||||
31 авг 06, 18:27 [3078833] Ответить | Цитировать Сообщить модератору |
BugsBunny Member Откуда: GMT+5=EST Сообщений: 2414 |
would you rather stand 3rd in line (british - queue) in small convinience store (one cashier) or be 15th person come to the set of 20(!) all-working cash-registers in superstore? |
31 авг 06, 18:30 [3078851] Ответить | Цитировать Сообщить модератору |
Александр Волок (def1983) Member Откуда: Rotterdam Сообщений: 4959 |
Разве не понятно, что если 20 очередей на одношпиндельном массиве, то это уже более серьезная проблема, чем те же 20 очередей на 10-шпиндельном массиве, т.к. последний расправиться с ними в 10 раз быстрее!! Очереди могут возникнуть на райде любой конфигурации, и чем быстрее они будут выполнены, тем выше общее быстродействие. |
||
31 авг 06, 19:03 [3078985] Ответить | Цитировать Сообщить модератору |
DeColo®es Member Откуда: Москва Сообщений: 5503 Блог |
Любая очередь длиной больше 2-х проказывает, что накопитель является узким местом - пока он пытается выполнить один запрос, к нему приходит второй. Если там хоть 100 дисков, но очередь выросла до 10, надо что-то делать - система УЖЕ загружена. 10 запросов УЖЕ ЖДУТ освобождения ресурса. Ресурс ЗАНЯТ. Сервер уперся именно в него, а не куда-то еще. А то, что носитель ГИПОТЕТИЧЕСКИ быстрее - в данном случае просто очередь в 100 раз меньше, чем МОГЛА БЫ БЫТЬ на 1 шпинделе. Вопрос не в конфигурировании новой системы, а в определении слабых мест СУЩЕСТВУЮЩЕЙ. |
1 сен 06, 10:08 [3080283] Ответить | Цитировать Сообщить модератору |
Александр Волок (def1983) Member Откуда: Rotterdam Сообщений: 4959 |
2DeColo®es У Вас есть опыт работы с базами > 100 гигабайт, корзинами больше 10 дисков?
Да и откуда такие суждения? Очередь может появится в следствие недостаточного объема ОЗУ, неоптимальных индексов, неоптимального дизайна БД в конце концов. Надеюсь Вы хоть BOL 2005 доверяете Monitoring Disk Usage
|
||||
1 сен 06, 10:28 [3080427] Ответить | Цитировать Сообщить модератору |
DeColo®es Member Откуда: Москва Сообщений: 5503 Блог |
Правильно. Просто все это "уперлось" в дисковую систему, которая не справляется с нагрузкой.
|
||||
1 сен 06, 10:50 [3080589] Ответить | Цитировать Сообщить модератору |
Александр Волок (def1983) Member Откуда: Rotterdam Сообщений: 4959 |
Слушайте, я не вижу смысл дальнейшей дискусии, желаю удачи Вам, карьерного и проф. роста ;) |
||||||
1 сен 06, 10:58 [3080652] Ответить | Цитировать Сообщить модератору |
WiRuc Member Откуда: Воронеж Сообщений: 1280 |
Перестаньте вводить людей в заблуждение, вам уже объяснили, что под очередью понимаются не только ожидающие, но и уже выполняющиеся запросы. Так что никакого бытылочного горлышка нету. |
||
1 сен 06, 11:04 [3080711] Ответить | Цитировать Сообщить модератору |
DeColo®es Member Откуда: Москва Сообщений: 5503 Блог |
Понятно. Значит, если у дисковой стойки с одним диском из 40 винтов скопилась очередь из 41 запроса, горлышка нет. Потому, что ждет на самом деле только 1, а остальные 40 обрабатываются отдельно каждым винтом. Ура!!!! |
1 сен 06, 11:50 [3081130] Ответить | Цитировать Сообщить модератору |
Гость 123
Guest |
Для случая RAID-5 из 4 дисков происходит деление на 4, а не на 3, как я думал. Интересно, почему?..
Софтовый RAID-5? Это сильно. |
||||
1 сен 06, 14:47 [3082667] Ответить | Цитировать Сообщить модератору |
Между сообщениями интервал более 1 года. |
maa2 Member Откуда: Сообщений: 4 |
Ситуация из практики в тему. есть RAID-массив из 12 HDD. подаём на него нагрузку с глубиной очереди=1 Например пусть это будет дефрагментация. В течении всего времени дефрагментации счетчик "Avg. Disk Queue Length" показывает "1" Как тут уже объяснили, в показания счетчика "Avg. Disk Queue Length" входят не только запросы, стоящие в очереди, но и запросы, находящиеся в стадии выполнения. Т.е. в нашем случае "1" означает, что в стадии выполнения в один момент времени находится один запрос, а очереди, как таковой, нет. Тут возникает вопрос - а сколько дисков в массиве могут одновременно обрабатывать один запрос? Наверняка ведь какие-то запросы хорошо распараллеливаются, какие-то плохо, а некоторые не распаралелливаются совсем? Как эту ситуацию мониторить? Я пробовал мониторить счетчик "% Idle Time", подавая с помощью Iometer на массив random-read-запросы разного размера при глубине очереди=1. Но, похоже, в случае RAID-массива этот счетчик врёт - всегда показывает ~0%, даже на запросе размером 4КБ, хотя запрос такого размера точно не может быть распараллелен, т.к. он меньше, чем stripe size массива. А если один такой запрос обрабатывается одним диском, а остальные простаивают, то "% Idle Time" должен быть = 100*(11/12) = 91,7%. В общем, практика не сходится с теорией. Давайте разберёмся. |
1 фев 15, 03:35 [17202195] Ответить | Цитировать Сообщить модератору |
aleks2
Guest |
Для счетчика ОСи RAID ничем не отличается от одиночного диска. Ничего про "распаралеливание" система не знает и знать не может. Все "распаралеливание" зарыто в недрах контроллера RAID. Поэтому твои "теории" никуда не годятся. |
1 фев 15, 13:34 [17202536] Ответить | Цитировать Сообщить модератору |
Александр Гладченко Member Откуда: Сообщений: 10765 Блог |
maa2, Уже много лет современные диски оптимизируются под глубины очередей на порядки превышающие 1 или 2. Тем же иометром Вы легко проверите сей факт, если будете в каждом новом измерении увеличивать глубину очереди и потом построите график. В том, что Вы наблюдаете с дефрагментацией, нет ничего удивительного, ведь очередь порождает всего один процесс, который может создать один поток ввода-вывода и посылать там запросы строго последовательно. На самом деле, если Вы малость "покопаете" интернет, то (даже на этом сайте) увидите рекомендации отказаться от наблюдения за глубиной очереди, ввиду того, что результаты не поддаются осмысленной интерпретации. Этот счётчик был хорош в конце прошлого и начале нынешнего века, сегодня он просто устарел и остаётся для обратной совместимости. По поводу интерпретации результатов иометра, приведите тут вначале сприншоты или конфигурацию нагрузки, тогда и обсудим. Сообщение было отредактировано: 1 фев 15, 16:39 |
1 фев 15, 13:50 [17202568] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |