Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6   вперед  Ctrl      все
 Re: Помогите выбрать дисковый расклад  [new]
gundamar
Guest
Александр Гладченко
... Ещё про надёжность RAID10 - выход одного диска рушит всё зеркало....


Отсюда вопрос - Вы работали с серьёзными дисковыми системами? Как Вы думаете, на серьезный системах тоже выход одного диска в дисковом массиве на raid 10 рушит все зеркало?
Например на MSA 1000/1500 от HP?
27 май 09, 16:53    [7235980]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
gundamar

Отсюда вопрос - Вы работали с серьёзными дисковыми системами? Как Вы думаете, на серьезный системах тоже выход одного диска в дисковом массиве на raid 10 рушит все зеркало?
Например на MSA 1000/1500 от HP?


Я не умею отличать серьёзные дисковые системы от несерьёзных :)
HP никогда не блистал решениями в этой сфере, зато блистал неординарность решений (не говорю, что это плохо). Однако, оба варианта RAID10 и RAID0+1 сильно теряют (по логике вещей), когда начинается ребилд одного из дисков массива. Посудите сами, если контроллер мог осуществлять чтение одновременно с обоих плечей (зеркал) массива, то в варианте RAID0+1 производительность чтения может упасть в два раза. В варианте RAID10 потери могут быть меньше, но это сильно зависит от алгоритма конкретного вендора... к тому же, последний вариант, скорее всего, не может читать с обоих плеч одновременно, т.к. плечё всего одно.
Что такое MSA 1000/1500 я не знаю.
27 май 09, 17:24    [7236261]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
gundamar
Guest
Александр Гладченко
gundamar

Отсюда вопрос - Вы работали с серьёзными дисковыми системами? Как Вы думаете, на серьезный системах тоже выход одного диска в дисковом массиве на raid 10 рушит все зеркало?
Например на MSA 1000/1500 от HP?


Я не умею отличать серьёзные дисковые системы от несерьёзных :)

Виноват, не корректно выразился. Лишь хотел подчеркнуть, что не всегда надежность зависит от уровня RAID, как это может показаться на первый взгляд. Вот пример: есть HP Modular Smart Array 1500cs (грубо это два контроллера MSA1000) плюс две дисковые полки MSA 30 c 14 (кажется) дисками в каждой. Далее все названия привожу в терминологии системы HP Array Configuration Utility.
Процесс создания массивов следующий 1) сначало создается (ются) массив(ы) (Array) - один или более как хотите. Причём вообще не спрашивается какой мы хотим RAID на массиве!!!.
2) Далее на созданном массиве (Array) создаются логические диски (Logical Disk) для которых мы и указываем уровень RAID, размер, stirpe size, и т.п. и т.д..(именно Logical Disk видны ОС)
Так вот, создаю следующую конфигурацию: все 28 дисков объединяю в один Array, затем на нем создаем 4 Logical Disk. Теперь я имитирую сбой. Вытаскиваю первых семь дисков из одной полки и последние сем дисков из другой полки - все работает. Про производительность могу скзать, что она осталась на уровне гораздо высшем, чем когда у меня на контроллере LSI MegaRAID 320-2 на RAID-5 массиве вышел из строя один диск (всего было 5 дисков). Хотя конечно сравнивать RAID-5 и RAID10 (и даже RAID1) не стоит.[/quot]

Александр Гладченко

HP никогда не блистал решениями в этой сфере, зато блистал неординарность решений (не говорю, что это плохо).

На это могу сказать, что только ленивый за это не пнул HP :). Насколько я помню Storage Works ей тоже от Compaq перешла по наследству. А серию XP кажется делает Hitachi - HP на них только вроде свои ярлыки вешает и софт делает.

Александр Гладченко
Что такое MSA 1000/1500 я не знаю.

А с какими системами Вы работали - IBM, HITACHI, SUN, EMC, Fujitsu?
27 май 09, 18:25    [7236609]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
В последние годы всё больше LSI (IBM или Dell), раньше и с HP доводилось... из списка не помню только, чтобы с EMC возился...
27 май 09, 18:46    [7236678]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
sp
Member

Откуда:
Сообщений: 3947
Вы тут о высоком :)
а вот я столкнулся с парадоксом - есть 2 машины: одна типа покруче(6гиг оперативки + быстрые САТА диски с 32мб кэшем, 2хядреным процем) и так сибе машика(2гига оперативки одноядреный старенький проц и не шибко шустрые маленькие диски) так вот база по физлицам на 48миллионов штук в основной таблице + связанные - запрос на поиск на обоих происходит почти без ощутимой разницы - я вот репу сижу чешу - если нет никакой разницы - зачем платить больше!?

