Вы находитесь на странице: 1из 92

1

<Insert Picture Here>

Производительные системы обработки


данных на основе СУБД Oracle
Сергей Стеценко
Ведущий технический специалист
Sergey.Stetsenko@oracle.com
Содержание доклада

• Конфигурирование производительных <Insert Picture Here>

систем обработки данных


• Терминология и системные
компоненты
• Конфигурирование систем хранения
• Конфигурирование OLTP-систем
• Конфигурирование хранилищ данных
• Optimized Warehouse Initiative и Exadata
• Нагрузочное тестирование

3
<Insert Picture Here>

Конфигурирование
производительных СОД

4
Конфигурирование систем
обработки данных (СОД)
• Вопросы определения программно-аппаратной
конфигурации СОД возникают
• При построении новой информационной системы
• Каким образом подобрать компоненты системы
для эффективной и надежной работы?
• При модификации существующей СОД
• Где "узкое" место в системе? Каковы возможности
развития системы?
• Задача имеет комплексный характер и требует
учета множества факторов
• Материальных, технических, организационных, людских

5
Конфигурационные факторы

• Конфигурация системы в первую очередь


зависит от ее функционального назначения
• Учет особенностей прикладной задачи
• OLTP или DSS? Характер рабочей нагрузки?
• Архитектура самого приложения
• Требования к производительности системы
• И перспектив ее увеличения (масштабируемости)
• Требования к надежности и защищенности системы
• Доклад в основном посвящен вопросам
расчетной производительности СОД
• "Сайзинг" (sizing) систем обработки данных

6
Конфигурирование СОД
для СУБД Oracle
• Конфигурирование производительных СОД,
основанных на СУБД Oracle, включает
• Выбор системной архитектуры (SMP или/и RAC)
• Определение характеристик и состава аппаратных
компонентов системы (с учетом рабочей нагрузки)
• Процессоры, память, адаптеры, интерфейсы,
коммутаторы, контроллеры, диски
• Тестирование конфигурации при реальной
(или рассчетной) рабочей нагрузке
• Вопросы выбора вычислительной
платформы в докладе не рассматриваются
• Производитель, тип процессоров, ОС

7
SMP или кластер?

• Несколько "меньших"
серверов с общей базой
данных, соединенных
скоростным интерконнектом
8 CPUs

• Один "крупный"
многопроцессорный
сервер (SMP)

Производительность обеих
систем сопоставима

8
SMP или кластер?
• Достоинства
• Расширяемость
• Отказоустойчивость
• Недостатки
• Сложность управления
• Требуется RAC-опция
8 CPUs • Межузловой обмен

• Достоинства
• Простота управления
• Эффективность
• Недостатки
• Нерасширяемость
• Уязвимость
• Стоимость сервера

9
SMP или кластер?

• Скорость перемещения
данных из ячейки в ячейку
по интерконнекту
8 CPUs 5000-50000 наносекунд

• Скорость перемещения
данных из ячейки в ячейку
по системной шине
320 наносекунд

10
OLTP-системы

• Системы категории
"заказ авиабилетов"
• Большое количество
пользователей
• Многочисленные
короткие транзакции
• Требуется минимальное
время отклика

11
OLTP-системы

• Системы категории
"заказ авиабилетов"
• Большое количество
пользователей
• Многочисленные
короткие транзакции
• Добавление процессоров
позволяет обслужить
больше пользователей
• ...при отсутствии других
узких мест в системе

12
Хранилища данных

• Хранилища данных и
аналитические системы
• Относительно немного
пользователей
• Сложные запросы и
массированные чтения
• Параллельное
выполнение

13
Хранилища данных

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

14
Сбалансированная СОД

Интерконнект

Процессоры

Серверы

Все компоненты
HBA

HBA
Адаптеры
системы должны
иметь согласованную
Коммутаторы пропускную
способность
Контроллеры

Диски

15
Вопросы конфигурирования
Процессорная мощность

Интерконнект

Процессоры • Сколько нужно


Серверы процессоров?
• Каких именно
процессоров?
HBA

HBA
Адаптеры

Коммутаторы

Контроллеры

Диски

16
Вопросы конфигурирования
Пропускная способность канала В/В

Интерконнект

Процессоры

Серверы

• Количество
HBA

HBA
Адаптеры
адаптеров?
• Скорость
адаптеров?
Коммутаторы

Контроллеры

Диски

17
Вопросы конфигурирования
Пропускная способность коммутатора

Интерконнект

Процессоры

Серверы HBA

