автор
Во вторых а как быть с распаралеливанием ввода вывода, о котором мы говорили несколько постов назад. Мне неизвесны контролеры которые
могут выполнять паралельно операции ввода вывода в пределах одного массива. Будь то RAID5 RAID10 или RAID1.
Тоесть то что база данных пытается паралелить по вводу выводу
Ваш RAID сводит на нет(потому что очередь на операции ВВ в масиве одна).

Я думаю этих аргументов пока достаточно.

Я не имел ввиду индекснй поиск по блобам.

Одноpначно для OLTP многопользовательской базы 10 x RAID1 всегда быстрее
одного 1 x RAID10.

с уважением, onstat-


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

2. авторОдноpначно для OLTP многопользовательской базы 10 x RAID1 всегда быстрее
одного 1 x RAID10.
Откуда такое утверждение?
Вы сами то рельно пробовали такую конфигурациию?
Наверно нет.
Дело втом что заниматься балансировкой файлов по дисковым разделам очень не благодарное дело.
А кроме того RAID10 имеет одно очень полезное свойство.
При выходе диска из строя производительность практически не падает , чего я не скажу скжаем о RAID 5.

Например RAID10 на 12x72GB на железке типа HP DL380 c контроллером SA6404 на двух каналах дает примерно 150МБ на запись и примерно 100-120
на чтение.

Если очень интерестно почему.
http://otn.oracle.com/deploy/performance/pdf/opt_storage_conf.pdf

Сергей Тихонов EugeneSOracle9i Real Application Clusters Concepts
Release 2 (9.2)
Part Number A96597-01

4. Scalability in Real Application Clusters
Спасибо за инфо. А можно ссылку на документ или в почту сюда киньте. Хочется поподробнее почитать. Заранее спасибо :-).

авторhttp://download-west.oracle.com/docs/cd/B10501_01/rac.920/a96597/psscadtl.htm#1798

Ggg_old
Дискуссия становится интересной. Задам вопросик параллельно с темой, особенно хотелось бы услышать мнение onstat. Есть БД, размер страницы 2к. Есть RAID 10 (по пять винтов на канале). ОС - Windows 2000AS. Какой размер страйпа будет предпочтительней - 4k, 16k, 32k, 64k? Как в этом случае нужно учитывать или выставлять размер кластера на NTFS. Режим работы БД - смешанный, но тюнить надо под OLTP. У меня есть возможность поэкспериментировать. Есть мысль - размер страйпа 4к (был 32), размер кластера по умолчанию оставить 4к.

Самый лучший вариант максимальный размер страйпа.
Далеет размер кластера должен быть равен размеру страницы БД.
Размер страйпа должен быть кратен размеру кластера и размеру блокак БД.
Если есть возможность размер страйпа бложен быть равен размеру IO ОС.
Я когда-то слышал что для Win это 1МБ.

Ggg_old2 Eugene_S
Мне не очень понятно почему, размер страйпа должен быть как можно больше?
Если БД запрашивает страницу 2к, ОС читает кластер в 4к (типа примитивного read ahead), контроллер читает страйп блок - 32к, а винты читают в свой кэш даже не знаю сколько (все зависит от винтов). Теретически - лишние файловые операции. Практически - эти операции хорошо влияют на чтение последовательных блоков, но здесь все очень зависит от БД и характера ее запросов. А если данные итаются с разных не рядом стоящих блоков, то надо вроде делать наоборот - читать поменьше. Но это конечно все пока теоретические измышления...

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


Вы не правы.
Серверный процесс запрашивает операцию чтения-записи у ОС.
Ядро ОС никогда не выполняет чтение одного блока, а всегда читает с учетом опережающего чтения за исключение случая прямого чтения из дискогово раздела мимо кэша ОС но это отдельная песня.
Значит на каждый запрос на чтение блока размером 2к или 32к со стороны СУБД ядро ОС будет выполнять чтение 1МБ.

onstat- EugeneS

1. Про контроллеры и распараллеливание.
Для того чтобы нормально восспользоваться функцией распараллеливания надо выполнить несколько условий
- число параллельных процессов равно числу процессоров.


Не обязательно, бывают спящие процессы.

EugeneS

- число параллельных процессов равно числу дисковых volume и в свою очередь равно числу дисковых контроллеров.


Тоже не обязательно, один контроллер может держать несколько томов.
IHMO Оптимально 3-5 шт.

EugeneS