Еще попутно мысль-вопрос - не мешает ли большой кэш у дисковых контроллеров работать шустро самому скулю?
30 май 09, 17:30    [7247857]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
vino
Member

Откуда:
Сообщений: 1191
sp, одиночный запрос показателем не является. Кстати, "так сибе машика" случайно не со SCSI дисками?
31 май 09, 19:55    [7249077]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
vino, классика парадоксальных конфигураций - это как раз то, что на машинах с "более быстрыми scsi винтами" SQL работает медленнее, чем на дешевых IDE/SATA. Потому, как последние жульничают и игнорируют просьбы SQL сервера не кэшировать и не переупорядочивать запись. А scsi честно не используют буфер на запись.
31 май 09, 21:32    [7249223]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
sp
Member

Откуда:
Сообщений: 3947
vino
sp, одиночный запрос показателем не является. Кстати, "так сибе машика" случайно не со SCSI дисками?


я рассказал об одиночном запросе как о показателе
машина допотопная с обычными дисками
1 июн 09, 07:07    [7249783]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
vino
Member

Откуда:
Сообщений: 1191
DeColo®es, на чтение-то SCSI опережают. Но помимо времени выполнения запроса нужно учесть его стоимость, как минимум в CPU и READS эквиваленте. Если в прошивке контроллера нет ошибок, то кэш никогда не замедлит работу (кэш на запись, очевидно, допустим, только если есть батарейка). SATA диски без кэша не показали бы высокой производительности, если бы не кэш+NCQ
1 июн 09, 10:30    [7250143]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
sp
Вы тут о высоком :)
а вот я столкнулся с парадоксом - есть 2 машины: одна типа покруче(6гиг оперативки + быстрые САТА диски с 32мб кэшем, 2хядреным процем) и так сибе машика(2гига оперативки одноядреный старенький проц и не шибко шустрые маленькие диски) так вот база по физлицам на 48миллионов штук в основной таблице + связанные - запрос на поиск на обоих происходит почти без ощутимой разницы - я вот репу сижу чешу - если нет никакой разницы - зачем платить больше!?

Еще попутно мысль-вопрос - не мешает ли большой кэш у дисковых контроллеров работать шустро самому скулю?


Слишком мало информации... Я встречал и такие случаи, как очень дорогое железо (десятки миллионов зелёных), умудрялись угробить неправильной конфигурацией....
1 июн 09, 10:44    [7250196]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
a_shats
Member

Откуда: Москва
Сообщений: 814
Александр Гладченко,

Нельзя ли уточнить условия вышеупомянутого тестирования ? А именно:
- сколько Outstanding I/O requests ( параметр -о) было задано ?
- каков объем тестовых файлов ?

Просто нужно кое-что проверить :)

Заранее спасибо за ответ.
1 июн 09, 10:49    [7250219]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
a_shats
Александр Гладченко,

Нельзя ли уточнить условия вышеупомянутого тестирования ? А именно:
- сколько Outstanding I/O requests ( параметр -о) было задано ?
- каков объем тестовых файлов ?

Просто нужно кое-что проверить :)

Заранее спасибо за ответ.


Скачайте презентацию моего доклада, там в комментариях всё подробно обозначено: https://www.sql.ru/Downloads/Presentation/AGmetod.zip
1 июн 09, 11:43    [7250529]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
a_shats
Member