HBA
Адаптеры

• Скорость FC-свича?
Коммутаторы • Количество портов?
• Несколько свичей?
Контроллеры

Диски

18
Вопросы конфигурирования
Производительность дисковой подсистемы

Интерконнект

Процессоры

Серверы HBA

HBA
Адаптеры

• Скорость
Коммутаторы дискового
контроллера?
• Сколько нужно
Контроллеры контроллеров?
• Сколько дисков
Диски и каких?

19
Вопросы конфигурирования
Пропускная способность интерконнектa

Интерконнект

Процессоры
• Какой интерконнект
Серверы использовать?
• Какова его скорость?
HBA

HBA
Адаптеры

Коммутаторы

Контроллеры

Диски

20
<Insert Picture Here>

Терминология и
системные компоненты

21
Дисковые интерфейсы
ATA и SATA

• ATA (Advanced Technology Attachment)


• Параллельный интерфейс подключения накопителей
• Уточненное название – PATA (Parallel ATA)
• Короткий 40-проводный шлейф
• Разновидностями ATA являются IDE, EIDE, ATAPI
• В настоящее время вытесняется SATA
• SATA (Serial ATA)
• Последовательный интерфейс
• Помехоустойчивость кабеля позволяет
работать на более высоких частотах
• SATA 2 более производителен, на очереди SATA 3

22
Дисковые интерфейсы
SCSI и SAS

• SCSI (Small Computer System Interface)


• Шинный интерфейс (протокол) для
объединения различных устройств
• Применяется преимущественно в серверах
• В настоящее время вытесняется SAS
• SAS (Serial Attached SCSI)
• Последовательный интерфейс "точка-точка"
• Использует команды SCSI для управления
и обмена данными
• Более высокая пропускная способность
• Поддерживает подключения SATA

23
Прямое подключение дисков
DAS

• DAS (Direct Attached Storage)


• Устройство хранения подключено
непосредственно к серверу
• Интерфейсы SCSI, FC, SAS
File System
• Отсутствуют
• Централизованное управление
ресурсами
• Разделение ресурсов между
серверами

24
Сети хранения данных
SAN

• SAN (Storage Area Network)


• Подключение удаленных накопителей, при
котором ОС видит ресурсы как локальные
• БЛОЧНЫЙ доступ к дискам
File System
• Обычно SCSI через FС
• Fibre Channel Protocol (FCP)
• Реже iSCSI (SCSI через TCP) FC, GbE

• Дешевле Fibre Channel


• InfiniBand для производительности
• Разделяемый сетевой дисковый
ресурс

25
Сетевое устройства хранения
NAS

• NAS (Network Attached Storage)


• Платформенно-независимый
сетевой файловый сервер
• Интеллектуальное устройство
• Не блочный, а ФАЙЛОВЫЙ доступ
к дискам Network

• Протоколы NFS, SMB/CIFS (Samba)


• Менее надежен и быстр, чем DAS File System
• Дополнительное ПО на пути данных
• Возможно, сетевые задержки
• Предшественник SAN

26
Дисковые накопители
Общие сведения

• В зависимости от используемого интерфейса


• Диски семейства SCSI
• Преимущественно SAS, FC, собственно SCSI
• Высокая надежность и быстродействие
• Высокая стоимость и средняя емкость
• SATA-диски
• Ценовая доступность и большая емкость
• Средние надежность и быстродействие
• Разное применение в базах данных (БД)
• SCSI для активной части БД, SATA для пассивной

27
Дисковые накопители
Емкость и надежность

• Производительные SCSI- и SAS-диски имеют


• Высокую скорость вращения (10К или 15К RPM)
• Сравнительно небольшие пластины, поэтому
относительно небольшую емкость
• Типичны 72, 144, 300 GB при 15К RPM
• "Миллион" часов наработки на отказ (MTBF)
• Многолетняя рабочая нагрузка в режиме 24*7
• SATA-диски
• Вращаются медленнее (как правило, 7.2K RPM)
• Имеют большую емкость (до 1TB)
• Вполовину меньший ресурс надежности

28
Производительность дисков
Теория и практика

• Паспортная производительность типичного


SCSI-диска
• 50/100 МБайт/сек (в конце и в начале диска)
• В новейших дисках до 100/150 МБ
• 50/100 IOPS (случайный/последовательный доступ)
• В новейших дисках до 180 IOPS @15K RPM
• Время доступа 3-5 мс
• Реальные усредненные показатели
при работе с Oracle (TPC-H)
• 20 МБ/с, 30 IOPS, 10-20 мс
• Теория не подтверждается практикой