- на каждом дисковом контроллере в свою очерель строится RAID10 ( в случае если используетя интесивная запись или RAID5 ). Это на сегодня самые распространненые уровни RAID. В случае если у вас есть RAID3 то можно его использовать для чтения , он лучше подходит для последовательного чтения , а RAID5 лучше для случайного чтения.



Я RAID3 & RAID5 не счтаю достойным к рассмотрению в случае работы с OLTP системами. На них можно хранить фильмы или делать бэкапы.


EugeneS

Откуда такое утверждение?
Вы сами то рельно пробовали такую конфигурациию?
Наверно нет.



Да. пробовал.

EugeneS
Дело втом что заниматься балансировкой файлов по дисковым разделам очень
не благодарное дело.

А кроме того RAID10 имеет одно очень полезное свойство.
При выходе диска из строя производительность практически не падает , чего я не скажу скжаем о RAID 5.


Нужно заниваться не балансировкой файлов, а балансировкой нагрузки на ввод вывод между томами. И возможность этого тюнинга предвидеть заранее.
Я неисползую RAID5 для баз данных и не планирую.

EugeneS
Например RAID10 на 12x72GB на железке типа HP DL380 c контроллером SA6404 на двух каналах дает примерно 150МБ на запись и примерно 100-120
на чтение.


Я не верю в то что это работала база данных.
Или в это время производились полные сканирования таблиц.


Результаты того что пробовал я:

IBM FASTT 600 (12х HDD FC 146 Gb)
Обьем базы данных 500 Gb, самая большая таблица ~230 млн записей.
в 8 таблицах больше 100 млн записей.

Объем кеша контроллеров(2шт) 512Mb.
База данных Informix DS 9.4 OS Linux RH 7.2 ядро 2.6.5
Сервер (Какой был под руками) 2хIntel PIII 1GHz 1 Gb Ram

Пробовали размер страйпа 128К.
На построении индексов коэфициент использования кеша контролера 100%
Считай полное сканирование таблиц.
Пиковая скорость 80М/с
Работа OLTP приложения(100 % индкесный поиск), 8 пользовательских сесий.
Кеш контроллера используется на 3-5 %.
Пиковая скорость 10М/с
При уменьшении страйпа до 8К использование кеша контролера повысилось до 30%.
Пиковая скорость 30 M/c
Общая производительность поднялась ~30-40%.
система была не совсем оптимальна, серверу явно не хватало ОЗУ и
быстродействия процессоров. Но какой был на таком и тестили целью было проверить fastt.


EugeneS

Если очень интерестно почему.
http://otn.oracle.com/deploy/performance/pdf/opt_storage_conf.pdf



Там описано то о чем я говорю на этом форме.
То есть ко всему нужно подходить взвешенно. Нет одного рецепта на все случаи жизни.
ihmo Что бы выжать из конфигурации все нужно учитывать каждуюю деталь.
Так как это делают в Формуле 1.

EugeneS

Самый лучший вариант максимальный размер страйпа.
Далеет размер кластера должен быть равен размеру страницы БД.
Размер страйпа должен быть кратен размеру кластера и размеру блокак БД.
Если есть возможность размер страйпа бложен быть равен размеру IO ОС.
Я когда-то слышал что для Win это 1МБ.



Почему вы не правы по поводу размера страйпа я повторяться не буду посмотрите мое сообщение в этой ветке.
http://www.sql.ru/forum/actualthread.aspx?tid=111586

А что такое размер IO OC? или я отстал отжизни :).

Если это то о чем я думаю, то дальше наверное будем говорить о DMA.

С уважением, onstat-
ps Прошу прощения за задержку, запарка на работе.


1. Я имеею ввиду Parallel Query Option у Oracle и естественно суда не включаются другие сессии, а только сессия которая будет выполнять запрос.


2. Про кол-во дисковых томов на контроллер.
Необязательно но желательно.
Понятно что в реальности все не так, и как правило это нехватка денег тому причиной, ну или когда контроллер имеет независимые каналы .

3. Балансировака нагрузки ввода-вывода как раз и сводится к раскладыванию файлов по дисковым томам в зависимости от ввода-вывода.
Это не так просто на растущей системе.
И очень часто требуется остановка системы.

4. Я говорил о линейном чтении или записи,естественно при случайном чтении и записи цифры ниже порядка 60-70МБ/с

авторА что такое размер IO OC? или я отстал отжизни :).
Это кол-во блоков которые ядро ОС считывает за одну операцию ввода-вывода с файловой системы.