Откуда: Москва
Сообщений: 814
Спасибо. Но ряд моментов в презентации очень удивили, конечно.
Не совсем понял, зачем нужна калибровка по винтам: винты с явно худшими или явно лучшими относительно остальных характеристиками можно выявить, просто глянув на маркировку: в пределах одной серии скачков и провалов одного винта на фоне других быть не должно - или он попросту неисправен. Понятно, что выбирать для тестирования, да и вообще пользовать массив с разномастными (разных производителей, серий и т.п.) винтами в одной драйв-группе как-то не комильфо.
Также странна калибровка массива: контроллеры внешних RAID давности года-двух, за исключением совсем уж дешевых, нагрузить одной полкой винтов не выйдет. А померить производительность собственно контроллера можно гораздо проще - задав область тестирования меньше объема кэша, с минимальным размером блока. Внутренние контроллеры - немного другое дело, но там тоже 8-16 винтов более или менее современный контроллер не "убьют".
"Запрудить" же шину в нынешних условиях, имхо, несколько нереально. Пример: реальная производительность устаревшего FC 2 Gbps - 25000 IOps. Реальная, полученная при тестировании.
Как Вы понимаете, шпинделей для этой цифири потребуется несколько больше, чем 12 :) Это не говоря о 4 и 8 GBps современных интерфейсах.
Понятно, что презентация еще и о других интерфейсах (SAS, SCSI) - но и там выбрать производительность по IOps достаточно проблематично.
Но это все ладно.
Неладно - это максимальный размер очереди для SQLIO. 64 - все же на хорошо нагруженных инсталляциях бывает очередь и поболе, да и для сравнения маловато. Понятно, что глюк самого инструмента измерения, но все же... Дабы сравнивать поведение массива с другими на тяжелой нагрузке - стоит и грузить его достаточно тяжко, чтобы сам контроллер с его кэшем серьезных результатов на тестирование не оказал (в плане разброса цифири).
Самый главный вопрос - для чего измеряются МБайт/с, а не IOps ? Понятно, что между ними есть зависимость в виде известного размера блока. Но все же: наиболее тяжкая нагрузка на транзакционные БД все же - случайный доступ. Как мне кажется :) . Зачем ориентироваться на линейный трансфер ? Не файловый сервер ведь. Хотя - Ваше замечание в презентации: При выборе другого оборудования или в условиях другого характера нагрузки, например, OLTP, график вполне может стать другим. - принимается. Но тогда, как мне кажется, нет смысла рассматривать данный метод тестирования применительно именно к транзакционным задачам.

Еще вопросы по собственно сравнительному тестированию:

1. Я нигде не увидел упоминание о т.н. "прогреве" - т.е. тестовом прогоне с включенным на контроллере кэшированием чтения и записи, результаты которого не должны учитываться. Прогрев надо бы делать перед каждым испытанием, при каждом изменении типа нагрузки.
2. Также не нашел времени каждого теста (кроме как в калибровке). Дело в том, что учитывая "заскоки" алгоритмов кэширования в современных контроллерах, первые минут 5 под нагрузкой результаты снимать просто не имеет смысла, цифирь будет зверски болтаться. Вспоминая, что и прогрева не было - немного грустно получается. На самом деле, нужно даже и не 5 минут - а гораздо больше, в идеале - час-другой, дабы показатели устаканились, вот тогда и есть смысл снимать результаты.

Резюмируя: я не спорю, что как-то этим методом оценить производительность массива под аналитику можно, но для транзакционных баз этот метод не очень пригоден. И это не говоря о необходимости в прогреве и достаточно длительном тестировании каждого варианта нагрузки.

И еще: выше Вы упоминали о преимуществе нескольких массивов перед большим - единственным.
Согласен - с условием, что дисков под каждый из файлов БД достаточно много. Скажем так - десятки. Мне, к сожалению :) , так и не довелось увидеть своими глазами преимущество нескольких массивов перед одним на количестве дисков 16-12 и менее: я собирал счетчики perfmon на множестве нагруженных инсталляций MSSQL, и убедился, что RAID-контроллер на таком количестве винтов рулит нагрузкой обычно эффективнее, чем это можно сделать руками :)
1 июн 09, 14:10    [7251376]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
a_shats
Спасибо. Но ряд моментов в презентации очень удивили, конечно.


Большое спасибо за развёрнутый ответ, предложения и, главное, замечания! Для меня это действительно очень важно.

a_shats

Не совсем понял, зачем нужна калибровка по винтам: винты с явно худшими или явно лучшими относительно остальных характеристиками можно выявить, просто глянув на маркировку: в пределах одной серии скачков и провалов одного винта на фоне других быть не должно - или он попросту неисправен. Понятно, что выбирать для тестирования, да и вообще пользовать массив с разномастными (разных производителей, серий и т.п.) винтами в одной драйв-группе как-то не комильфо.


Увы, если бы всё всегда было так, как в Ваших словах... Чаще всего я с серверами работаю удалённо, и не всегда удаётся добиться оперативной реакции обслуживающего железо персонала. В таких случаях проще сделать быстрый, как в презентации, тест на "вшивость". Однако, признаю, что этот акцент в описании был мной недостаточно чётко обозначен.

a_shats