29
Дисковые массивы

• Внешние многодисковые устройство хранения


• Гибкость, функциональность, надежность
• Собственный кэш и контроллеры
с поддержкой RAID и виртуализации
• Подразделяются на NAS, модульные
SAN (в шкаф) и монолитные SAN
• При выборе учитываются
• Функциональность и надежность (цена)
• Количество и характеристики дисков
и дисковых контроллеров
• Количество и скорость портов
• Размер кэша

30
Производители дисковых массивов

• EMC - CLARiiON AX4/CX3/CX4


• Hitachi - TagmaStore, SMS100
• HP - EVA, MSA
• IBM - DSxxxx, Nxxxx
• NetApp - FASxxxx
• Sun - StorageTek xxxx
• И многие другие…

31
FC-коммутаторы

• Сетевые устройства для протокола Fibre Channel


• Коммутация устройств по схеме "многие ко многим"
• Защита данных и надежность
• Зонирование трафика
• Каскадирование коммутаторов
• При выборе учитываются
количество и скорость портов
• Сетевая скорость измеряется в битах, а не байтах
• Для DAS-конфигураций коммутатор не нужен
• Производители Brocade, Cisco, QLogic

32
Адаптеры ввода-вывода
Host Bus Adapters (HBA)

• Устройства, соединящие компьютер


с накопителями
• Обычно Fibre Channel (также SCSI)
• Могут быть одно- или двухпортовыми
• Brocade, Emulex, QLogic
• Сетевые компоненты
• Скорость измеряется в битах, а не байтах
• 2, 4 или (новейшие) 8 Гбит/с
• В хранилищах рекомендуется 1 HBA на 1 CPU
(и даже на одно ядро!)
• В OLTP-системах редко бывают узким местом

33
Процессоры

• Производительность зависит от архитектуры


и конкретной модели
• Одно ядро AMD обрабатывает до 120, Intel до 155,
IBM p6 до 300 МБ/сек (на одинаковых тестах)
• Можно принять, что 1 ГГц одного ядра
обрабатывает 50-100 МБ/с из потока I/O
• Или 100-200 МБ/с для усредненного ядра (2 ГГц)
• В реальных условиях этот показатель обычно ниже
• Оценочные расчеты очень приблизительны!
• Не учитывается смешанная и служебная нагрузки

34
Процессоры
Практические рекомендации

• Использование CPU c максимальными


объемами кэшей 1-го и 2-го уровней (L1 и L2)
• Даже важнее, чем частота процессора
• Поэтому в серверах используется Xeon, а не Pentium 4
• Учет ограничений системной шины
• Например, у PCIe 2 ГБ/с при 8 лэйнах по 250 МБ/с
• Как правило, при большом количестве процессоров
• Рассмотреть возможность перехода к RAC
• Использование 64-битных процессоров
• Больше адресное пространство, шире шина,
быстрее арифметика

35
Интерконнект

• Используется в кластерных конфигурациях


для межузлового обмена информацией
• Контроль целостности кластера ("heartbeating")
• Oracle Cluster Ready Services (OCRS)
• Распределенный буферный кэш (Cache Fusion)
• Буферизованные сообщения между процессами (IPC)
• Основной фактор при многоузловом параллельном
выполнении запросов в хранилищах данных

36
Межузловые коммуникации
при параллельном выполнении
Узел 1

Узел 2 Межузловые
сообщения
37
Интерконнект
Возможные реализации

• Ethernet
• Сегодня наиболее распространенная технология
• Витая пара, оптоволокно, медь
• 1 GigE позволяет достичь скорость до 80 MБ/сек
• Ограничение протокола (8b/10b кодировка)
• 10 GigE в 10 раз быстрее, но менее распространен
• InfiniBand
• Последовательный двунаправленный интерфейс
"точка-точка", разрабатывался как преемник PCI
• HCA (Host Channel Adapter) вместо HBA
• Скорость 2 (SDR), 4 (DDR), 8 (QDR) Гбит/сек
• Линки могут объединяться по 4 (или даже по 12)

38
Интерконнект
Практические рекомендации

• Каждая кластеризованная система обычно


имеет ТРИ сети
• Приватную для контроля целостности ("heartbeating")
• Невысокие требования к производительности
• Публичную – для обеспечения доступа пользователей
• Высокопроизводительную приватную для IPC
• Чаще всего используется 1(10) GigE
• InfiniBand при количестве узлов в кластере более 8
• Учесть дополнительную нагрузку на процессор
• uDAPL (InfiniBand) лучше, чем UDP
• UDP лучше, чем TCP
• Jumbo-фреймы Ethernet (9000 vs 1500 байт MTU)