Также странна калибровка массива: контроллеры внешних RAID давности года-двух, за исключением совсем уж дешевых, нагрузить одной полкой винтов не выйдет. А померить производительность собственно контроллера можно гораздо проще - задав область тестирования меньше объема кэша, с минимальным размером блока. Внутренние контроллеры - немного другое дело, но там тоже 8-16 винтов более или менее современный контроллер не "убьют".
"Запрудить" же шину в нынешних условиях, имхо, несколько нереально. Пример: реальная производительность устаревшего FC 2 Gbps - 25000 IOps. Реальная, полученная при тестировании.
Как Вы понимаете, шпинделей для этой цифири потребуется несколько больше, чем 12 :) Это не говоря о 4 и 8 GBps современных интерфейсах.
Понятно, что презентация еще и о других интерфейсах (SAS, SCSI) - но и там выбрать производительность по IOps достаточно проблематично.


Производительность отдельных компонент дисковой подсистемы в методике не исследовалась, хотя понятно, что абстрагироваться от этого полностью невозможно. В предлагаемой методике мы смотрим на дисковую подсистему, условно, как на "чёрный ящик"... Ограничения, а также разного рода ошибки, могут быть совершенно в разных местах. Чтобы начать разговор об этом с администраторами дисковой подсистемы, нужно иметь аргументы. Масштабирование позволяет получить на руки факты именно из этой области. Кроме того, поскольку мы хотим получить в итоге некий эталон производительности, подобные измерения бывают весьма полезны.
Хотел бы поспорить только по одному моменту, это по поводу узких мест в интерфейсах. Даже на закупленном в этом году железе мне удавалось достичь предела производительности одной петли силами 12-ти дисков. Как раз на тесте Масштабирования. Увы, мне больше приходиться с подобными системами возиться :(

a_shats

Но это все ладно.
Неладно - это максимальный размер очереди для SQLIO. 64 - все же на хорошо нагруженных инсталляциях бывает очередь и поболе, да и для сравнения маловато. Понятно, что глюк самого инструмента измерения, но все же... Дабы сравнивать поведение массива с другими на тяжелой нагрузке - стоит и грузить его достаточно тяжко, чтобы сам контроллер с его кэшем серьезных результатов на тестирование не оказал (в плане разброса цифири).


Ограничение глубины очередей довольно существенно нивелируется увеличением числа потоков. Наверное, есть резон желать большего... Мне пока не доводилось готовить дисковые подсистемы для задач такого масштаба. Для моих приложений нагрузка была вполне приемлемой.

a_shats

Самый главный вопрос - для чего измеряются МБайт/с, а не IOps ? Понятно, что между ними есть зависимость в виде известного размера блока. Но все же: наиболее тяжкая нагрузка на транзакционные БД все же - случайный доступ. Как мне кажется :) .
Зачем ориентироваться на линейный трансфер ? Не файловый сервер ведь. Хотя - Ваше замечание в презентации: При выборе другого оборудования или в условиях другого характера нагрузки, например, OLTP, график вполне может стать другим. - принимается. Но тогда, как мне кажется, нет смысла рассматривать данный метод тестирования применительно именно к транзакционным задачам.


Измерялись оба параметра :) по другому SQLIO не умеет... А вот графики рисовались для начальства, а им в мегабайтах понятней...
По большому счёту, не только очень случайный и очень глубокий по очередям доступ стоит добавить в "матрицу" прогона теста... Увы, я всегда был вынужден искать компромисс получения результата (эталона) в заданные временные рамки :( На семинаре я как раз словами подчёркивал, что набор измеряемых параметров - это самое "уязвимое" допущение методики. С ним, и в первую очередь с ним можно и нужно спорить. ИМХО, для каждой системы этот набор может быть своим. По поводу предложенных параметров тестирования могу только сказать одно, я их не раз апробировал, они давали мне вполне приемлемое качество оценки производительности дисковой подсистемы, которая потом подтверждалась практикой.

a_shats

Еще вопросы по собственно сравнительному тестированию:

1. Я нигде не увидел упоминание о т.н. "прогреве" - т.е. тестовом прогоне с включенным на контроллере кэшированием чтения и записи, результаты которого не должны учитываться. Прогрев надо бы делать перед каждым испытанием, при каждом изменении типа нагрузки.


Да, о «прогреве» и «остывании» в презентации не говорится, об этом сказано в статье об SQLIO по ссылке на первых слайдах.
Кэш я предлагаю всегда отключать, Майкрософт рекомендует чередовать тесты чтения и записи, время тестирования и ожидания между каждым из тестов предлагается выбирать исходя из поведения системы, начав с довольно высоких значений – 300 сек. Мне пока не доводилось сталкиваться с системами, где бы за это время не удавалось получить достаточно хорошо повторяющихся результатов.
a_shats

2. Также не нашел времени каждого теста (кроме как в калибровке). Дело в том, что учитывая "заскоки" алгоритмов кэширования в современных контроллерах, первые минут 5 под нагрузкой результаты снимать просто не имеет смысла, цифирь будет зверски болтаться. Вспоминая, что и прогрева не было - немного грустно получается. На самом деле, нужно даже и не 5 минут - а гораздо больше, в идеале - час-другой, дабы показатели устаканились, вот тогда и есть смысл снимать результаты.

Время каждого теста указано параметром «-s». Про то, что кэши не используются, я уже писал. Согласен, что для теста с включёнными кэшами нужно создавать другие условия.

a_shats

Резюмируя: я не спорю, что как-то этим методом оценить производительность массива под аналитику можно, но для транзакционных баз этот метод не очень пригоден. И это не говоря о необходимости в прогреве и достаточно длительном тестировании каждого варианта нагрузки.

Я не удивляюсь, что у Вас такое первое впечатление от презентуемой методики :) Обычно, первая реакция бывает даже более бурной… Однако, фактом является то, что методика позволяла мне выбрать хороший сайзинг именно для транзакционных OLTP задач. А также и для смешанных типов нагрузки… Для хранилищ я сайзингом не занимался.
a_shats

И еще: выше Вы упоминали о преимуществе нескольких массивов перед большим - единственным.
Согласен - с условием, что дисков под каждый из файлов БД достаточно много. Скажем так - десятки. Мне, к сожалению :) , так и не довелось увидеть своими глазами преимущество нескольких массивов перед одним на количестве дисков 16-12 и менее: я собирал счетчики perfmon на множестве нагруженных инсталляций MSSQL, и убедился, что RAID-контроллер на таком количестве винтов рулит нагрузкой обычно эффективнее, чем это можно сделать руками :)

Уфф… хорошо хоть тут я могу не только своим авторитетом прикрываться :) Посмотрите внимательно на сайзинг баз данных, которые используются на тестах TPC-C и TPC-H. Очень занимательное зрелище ;)
1 июн 09, 15:34    [7251912]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
a_shats
Member

Откуда: Москва
Сообщений: 814
Александр Гладченко,

Даже на закупленном в этом году железе мне удавалось достичь предела производительности одной петли силами 12-ти дисков. Как раз на тесте Масштабирования. Увы, мне больше приходиться с подобными системами возиться :(

Если речь идет о нагрузке типа последовательный доступ большими блоками (линейный трансфер) - то да, нагрузить интерфейс действительно можно :) Просто я смотрел с т.з. транзакционных БД, где этот момент обычно дело девятнадцатое.
Измерялись оба параметра :) по другому SQLIO не умеет...

Это понятно :) Вопрос лишь в типе нагрузки. Цифирей в МБайт/с добиваются одними способами, в IOps - другими :) То же о размере очереди.
С ним, и в первую очередь с ним можно и нужно спорить. ИМХО, для каждой системы этот набор может быть своим.

Но, как мне показалось, в теме обсуждалась именно нагрузка от транзакционной БД, а не аналитической. А Вы предложили автору темы использовать результаты тестирования именно аналитики. Возможно, я ошибаюсь, и что-то где-то просмотрел...
Кэш я предлагаю всегда отключать,

Если речь о "калибровке" дисков - то да. А если речь о боевой эксплуатации - современные массивы могут понести потери в производительности в разы от отключения бортового кэша RAID-контроллера, особенно - кэширования отложенной записи. Пример: на живой задаче (Oracle + 10G база) получилось с HDS AMS500 16-18К IOps всего-то с 30хFC 15K винтов в 2хRAID10. Понятно, что с винтов подобную цифирь получить невозможно, тут сурово сыграл именно кэш.
Собственно, о прогреве и речь шла в том же контексте - он нужен для того, чтобы кэш контроллера набился и устаканился.
Мне пока не доводилось сталкиваться с системами, где бы за это время не удавалось получить достаточно хорошо повторяющихся результатов.

Гм. Вот что значит - разный опыт. Мне за 5 минут сколько-нибудь осмысленных результатов получить ни разу еще не удавалось, слишком суровый разброс. Правда, измерения проводились при помощи IOMeter - там это видно очень наглядно.
Однако, фактом является то, что методика позволяла мне выбрать хороший сайзинг именно для транзакционных OLTP задач.