39
Что еще нужно упомянуть

• "Религиозные" дебаты о RAID5


• Запись в несколько раз медленнее чтения
• Кэш обратной записи (write-back) обязателен
• Не так уж плох в реальной практике
• Кэш дискового массива
• Всегда приветствуется
• Особенно при записи, и особенно для RAID5
• Кэширование (буферизация) файловой системы
• На работе Oracle сказывается отрицательным образом
• Прямой ввод-вывод быстрее
• ASM и RAC кэш не используют
• Асинхронный ввод-вывод ("перехлест" I/O и CPU)
• DISK_ASYNCH_IO=TRUE (обычно по умолчанию)

40
Автоматическое управление
дисковой памятью
• Automatic Storage Management (ASM)
• Техника управления данными в Oracle 10g+
• Volume Manager для СУБД Oracle
• Фактически является программной
реализацией RAID-технологии
• Учитывает особенности работы СУБД
• Избавляет АБД от необходимости
управления сотнями файлов данных
• Оперирует не файлами, а дисковыми группами
• Автоматические страйпинг, ребалансирование,
зеркалирование данных

41
<Insert Picture Here>

Конфигурирование
систем хранения данных

42
Конфигурирование по объему
хранения
• Конфигурирование дисковой подсистемы,
основанное только на объемах хранения
• Чаще всего ошибочный способ проектирования
• Применим только в исключительных случаях
или в дополнение к другим методикам
• Существенно зависит от используемой
схемы повышения надежности хранения
• Зеркалирование дисков в RAID1 (или RAID10)
• Нормальная (NORMAL) избыточность ASM
• Не совсем RAID1, но в тех же объемах
• RAID5 (распределенная информация о четности)

43
Расчет объемных характеристик
дисковой подсистемы
• Предположим, что база содержит 1 ТБ
табличных данных, планируется рост до 3 ТБ
• Реальные дисковые объемы должны быть
в 3-5 раз больше, т.е. 9-15 ТБ
• Индексы, кубы, рабочее пространство (внутри базы)
• Дисковые резервные копии, область быстрого
восстановления, архивные журналы (вне базы)
• При 300 ГБ дисках для хранения 15 ТБ
потребуется
• 100 дисков в RAID1 (50+50)
• 63 диска для RAID5 (по схеме 4+P)

44
Хранение данных в сжатой форме

• Сжатие табличных данных


• Удаление внутриблочной избыточности
• Сокращение объемов хранения в 2-3 раза
(например, для таблиц в хранилищах)
• Эффективные чтения при небольшой
дополнительной нагрузке на CPU
• Advanced Compression позволяет сжимать
• OLTP-таблицы перманентно
• Неструктурированные данные (SecureFiles)
• Резервные копии Data Pump и RMAN
• Опция Oracle Database EE

45
<Insert Picture Here>

Конфигурирование
OLTP-систем

46
Характеристики типичных
запросов к базе данных
• Ресурсоемкие запросы (и подзапросы)
условно подразделяются на две категории
• Запросы с высоким потреблением ресурсов CPU
• Интенсивная обработка строчных данных
• Сравнительно небольшой объем чтения таблиц
• Запросы с большой нагрузкой по I/O
• Преимущественно чтение строк из таблиц
• Несложная обработка данных в строках
• В реальные системах встречаются
запросы обеих категорий
• Но какая-то из категорий преобладает

47
Примеры ресурсоемких запросов

Интенсивный I/O Нагрузка на CPU


SELECT cust_id, AVG(amount_sold) SELECT prod_id
FROM sales s, time_dim t channel_id,
WHERE s.time_id = t.time_id SUM(quantity_sold),
AND fiscal_year BETWEEN SUM(amount_sold),
1999 AND 2002 AVG(quantity_sold),
GROUP BY cust_id; AVG(amount_sold),
SUM(quantity_sold*amount_sold),
AVG(quantity_sold*amount_sold),
COUNT(*)
FROM sales
GROUP BY prod_id, channel_id
ORDER BY prod_id, channel_id;

• Больше чтений из таблиц • Меньше чтений


• Меньше вычислений • Больше вычислений
• 200 МБ/с на Xeon 3.0 ГГц • 50 МБ/с на Xeon 3.0 ГГц

48
Характеристики системного
ввода-вывода
• При конфигурировании СОД нужно учитывать
характерные режимы доступа к дискам
• I/O c логически случайным доступом к данным
• Одноблочный доступ в Oracle
• Интенсивное использовании индексов
• Обычно OLTP-приложения
• I/O c логически последовательным доступом
• Многоблочный доступ
• Сканирование таблиц и хэш-соединения
• Хранилища данных
• В реальные системах нагрузка смешанная

49
Характеристики I/O для уже
существующей системы
• Характеристики I/O для рабочей системы
определяются по системной статистике
• Версии 10gR2+
• Показатели "single-block ..." и "multi-block ..."
в V$SYSSTAT
• В более ранних версиях
• V$FILESTAT (файлы данных), V$SYSSTAT (журналы),
V$BACKUP_*_IO, V$FLASHBACK_DATABASE_STAT
• Отчеты AWR (V$SYSSTAT) для общей нагрузки
• "physical IO disk bytes" для MBPS,
"physical reads" и " physical writes" для IOPS

50
Сайзинг OLTP-систем

• OLTP-системы характеризуются
• Многочисленными короткими транзакциями
• Большим количеством пользователей
• Высокими требованиями к времени отклика
• Смешанной нагрузкой – не только транзакции, но и
• Пакетная загрузка, регламентированная отчетность,
выгрузка данных в хранилище, другие работы
• Тем не менее, обычны индексные методы доступа
• Теоретический сайзинг OLTP-систем затруднен
• Как правило, показатели вырабатываются на основе
уже накопленных данных о производительности

51
Конфигурирование по количеству
операций ввода-вывода
• Предположим, система имеет смешанную
транзакционно-пакетную нагрузку
• 20 транзакций/сек при 50 чтениях на транзакцию
• 2000 физических чтений/сек для пакетного режима
• Средняя производительность диска при
работе СУБД Oracle составляет 30 оп/с
• Требуемое количество дисков
• По транзакциям (20*50)/30 = 32 диска
• По пакетным заданиям 2000/30 = 64 диска
• 128 дисков в RAID1 и 80 дисков для RAID5

52
<Insert Picture Here>

Конфигурирование
хранилищ данных

53
Сайзинг по пропускной
способности системы
• Хранилища данных характеризуются
большими объемами ввода-вывода
• Чтение больших массивов данных
• Массовая загрузка данных в хранилище
• Время обработки крупных массивов данных
является основным критерием сайзинга
• Требуемая производительность достигается
путем распараллеливания вычислений
• На пути параллельных потоков обработки
не должно быть узких мест

54
Конфигурирование хранилищ
Простые правила

• Пропускная способность подсистемы


ввода-вывода важнее дисковых объемов
• Чем больше физических дисков, тем лучше
• Особенно при большом количестве процессоров
• "Минимум по два диска на CPU" (DW Guide :)
• Максимальный страйпинг файлов
• Планирование роста базы
• Дисковая избыточность для
повышения надежности

55
Один терабайт за 10 минут
Пример конфигурирования – Часть 1

• Предположим, что необходимо обработать


шесть терабайт за один час
• 1 ТБ за 10 минут или 1600 МБ/с
• Средняя производительность диска при
работе СУБД Oracle составляет 20 МБ/с
• Требуемое количество дисков 1600/20 = 80
• 160 дисков в RAID1 и 100 дисков для RAID5
• Пропускная способность выбранного
дискового контроллера 2 Гб/с (200 МБ/с)
• Требуется 1600/200 = 8 контроллеров (массивов)

56
Один терабайт за 10 минут
Пример конфигурирования – Часть 2

• Предположим, используются CPU


c производительностью ядра 100 МБ/с
• Требуется 1600/100 = 16 ядер
• Например, 4 узла по два 2-ядерных CPU
• Для соединения с дисковой подсистемой
используем 2 Гб/с FC-адаптеры (HBA)
• По одному адаптеру на CPU или рассчетных
1600/200 = 8 HBAs
• 8 потоков на вход и 8 на выход требуют
16 портов в коммутаторе по 2 Гб/с каждый
• Например, два 8-портовых FC-свича

57
Сбалансированная система
1 Тбайт за 10 минут

Interconnect 100MB/s GigE


1GB Infiniband
CPU's
2*4*200MB/s = 1600MB/s
Servers
HBA1

HBA2

HBA1

HBA2

HBA1

HBA2

HBA1

HBA2
HBA's 2*4*200MB/s = 1600MB/s

FC-switches 8 ports 2*800MB/s = 1600MB/s