Собственно, в этом как раз я и усомнился. То есть тестирование на одной нагрузке совершенно не дает представление о поведении того же железа на нагрузке совершенно противоположного типа, как мне кажется :)
Посмотрите внимательно на сайзинг баз данных, которые используются на тестах TPC-C и TPC-H. Очень занимательное зрелище

Ну, в таких вещах всегда исходят из задачи - что именно надо получить. В ТРС конкретно добиваются наивысшего tps/$ , и только. Соответствующими методами (типа набивания вагона дешевых хранилок в софтовый RAID0 :) ).

Итого - единственное и главное мое возражение состоит в том, что нельзя результаты тестирования на последовательном доступе большими блоками использовать для оценки поведения RAID при случайном доступе мелкими блоками, и делать на этом какие-то серьезные выводы и обобщения :)
1 июн 09, 16:25    [7252327]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
Я тут немного поработаю адвокатом Александра, ОК? ;)

Насчет отключения кэшей. Насколько я понял, Александр смотрит не на пиковую, а на минимальную производительность дисковой исстемы. Именно поэтому ему и не нравится RAID10 - при смерти одного диска может недопустмо деградировать производительность.

Спорность данной методики как раз в том, что сделано некоторое количество допущений и ограничений, которые не совсем очевидны и заметны.
1 июн 09, 17:14    [7252663]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
a_shats

Итого - единственное и главное мое возражение состоит в том, что нельзя результаты тестирования на последовательном доступе большими блоками использовать для оценки поведения RAID при случайном доступе мелкими блоками, и делать на этом какие-то серьезные выводы и обобщения :)


Как я понял, корень нашего недопонимания друг - друга как раз в этом :)
Дело в том, что методика демонстрирует получение эталонных значений производительности для SQL Server. Т.е. размеры запросов ввода-вывода характерны только для этой СУБД (там они в отдельной табличке представлены с пояснениями). Эта СУБД из всех сил старается избегать использования мелких блоков (8Кб)! Например, самый ходовой размер запроса ввода-вывода на быстрых конфигурациях определяется характерыми для упреждающего чтения SQL Server размером запроса 64Кб (один экстент = 8 страниц). Поэтому вытягивать производительность для лавины запросов в 8Кб - задача не из самых популярных (это, кстати, и счётчики производительности должны подтверждать).
Итого, в методике делается упор на комплексную задачу, включая размеры запросов, характерные не только для "запущенных" случаев OLTP, но и для удачных попаданий в индекс, упреждающего чтения, всякого рода обслуживания, резервного копирования и т.п.
ИМХО, серьёзные вывод делать только на основании коротких запросов тоже не резон, я ратую за комплексный подход. Но вот расставить весовые коэффициенты в том, каким размерам запроса ввода-вывода отдавать большие приоритеты в оценке их значимости для боевой системы - это уже больше бизнес-задача, которую нужно решить ещё до тестов, тщательно взвесить, обосновать и согласовать с теми, кто за всё это заплатит :)
Не исключено, что в результате, тест сосредоточится только на случайных, коротких запросах. В моей практике такого не случалось ни разу...
И в качестве ностальгического воспоминания... я помню ещё те времена, когда контроллеры не кэшировали запросы, если считали их большими. Например, в некоторых моделях, запрос считался большим, если он превышал 16 Кб...

Я не призываю отключать кэш, это было только обязательным условием для методики. Игры с кэшем я затевал, тут всё, как и у Вас, большой разброс и долго устаканивалось. Если тестировать с кэшем, никаких, увы, сроков не хватит :( Поэтому, я предлагаю делать замеры с включёнными политиками кэширования только для оканчательной конфигурации, чтобы понимать эффективность полученой базы. Задача же моей методики сводилась к тому, чтобы уложиться в неделю и при этом зафиксировать производительность всех ключевых параметров работы SQL Server.

Сообщение было отредактировано: 1 июн 09, 17:38
1 июн 09, 17:36    [7252799]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
a_shats
Member

Откуда: Москва
Сообщений: 814
DeColo®es,
Я тут немного поработаю адвокатом Александра, ОК? ;)

Да не вопрос :)
Насчет отключения кэшей. Насколько я понял, Александр смотрит не на пиковую, а на минимальную производительность дисковой исстемы. Именно поэтому ему и не нравится RAID10 - при смерти одного диска может недопустмо деградировать производительность.

Может быть, но я не вижу смысла тестировать голую производительность винтов - она и так известна :)

Александр Гладченко