Controllers
8*200MB/s = 1600MB/s
Arrays 1600/20 = 80 disks
160 RAID1, 100 RAID5

58
Системные ограничения
и рекомендации
• Узел имеет ограниченное количество бас-слотов
• По крайней мере, один слот будет задействован
под интерконнект
• Возможно применение двухпортовых HBA
• Но их производительность может оказаться ниже
• Требуемые объемы оперативной памяти зависят
от множества факторов
• DW или OLTP, особенности нагрузки, архитектуры и
самого приложения, параметры базы данных
• 4 ГБ на ядро CPU можно считать начальным
приближением при конфигурировании

59
<Insert Picture Here>

Optimized Warehouse
Initiative и Exadata

60
Конфигурирование хранилищ
данных
• Конфигурирование эффективных хранилищ
данных представляет собой сложную задачу
• Задача может быть существенно упрощена
применением
• Образцовых (референсных) конфигураций на основе
оборудования известных производителей
• Готовых преконфигурированных систем разного уровня
с предустановленным ПО для хранилищ данных
• Такой подход реализован в рамках проекта
"Oracle Optimized Warehouse Initiative"

61
Референсные конфигурации
для хранилищ данных
• Хорошо протестированные и документированные
конфигурации ПО и оборудования ведущих фирм
• Готовые конфигурации для систем разного уровня
• Гарантированная производительность
• Сбалансированность и согласованность компонент
• Модульность и масштабируемость систем
• Широкий выбор архитектур и поставщиков

62
Конфигурационные модули

• Основной конфигурационной единицей


является "модуль"
• Например, "для хранилища объемом 10ТБ
с интенсивной обработкой данных"
• Определенные ОС, сервер, CPU, память,
дисковая подсистема, коммутатор
• Выбор модулей достачно широк
• Из однотипных модулей формируются
более крупные системы
• Например, до 4 модулей в связке
• Линейный рост производительности

63
Выбор конфигурационного модуля

Размер системы
Рабочая нагрузка

64
Преконфигурированные хранилища
Oracle Optimized Warehouses

• Преконфигурированные хранилища данных


с уже установленным ПО Oracle
• Готовы к работе сразу же после развертывания
• Продаются и поддерживаются как единый продукт
• ASM, RAC, Partitioning, OEM, средства мониторинга
уже установлены и преднастроены
• Для компоновки системы используются референсные
конфигурации известных производителей
• Новым шагом в этом направлении является
создание семейства продуктов HP Oracle Exadata

65
HP Oracle Database Machine
Extreme Performance

• Специализированная система для


хранилищ данных на базе Oracle
• Совместная разработка Oracle и HP
• Предустановленные OE Linux и Oracle
• ASM, RAC, Partitioning, плагин OEM
• Сверхвысокая производительность
• На ПОРЯДОК быстрее классических
архитектур
• Скорость обработки от 14 ГБ/с
• Массовый параллелизм
• Каскадируемость
• Противовес Netezza,Teradata, Greenplum

66
HP Oracle Database Machine
Что внутри?

• 8 серверов баз данных


• HP DL360 G5 с 2-мя 4-ядерными Intel
CPU, 32 ГБ ОЗУ, 4 SAS-диска 146 ГБ,
2-портовый 16 Гб адаптер InfiniBand
• Oracle Enterprise Linux
• Oracle DB 11g EE, RAC и Partitioning

67
HP Oracle Database Machine
Что внутри?

• 8 серверов баз данных


• HP DL360 G5 с 2-мя 4-ядерными Intel
CPU, 32 ГБ ОЗУ, 4 SAS-диска 146 ГБ,
2-портовый 16 Гб адаптер InfiniBand
• Oracle Enterprise Linux
• Oracle DB 11g EE, RAC и Partitioning
• 1 Гб коммутатор Ethernet
• 4 24-портовых коммутатора InfiniBand

68
HP Oracle Database Machine
Что внутри?

• 8 серверов баз данных


• HP DL360 G5 с 2-мя 4-ядерными Intel
CPU, 32 ГБ ОЗУ, 4 SAS-диска 146 ГБ,
2-портовый 16 Гб адаптер InfiniBand
• Oracle Enterprise Linux
• Oracle DB 11g EE, RAC и Partitioning
• 4 24-портовых коммутатора InfiniBand
• 14 дисковых серверов (Exadata Storage)
• HP DL180 G5 с 2-мя 4-ядерными Intel
CPU, 8 ГБ ОЗУ, 12 дисков (SAS или SATA),
2-портовый 16 Гб адаптер InfiniBand
• Oracle Enterpise Linux
• Oracle Exadata Storage Server Software

69
HP Oracle Exadata Storage Server
Дисковый сервер

• Дисковая модульная единица, используемая


в Oracle Database Machine
• Фактически является SMP-сервером с12 дисками
• 450 ГБ SAS-диски (общая скорость 1 ГБ/с) или
• 1 ТБ SATA-диски (производительность 750 МБ/с)
• ASM с зеркалированием (между серверами)
• Установлено специальное серверное ПО Exadata
• Выполнение специфичных для СУБД задач
• Сама СУБД не устанавливается
• Может использоваться
и без Database Machine

70
Как работает Exadata Storage Server
Query Offload

• Запрос выполняется
сервером БД, НО...
Server
• Шаги плана с интенсивным
Smart Scan I/O выполняются на самом
дисковом сервере
Smart Scan • Фильтрация строк, столбцов,
соединения (если возможно)
Smart Scan • Массовый параллелизм
• Разгрузка интерконнекта
Smart Scan • Встроенное ПО “Smart Scan”
• Поддерживается в 11.1.0.7

71
Как работает Exadata Storage Server
Некоторые детали реализации

SGA • Протокол iDB для связи


PХ- RAC- и дисковых серверов
процессы
• "Smart Scan" выполняется
компонентой CELLSRV
• Возвращаются не блоки,
iDB
Function
shipping
а результирующий набор
Result • Непосредственно в область
set
памяти PХ-процесса
• Буферный кэш не используется
• Если функции не делеги-
CELLSRV руются, то обычная схема

72
Как работает Exadata Storage Server
Пример плана выполнения

------------------------------------------------------------
| Id | Operation | Name | E-Rows |
------------------------------------------------------------
| 0 | SELECT STATEMENT | | |
| 1 | SORT AGGREGATE | | 1 |
| 2 | PX COORDINATOR | | |
| 3 | PX SEND QC (RANDOM) | :TQ10000 | 1 |
| 4 | SORT AGGREGATE | | 1 |
| 5 | PX BLOCK ITERATOR | | 46 |
|* 6 | TABLE ACCESS STORAGE FULL| SALES | 46 |
------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------

6 - storage(:Z>=:Z AND :Z<=:Z)


filter("PRICE"<25000)

73
<Insert Picture Here>

Нагрузочное
тестирование

74
Нагрузочное тестирование

• Как правило, сложный многоэтапный


процесс, включающий в себя
• Анализ профиля нагрузки и
разработку типовых сценариев
• Настройку тестируемой конфигурации
и проведение нагрузочных испытаний
• Анализ результатов и построение прогнозов
• Документирование всех этапов тестирования
• Качественное тестирование предполагает
соответствующую инструментальную поддержку
• Но не отвергает простые и эффективные средства

75
Инструментальные средства
тестирования производительности
• Тестирование дисковой подсистемы
средствами ОС
• Команда dd в UNIX
• ORION
• Real Application Testing
• Воспроизведение реальной нагрузки
на тестовой системе
• В докладе НЕ рассматриваются
• Тестирование формальными тестами
• TPC-С/TPC-H, SAP, EBS, …
• Эмуляторы нагрузки приложений

76
Тестирование дисковой подсистемы
средствами ОС
• Нужно убедиться в "сырой" производительности
дисковой подсистемы до установки Oracle
• UNIX- и Linux-команда dd
• Копирует данных со входного устройства на выходное
• Используемые параметры dd
• bs=BYTES (размер блока при чтении)
• count=BLOCKS (количество копируемых блоков)
• if=FILE (чтение из FILE вместо stdin)
• of=FILE (запись в FILE вместо stdout)
• skip=BLOCKS (смещение от начала чтения)
• Запускается с каждого узла в кластере
77
dd для тестирования дисковой
производительности
• Размер блока устанавливается равным объему
одиночного многоблочного чтения в Oracle
• DB_FILE_MULTIBLOCK_READ_COUNT до 10gR2
• 1 МБайт для первичной оценки
• В качестве входного указывается устройство,
используемое для ASM или файлов данных
• В качестве выхода указывается /dev/null
• Читается достаточно большое количество блоков
• Пример команды
dd bs=1048576 if=/raw/data_1 of=/dev/null count=1000