Ну то есть, мы с Вами все же пришли к общему мнению, что тестирование, описанное в Вашей презентации, нужно рассматривать с учетом задачи и условий, в которых оно производилось ?
Тогда - согласен :)
1 июн 09, 17:49    [7252882]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
a_shats
Может быть, но я не вижу смысла тестировать голую производительность винтов - она и так известна :)
Ну... Скорость работы под конкретной нагрузкой будет разной у разных систем в зависимости, например, от пресловутого размера блока.
1 июн 09, 18:04    [7252975]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
a_shats

Может быть, но я не вижу смысла тестировать голую производительность винтов - она и так известна :)


С этим соглашусь только с одной поправкой - если речь идёт о коротких, случайных запросах.
Когда же размер нагрузки исчисляется Гигабайтами, не всякого кэша хватит для его эффективного кэширования, и роль кэша во всей дисковой подсистеме становится другой.
Ну а поскольку в приведённых в методике примерах мы полагались на достаточно хорошо оптимизированную OLTP - нагрузку, как раз отключение кэшей позволяет получить наиболее вероятные характеристики работы SQL Server.
1 июн 09, 18:33    [7253103]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
a_shats
Member

Откуда: Москва
Сообщений: 814
Александр Гладченко

С этим соглашусь только с одной поправкой - если речь идёт о коротких, случайных запросах.
Когда же размер нагрузки исчисляется Гигабайтами, не всякого кэша хватит для его эффективного кэширования, и роль кэша во всей дисковой подсистеме становится другой.
Ну а поскольку в приведённых в методике примерах мы полагались на достаточно хорошо оптимизированную OLTP - нагрузку, как раз отключение кэшей позволяет получить наиболее вероятные характеристики работы SQL Server.

Ну вот, а я только собрался с Вами согласиться :)
Насчет IOps от винтов - согласен, они именно на случайном доступе мелкими блоками и известны.
Что касается "не хватит" - я выше приводил пример с Oracle, 10 ГБ базой и AMS500 с кэшем 2 гига. Которого как бы по определению не хватало. Результат я уже назвал - производительность, в несколько раз отличающаяся от той, что могла быть получена при отключении кэширования чтения и записи.
Могу сказать также, что эффективность кэширования в современных RAID-контроллерах не настолько зависит от объема нагрузки, насколько это кажется. Причем это касается как случайного доступа, так и последовательного. Гораздо больше оная эффективность зависит от извращенности изощренности алгоритмов кэширования. По части которой как раз и рулят mid-range и high-end tier-1, за исключением отдельных моделей отдельных производителей.
По методике - ну Вы меня просто расстроили. Там написано, цитирую:
Этот график отражает эффективность работы разных уровней RAID на нашей аппаратной платформе и для тех режимов рабочей нагрузки, которые характерны приложениям заказчика (это аналитические запросы).

Еще раз хотелось бы обратить Ваше внимание: это разные нагрузки на дисковую подсистему. Принципиально разные. Оценивать возможную производительность на одной по результатам другой, на мой взгляд, просто нельзя.

Ну и, немного отойдя в сторону,
ИМХО, серьёзные вывод делать только на основании коротких запросов тоже не резон, я ратую за комплексный подход. Но вот расставить весовые коэффициенты в том, каким размерам запроса ввода-вывода отдавать большие приоритеты в оценке их значимости для боевой системы - это уже больше бизнес-задача, которую нужно решить ещё до тестов, тщательно взвесить, обосновать и согласовать с теми, кто за всё это заплатит :)
Не исключено, что в результате, тест сосредоточится только на случайных, коротких запросах. В моей практике такого не случалось ни разу...

У нас с Вами, возможно, просто сильно разный подход к решению задачи :) Вы предпочитаете решить задачу софтом, "облегчая" жизнь дисковой подсистеме путем сведения каких только можно нагрузок к наиболее "удобному" для дисковой последовательному доступу. Я - наоборот, пляшу "от железа" и рассчитываю на наихудший случай. Причем и Вы, и я в своих подходах ни разу не одиноки - например, производители SCSI/SAS/FC RAID уже с десяток лет оптимизируют все, что только можно, в своих машинах именно под случайный доступ; статей про разруливание нагрузки на дисковую "вручную" тоже, мягко говоря, более чем одна - хотя базируются они на материалах тестирований давности примерно такой же :)
2 июн 09, 11:00    [7254663]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
a_shats

По методике - ну Вы меня просто расстроили. Там написано, цитирую:
Этот график отражает эффективность работы разных уровней RAID на нашей аппаратной платформе и для тех режимов рабочей нагрузки, которые характерны приложениям заказчика (это аналитические запросы).