78
Имитация параллельных чтений
командами dd
• При параллельном выполнении чтение данных
выполняется несколькими процессами
• Parallel Servers в терминологии Oracle
• Для имитации параллельных чтений запускается
несколько одновременных команд dd
• По возможности на разных устройствах для
минимизации эффекта кэширования массива
• Или с различным смещением от начала устройства:
dd bs=1048576 count=200 if=/raw/data_1 of=/dev/null &
dd bs=1048576 count=200 skip=200 if=/raw/data_1 of=/dev/null &
dd bs=1048576 count=200 skip=400 if=/raw/data_1 of=/dev/null &
dd bs=1048576 count=200 skip=600 if=/raw/data_1 of=/dev/null &
dd bs=1048576 count=200 skip=800 if=/raw/data_1 of=/dev/null &

79
Скорость чтения dd и Oracle

Насыщение

МБ/сек

Процессов чтения

• Скорость многоблочного чтения в Oracle


составляет около 85% скорости чтения dd

80
ORION
Oracle I/O Numbers Calibration Tool
• Инструментальное средство тестирования
производительности I/O для БД Oracle
• Общедоступное, но не поддерживаемое
http://www.oracle.com/technology/software/tech/orion/index.html
• Установка базы данных Oracle не требуется
• Имитация операций I/O, характерных для Oracle
• Используется библиотека ввода-вывода Oracle
• Эмулируются случайный и последовательный
методы доступа, эффект страйпинга в ASM
• Различный уровень нагрузки
• В RAC запускается на индивидуальных узлах

81
Пример использования программы
ORION
• orion • Значение параметров
• -run advanced • Режим тестирования
(также simple или normal)
• -testname Test • Наименование теста
• -num_disks 120 • Количество дисков
• -size_large 1024 • Размер крупного блока I/O (КБ)
(-size_small для малого блока)
• -type rand • Случайный доступ
(seq - последовательный)
• -num_streamIO 64 • Потоков операций
• -simulate RAID0 • Страйпинг через LUNs
(concat - LUNs подряд)
• -duration 60 • Длительность теста (сек)

82
Результаты работы программы
ORION
• В результате тестирования формируется
несколько текстовых файлов
• Общие результаты тестирования (в MBPS и IOPS)
• Гистограммы показателей производительности при
разных уровнях нагрузки

83
Тестирование системы на
реальной нагрузке
• Тестирование новой системы на реальной
нагрузке представляет собой сложную задачу
• Необходимы значительные людские, материальные
и временные ресурсы
• Большую сложность представляет собой
воспроизведение реалистической нагрузки
• Конкурентный доступ, характеристики транзакций,
профиль их поступления по времени и т.д.
• Новые возможности Database 11g позволяют
эффективно решить эти задачи
• Dаtabase Replay и SQL Performance Analyzer

84
Real Application Testing
Тестирование системы на реальной нагрузке
Статистика (AWR)

Рабочая Захват Тестовая


система рабочей система
нагрузки

Файлы
захвата Анализ и
отчеты
Агенты
воспроизведения

DUPLICATE, Snapshot Standby, DataPump

85
Захват рабочей нагрузки

• Все клиентские запросы протоколируются


в специальных файлах захвата
• Двоичные платформенно-независимые файлы
в файловой системе
• Могут быть ОЧЕНЬ большими
• Задаются начальный момент времени
и продолжительность захвата
• Рекомендуется рестарт базы
• Возможен захват только
некоторых сессий
Файлы
• Мониторинг в OEM Рабочая
Захват
захвата
нагрузка

86
Воспроизведение нагрузки

• Файлы захвата переносятся на тестовую систему


и предварительно обрабатываются
• Однократная операция, создание метаданных
• Нагрузка воспроизводится специальными
процессами-агентами (wrc)
• Возможно избирательное воспроизведение
• Каждый агент воспроизводит несколько сессий
• Может быть несколько агентов
(по результатам калибровки)
• Допускается многократное
воспроизведение нагрузки Файлы Агент
захвата Тестовая
• Мониторинг в OEM воспроиз-
ведения нагрузка

87
Отчеты о результатах тестирования

88
<Insert Picture Here>

Заключение

89
Что еще нужно учесть при
конфигурировании СОД
• Важной задачей является конфигурирование
подсистемы резервного копирования
• Применимы рассчеты, основанные
на пропускной способности каналов I/O
• Но есть специфика (инкрементальные
режимы, время восстановления и т.д.)
• Требования к резервному копированию
могут изменить основную конфигурацию
• Дополнительная (и весьма существенная)
нагрузка на подсистему I/O
• Это только частная задача общей проблемы
обеспечения высокой надежности системы

90
Рекомендации по сайзингу

91
92