Еще раз хотелось бы обратить Ваше внимание: это разные нагрузки на дисковую подсистему. Принципиально разные. Оценивать возможную производительность на одной по результатам другой, на мой взгляд, просто нельзя.


Похоже, Оракл работает с дисковым вводом-выводом совсем иначе... ну да ладно. Для моих задач всегда была характерна смешанная нагрузка, т.е. большая часть тот самый случайный доступ (который мы стараемся свести к логическим чтениям) и эпизодические аналитические запросы. В качестве совсем уж крайностей в виде примера можно привести пресловутый 1С и ахсапту. Повидимому, труды веноров дисковых подсистем по оптимизации случаного ввода-вывода не пропали даром, моя практика показывает, что той иммитации подобных нагрузок, которая применяется в тестах методики, вполне достаточно, чтобы оценить производительность случайных маленьких запросов. Впрочем, тут даже небольшие ошибки не играют роли, поскольку SQL Server опирается не не кэш железа, а на свой буферный пул. Именно в него он подкачивает экстенты и диапазоны индексов, когда нужно проделать нечто с данными. Для дисковой подсистемы это выливается в основном в последовательные операции с не малыми запросами, которые таковыми становятся за счёт объединения запросов ввода-вывода (это как раз одна из фич, позволяющих сильно поднять производительность таких запросов). В общем, архитектурные особенности SQL Server таковы, что на те проблемы, с которыми, похоже, приходиться бороться в Оракле, можно просто забить. И похоже, мне нужно будет в презентации подчеркнуть ещё и тот факт, что методика для Оракла не годиться... а жаль, я наивно полагал, что ввод-вывод у них схож...

Сообщение было отредактировано: 2 июн 09, 12:04
2 июн 09, 12:02    [7255098]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
a_shats
Member

Откуда: Москва
Сообщений: 814
Похоже, Оракл работает с дисковым вводом-выводом совсем иначе... ну да ладно.

Я бы не стал так однозначно это утверждать :)
Впрочем, тут даже небольшие ошибки не играют роли, поскольку SQL Server опирается не не кэш железа, а на свой буферный пул. Именно в него он подкачивает экстенты и диапазоны индексов, когда нужно проделать нечто с данными. Для дисковой подсистемы это выливается в основном в последовательные операции с не малыми запросами, которые таковыми становятся за счёт объединения запросов ввода-вывода (это как раз одна из фич, позволяющих сильно поднять производительность таких запросов).

Проверить это несложно - есть ведь perfmon и счетчик среднего размера блока данных (Avg. Bytes/Read и /Write) :) Ну и Reads/sec и Writes/sec, само собой.
Мой опыт более всего связан с 1С, конечно - и вот там случайного доступа хоть отбавляй. Да еще с очень неприятным соотношением чтения и записи. Собственно, мне не доводилось видеть инсталляций транзакционных БД, где обмен с дисковой был исключительно последовательным доступом большими блоками. Но это, вполне возможно, просто от нехватки опыта :)
В общем, архитектурные особенности SQL Server таковы, что на те проблемы, с которыми, похоже, приходиться бороться в Оракле, можно просто забить.

Повторюсь - не думаю, что стоит это однозначно утверждать.
2 июн 09, 13:07    [7255503]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать дисковый расклад  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
Материалы доклада в виде статьи выложены в блог: http://msmvps.com/blogs/gladchenko/archive/2009/06/09/1694801.aspx
10 июн 09, 12:35    [7285152]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Помогите выбрать дисковый расклад  [new]
MicrosoftProjectRU
Member

Откуда:
Сообщений: 78
Очень интересное обсуждение.

Подниму. Согласен с Гладченко.
1) MS SQL действительно умнее чем любой RAID-контроллер, т.к. имеет более серьезную вычислительную мощность для принятия решений
2) Тестирование всегда выявляется "бутылочные горла", поэтому раскидать по зеркалам самые критичные части базы (баз) будет очень серьезной оптимизацией.

Вопрос к Сообществу.

Есть ли материалы на английском языке по стратегии оптимизации баз MS SQL через пачки зеркал?

Мы сейчас готовимся к разработке новой версии MS Project Server, было бы хорошо сразу спроектировать file groups для такой стратегии оптимизации. Возможно даже мастер, который сам по зеркалам все раскидывает при инсталляции.

Но для обсуждения требуется западные заключения.
20 май 11, 20:38    [10687023]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить