Введение

TPC-H – это известный эталонный тест для тестирования баз данных в системах поддержки принятия решений, который подвергает стрессовой нагрузке производительность базы данных, платформы и системы ввода/вывода. Для достижения оптимальной производительности в условиях этой рабочей нагрузки аппаратные и программные системы должны быть полностью настроены и оптимизированы. В статье описывается настройка базы данных и конфигурация системы для публикации ведущего эталонного теста TPC-H с нагрузкой 100 ГБ. Информацию, представленную в данной статье, можно использовать для оптимизации рабочих нагрузок системы поддержки принятия решений и хранилищ данных, которые по своему характеру схожи с эталонным тестом TPC-H.

Публикация эталонного теста TPC-H, которая была использована для создания данной статьи, осуществлялась на базе IBM® DB2® Universal Database™ (UDB) v8.1 с Microsoft Windows® Server 2003 на платформе MAXDATA Platinum 9000-4R® Server. Сервер построен на базе четырех процессоров Itanium® 2 с размером кэш-памяти 3-го уровня 6 MБ, тактовая частота каждого процессора равна 1,5 ГГц.

Задачи оптимизации платформы для указанной рабочей нагрузки решались путем выполнения последовательности шагов по выбору конфигурации системы и базы данных и их настройке. Рабочая нагрузка была разбита на несколько потоков для использования преимуществ работы в многопроцессорной среде и для повышения масштабируемости. Организация дисковой подсистемы, благодаря тщательному размещению пространств таблиц на дисках, обеспечивает оптимальную производительность.

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

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

В начало

Результаты эталонного теста

TPC-H представляет собой эталонный тест для систем поддержки принятия решений, который состоит из набора бизнес-ориентированных и специализированных запросов и параллельных операций изменения данных. Этот эталонный тест демонстрирует производительность систем поддержки принятия решений посредством обработки огромных объемов данных, выполнения сложных запросов и предоставления ответов на вопросы, имеющие важное значение для бизнеса. Запросы к базе данных в эталонном тесте TPC-H сложнее обычных OLTP-запросов.

Тест производительности TPC-H состоит из двух тестов: теста на производительность (Power) и теста на пропускную способность (Throuhgput). В ходе теста Power выполняется один поток последовательных запросов к базе данных. В ходе теста Throughput выполняется несколько параллельных потоков запросов к базе данных, в каждом из которых запросы выполняются последовательно.

Компании IBM, Intel и MAXDATA совместно провели эталонный тест TPC-H в конфигурации 100 ГБ для продукта IBM DB2 Universal Database, установленного на платформе на базе процессоров Intel Itanium 2.

В следующей таблице перечислены результаты эталонного теста TPC-H.

В начало

Описание системы

В качестве системной платформы используется сервер MAXDATA Platinum 9000-4R Server под управлением Microsoft Windows Server 2003 Enterprise Edition с установленной СУБД IBM DB2 UDB V8.1. Для хранения данных используется система сетевого хранения с оптоволоконным интерфейсом подключения Eurologic SANbloc, дополнительно оснащенная возможностью работы по протоколу 2GB Fiber Channel.

На рисунке 1 показана схема физической конфигурации системы.

MAXDATA Platinum 9000-4R Enterprise Server

В качестве платформы эталонного тестирования используется компьютер MAXDATA Platinum 9000-4R Enterprise Server. Это серверная стойка, оснащенная четырьмя процессорами Intel Itanium 2, которые работают на частоте 1,5 ГГц. Каждый процессор имеет кэш-память третьего уровня объемом 6 МБ. Системная плата построена на чип-сете Intel E8870 Server.

Платформа сконфигурирована на использование 32 ГБ физической памяти – это максимальный размер памяти, поддерживаемый данным сервером (16 двухгигабайтных модулей памяти DDR266 DIMM).

Процессор Intel Itanium 2

В платформе эталонного тестирования используются процессоры Itanium 2, работающие с тактовой частотой 1,5 ГГц и имеющие кэш-память третьего уровня объемом 6 МБ каждый. Системная шина работает на частоте 400 МГц и обеспечивает пропускную способность до 6,4 ГБ/с. Процессор создан на базе архитектуры Intel® EPIC и прекрасно совместим с приложениями СУБД типа DB2.

Система сетевого хранения Eurologic SANbloc

В качестве системы хранения данных используется система сетевого хранения Eurologic SANbloc FC2100. Эта система состоит из восьми дисковых массивов с волоконно-оптическим интерфейсом подключения, в каждом из которых 14 дисков размером 18,3 ГБ, скорость вращения 15 000 об/мин. В общей сложности в системе для размещения базы данных имеется 112 дисков. Все восемь дисковых массивов размещены в общем корпусе Eurologic 19” 30U.

Система дискового хранения подключена к системе сервера при помощи четырех волоконно-оптических (FC) адаптеров QLogic QLA2342. Каждый из четырех адаптеров имеет два FC-порта. Каждый FC-порт подключается к одному из восьми дисковых массивов FC.

Microsoft Windows Server 2003 Enterprise Edition (64-разрядная версия)

Для данного эталонного теста была выбрана операционная система Microsoft Windows Server 2003, Enterprise Edition, специально рассчитанная на серверную рабочую нагрузку. Операционная система Microsoft Windows Server 2003, Enterprise Edition доступна в 32-разрядной и в 64-разрядной версиях. В данном случае используется 64-разрядная версия. Версия Enterprise Edition поддерживает до восьми процессоров и 64 ГБ оперативной памяти.

DB2 UDB V8.1 Enterprise Server Edition (ESE) (64-разрядная версия)

Программный продукт DB2 UDB представляет собой сервер управления объектно-реляционными базами данных, обеспечивающий надежный фундамент для достижения высоких показателей производительности и масштабируемости. Версия DB2 Enterprise Server Edition разрабатывалась и оптимизировалась под архитектуру процессоров Intel Itanium; для работы в Windows программа использует компилятор С++. Этот компилятор способствует достижению оптимальной производительности для систем с процессорами Itanium 2.

64-разрядная версия DB2 UDB V8.1 Enterprise Server Edition для Windows предоставляет те же функции, что и ее 32-разрядный аналог. Наиболее существенное различие между этими версиями заключается в том, что 64-разрядная версия позволяет работать с большими объемами данных.

В 32-разрядной версии существуют два основных способа обхода жесткого ограничения в 3 ГБ на виртуальную адресацию для Windows-платформ. Один из способов заключается в использовании модуля расширения Microsoft Windows Address Windowing Extensions (AWE). В другом используется разбиение (или секционирование) рабочей нагрузки на несколько логических разделов, и запуск базы данных по технологии MLN (Multiple Logical Nodes, нескольких логических узлов) на компьютере с симметричной многопроцессорной обработкой. В этом случае каждый логический узел рассматривается как отдельное приложение, а теоретически каждое приложение может использовать до 3 ГБ виртуальной памяти, поэтому несколько узлов могут использовать в общей сложности более 4 ГБ памяти.

64-разрядная адресация, предоставляемая архитектурой Itanium, устраняет ограничение на возможности адресации памяти, существующее в 32-разрядных вычислительных средах. В 64-разрядной версии DB2 имеет встроенную поддержку любого объема памяти, поддерживаемой операционной системой, без использования вышеупомянутых методов AWE и MLN. Тем не менее метод нескольких логических узлов (MLN) все еще остается важным принципом в 64-разрядной вычислительной модели для DB2; он используется для решения других технических проблем, о которых говорится далее в этой статье.

В начало

Конфигурация базы данных

В этом разделе мы изучим конфигурацию DB2 для рабочей нагрузки, создаваемой тестом TPC-H. Первым шагом в достижении максимальной производительности в эталонном тесте TPC-H является изучение возможностей масштабирования.

Масштабируемость и метод логических узлов

Масштабируемость в своей основе связана с отношением между использованием вычислительных ресурсов и производительностью. Организация вычислительных ресурсов эффективным и гибким способом является основой высокой масштабируемости в динамичных средах, используемых в бизнесе и науке. В таких средах объемы данных имеют тенденцию к быстрому росту, а вычислительные ресурсы необходимо часто модернизировать. Для обеспечения масштабируемости в таких проблемных средах база данных должна иметь дополнительные функции.

В DB2 используется архитектура, не предусматривающая разделения ресурсов. Такая архитектура позволяет разделить рабочую нагрузку на несколько логических единиц (или разделов), причем для каждой логической единицы вычислительные ресурсы (ресурсы процессора, память, дисковое пространство) выделяются независимо. В процессе выполнения операций базы данных эти логические единицы для решения общих операционных задач выполняются независимо и одновременно. Архитектура, не предусматривающая разделения ресурсов, гарантирует минимум взаимодействий между разными логическими единицами и использует преимущества параллельных вычислений.

Описанная архитектура может применяться не только к нескольким физическим узлам или к кластеру компьютера, но и к компьютеру с многопроцессорной обработкой (или SMP-компьютеру). В нашем эталонном тесте мы делим рабочую нагрузку теста TPC-H между четырьмя процессорами Itanium 2 так, чтобы каждый процессор работал как можно более независимо от остальных процессоров системы. Для разделения рабочей нагрузки необходимо использовать MLN-функции DB2 и создать экземпляр базы данных с четырьмя логическими узлами. Следующая команда создает экземпляр базы данных с четырьмя логическими узлами для данной четырехпроцессорной платформы:

db2icrt db2tpch /s:ese /u:<userid>,<password> /p:D:\db2inst
db2ncrt /n:1 /u:<userid>,<password> /o:db2bench /i:db2tpch /p:1
db2ncrt /n:2 /u:<userid>,<password>/o:db2bench /i:db2tpch /p:2
db2ncrt /n:3 /u:<userid>,<password> /o:db2bench /i:db2tpch /p:3

В этой команде db2bench – имя компьютера, на котором размещена база данных, а db2tpch – имя экземпляра. Для каждого логического узла выделен порт связи. Узел 0 по умолчанию владеет портом 0; порты остальных узлов определяются при помощи параметра /p. После создания экземпляра и добавления остальных трех узлов четыре физических процессора присоединяются (по принципу родственности), соответственно, к определенным логическим узлам при помощи следующей группы команд:

db2set db2processors=0 –i db2tpch 0
db2set db2processors=1 –i db2tpch 1
db2set db2processors=2 –i db2tpch 2
db2set db2processors=3 –i db2tpch 3

Как правило, в SMP-системе нумерация процессоров начинается с 0. В данном случае процессор 0 присоединяется к логическому узлу 0, процессор 1 – к логическому узлу 1 и т.д.

Настройка пространства таблиц

Для достижения оптимальной производительности базы данных очень важно правильно определить пространство таблиц.

В данной конфигурации эталонного теста присутствует восемь дисковых массивов по 14 дисков в каждом, т.е. всего в системе насчитывается 112 дисков. Эти диски равномерно распределяются между четырьмя логическими узлами. Следовательно, каждому логическому узлу выделено два массива или 28 дисков. Логические узлы и выделенные для них диски позволяют узлам работать независимо друг от друга.

В логическом узле каждое пространство таблиц определяется в двух массивах, при этом из каждого массива используется 13 дисков, в общей сложности это 26 жестких дисков. Два диска, по одному из каждого массива, объединяются и формируют зеркальный том. Зеркальный том предназначен для хранения файлов журналов и определяется при помощи системной утилиты Windows для управления жесткими дисками.

В базе данных создают пять обычных пространств таблиц и одно временное пространство таблиц. В следующей таблице указаны подробные параметры для всех пространств таблиц.

Все пространства таблиц, за исключением small_tables, определяются на одном наборе дисков. Такая организация используется потому, что в ходе теста TPC-H значительный объем операций ввода/вывода используется для последовательного чтения данных. В процессе интенсивных последовательных чтений из одного пространства таблиц операции ввода/вывода в других пространствах таблиц незначительны или даже совсем отсутствуют.

Если разные пространства таблиц размещаются на разных физических дисках, то в процессе последовательной выборки из одного пространства таблиц будут вращаться только те диски, на которых определено это пространство таблиц, остальные диски будут вращаться очень мало или вообще простаивать. Такое распределение дисков благоприятно для последовательных чтений. Рекомендуемая стратегия – распределить данные из всех пространств таблиц по максимально возможному числу дисков, чтобы добиться максимальной степени параллелизма ввода/вывода.

Все пространства таблиц, за исключением small_tables, были определены как DMS (Database Managed Space – пространство, управляемое базой данных), а не SMS (System Managed Space – пространство, управляемое системой). Тип пространства таблиц связан с последовательным характером ввода/вывода рабочей нагрузки теста TPC-H. Для пространств таблиц типа DMS DB2 в большей степени контролирует физическое отображение страниц данных на группы кластеров дискового пространства, которые называются экстентами.

Экстенты определяют разбиение данных по разным контейнерам и гарантируют, что страницы данных в одном контейнере будут смежными. Благодаря тому, что в пространствах таблиц DMS страницы данных являются смежными, такие операции, как последовательные сканирования таблиц, будут более эффективными по сравнению с пространствами таблиц SMS. В пространствах таблиц типа SMS физическое размещение страниц данных определяется системой, поэтому нет никакой гарантии, что в одном экстенте будут размещаться смежные страницы.

Размер страницы буферного пула

Еще одной важной мерой настройки производительности является управление размером страниц буферного пула. Буферный пул – это область памяти, используемая для хранения (или кэширования) страниц данных в процессе их чтения с диска или изменения. Буферный пул способствует повышению производительности базы данных за счет того, что обращение происходит к данным, хранящимся в памяти, а не на диске. DB2 поддерживает следующие размеры страниц буферного пула: 4 КБ, 8 КБ, 16 КБ и 32 КБ. В данном эталонном тесте для пространств таблиц типа DMS был выбран средний размер страницы – 16 КБ. Обычно больший размер страницы выбирают при последовательных операциях ввода/вывода, а меньший размер страницы лучше подходит для произвольных операций ввода/вывода.

Конфигурация диска

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

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

Независимо от того, насколько быстрыми являются отдельные жесткие диски, после того как количество подключенных через контроллеры к шине PCI дисков достигает определенного уровня, система не может обеспечить большую пропускную способность за счет подключения дополнительных дисков. Независимо от суммарной пропускной способности всех шин PCI, объем ввода/вывода отдельного приложения в конечном итоге будет определяться объемом данных, которые может обработать операционная система. Вычисление размера экстента является отражением этих системных ограничений.

Как правило, рассматриваются два типа дисковых подсистем – RAID и не-RAID. Не-RAID cистемы хранения обычно называют JBOD (Just a Bunch Of Disks – просто пакет дисков).

RAID-массивы всех уровней, за исключением RAID 1-го уровня, используют так называемое расслоение данных по дискам. Если используется RAID-массив с расслоением данных, то до вычисления размера экстента необходимо при настройке конфигурации RAID-массивов выбрать размер блоков расслоения данных. Размер блоков расслоения данных – это объем данных, который записывается на один диск до перехода к следующему диску в данном массиве.

Как правило, выбирается такой размер блоков расслоения данных, который равен максимальному размеру блока ввода/вывода, который может обработать операционная система. Если размер блока расслоения данных будет больше, то, чтобы распараллелить операции ввода/вывода в крупных дисковых массивах, для одного блока расслоения данных потребуется выполнить более одной операции ввода/вывода. Если размер блока расслоения данных будет меньше, чем максимальный размер блока ввода/вывода, то часть пропускной способности ввода/вывода не будет использоваться, что приведет к более медленному выполнению данного количества операций ввода/вывода.

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

Размер экстента = Количество дисков с данными × размер блока расслоения данных (КБ) / размер страницы буферного пула (КБ)

Определение количества дисков для данных в каждом RAID-массива может быть довольно сложной задачей, поскольку количество дисков в массиве не обязательно равно количеству дисков, на которые записываются данные. В следующей таблице указано количество дисков для данных в RAID-массивах самых распространенных уровней:

Для хранилищ, не использующих технологию RAID-массивов (JBOD), ключевым фактором является определение максимального размера блока ввода/вывода, который может обработать операционная система, до выбора размера экстента. В данном эталонном тесте мы использовали для измерения 256 КБ на одну операцию ввода/вывода на протяжении 42 минут времени выполнения, показания фиксировались каждые пять секунд. В следующей таблице показана дополнительная информация об измерениях размера блоков ввода/вывода.

Размер экстента для хранилищ типа JBOD можно вычислить по следующей формуле:

Размер экстента = Максимальный размер блока ввода/вывода / размер страницы буферного пула (КБ)

Экстент, имеющий размер, рассчитанный по этой формуле, может быть прочитан и записан за один блок ввода/вывода в пределах одного диска. В противном случае эффективность обменных операций с диском может заметно снизиться.

В данном эталонном тесте система хранения сконфигурирована как JBOD с размером экстента в 16 страниц (16 = 256 КБ / 16 КБ на страницу).

Серверы ввода/вывода базы данных

Из-за большого объема операций просмотра и сортировки таблиц в рабочей нагрузке теста TPC-H важным моментом для обеспечения оптимальной производительности является упреждающая выборка данных с дисков в оперативную память. DB2 использует упреждающую выборку, если в данной ситуации последовательный ввод/вывод обеспечивает достаточную эффективность, и очевидно, что упреждающая выборка может повысить производительность.

В DB2 серверы ввода/вывода представляют собой потоки (или агенты), которые выполняют упреждающую выборку ввода/вывода и асинхронный ввод/вывод от имени рабочих потоков базы данных. Количество серверов ввода/вывода указывается в параметрах DB2. Для нашего эталонного теста количество серверов ввода/вывода (NUM_IOSERVERS) равно 14 для каждого узла. Для четырех узлов общее количество серверов ввода/вывода равно 56.

Размер упреждающей выборки

Если выполняется упреждающая выборка, то ее размер представляет собой важный настраиваемый параметр. Параметр Prefetchsize (размер упреждающей выборки) определяет количество чтений страниц с диска в ходе запроса упреждающей выборки; обычно его значение выбирают равным нескольким размерам экстента.

Поскольку данный параметр является настраиваемым, можно сначала выбрать значение, равное произведению размера экстента и количества контейнеров, выделенных для одного логического узла, а затем изменять его до достижения наибольшей эффективности последовательного ввода/вывода. В данном эталонном тесте размер упреждающей выборки периодически изменялся и, в конце концов, составил 2 240 (16 × 140).

Использование памяти

DB2, как правило, выделяет память для буферных пулов, кучи для сортировки и других применений на уровне логического узла. Размер буферного пула и кучи для сортировки выбираются такими, чтобы они в совокупности использовали большую часть доступной физической памяти (>90%). В этом эталонном тесте буферному пулу было выделено 375 000 страниц, а куче для сортировки – 75 000 страниц. В следующей таблице приводятся показатели использования памяти в ходе выполнения теста Power,

При выполнении теста Power максимальное использование памяти составило 29 182 062 720 байтов или приблизительно 27,18 ГБ, причем 27 ГБ, или 6,8 ГБ на один логический узел, использовала DB2. Это демонстрирует преимущества 64-разрядных сред. В 32-разрядной системе каждый логический узел может использовать только до 3 ГБ памяти.

В начало

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

В этом разделе представлены различные показатели производительности в тестируемой системе.

Масштабируемость от выполнения теста Power до выполнения теста Throughput

Один из способов оценки масштабируемости системы баз данных заключается в том, что при относительно постоянных ресурсах увеличивается рабочая нагрузка на систему, а затем изучаются результаты.

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

Итоговое время на выполнение теста Power составило 2 738 секунд, а время на выполнение теста Throughput – 13 069 секунд. При выполнении теста Power была использована рабочая нагрузка, в 5 раз превышающая рабочую нагрузку теста Throughput, но выполнение теста заняло только в 4,77 раз больше времени, чем выполнение теста Power. Этот результат свидетельствует о возможности масштабирования системы в целом.

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

Чтобы измерить пропускную способность диска в отношении операций чтения, при помощи системного монитора Windows (Microsoft System Monitor, PerfMon)* осуществляется сбор показаний числа байтов чтения диска в секунду с 5-секундными интервалами. Общая пропускная способность диска в ходе выполнения теста Throughput показана на рисунке 2 (на графике показано изменение этого показателя в МБ/с с течением времени).

Чтобы измерить пропускную способность диска в отношении операций чтения, при помощи системного монитора Windows (Microsoft System Monitor, PerfMon)* осуществляется сбор показаний количества байт чтения диска в секунду с пятисекундными интервалами. Общая пропускная способность диска в ходе выполнения теста Throughput показана на рисунке 2 (на графике показано изменение этого показателя в Мбайт/с с течением времени):

Итоговая средняя пропускная способность диска за все время выполнения теста Throughput составила 344 МБ/с. В отдельные моменты теста Throughput производительность дисковой подсистемы превышала 1 ГБ/с. От начала выполнения теста Throughput до момента времени 2 000 секунд средняя пропускная способность для операций чтения с диска явно превысила 400 МБ/с. Такая пропускная способность в отношении существенных объемов данных требует эффективной настройки базы данных и аппаратно-операционной платформы.

Показатель интенсивности операций чтения диска, IOPS

Чтобы измерить интенсивность операций чтения диска, которая выражается числом операций ввода/вывода в секунду (I/O operations per second, IOPS), при помощи системного монитора Windows (Microsoft System Monitor, PerfMon) фиксируют число операций чтения в секунду с 5-секундными интервалами. Итоговая интенсивность операций чтения с диска в ходе теста Throughput, выраженная числом чтений в секунду, показана на рисунке 3.

В среднем число операций чтения с диска в секунду составляет около 1 800. Максимальное значение – около 8 600 операций чтения с диска в секунду. Это число операций чтения с диска в секунду является ожидаемым, потому что средний размер для чтения с диска составляет 256 КБ.

Использование ресурсов процессора

Теперь перейдем от дисковой подсистемы к процессору. В этом разделе мы рассмотрим совокупное использование ресурсов процессора. На диаграмме (рисунок 4) показано использование ресурсов процессора пользователем и ядром системы в ходе выполнения теста Throughput. На диаграмме видно, что процессоры работали на пиковой мощности с приблизительно 100%-ным использованием. Высокий уровень использования ресурсов процессоров означает, что система хорошо сбалансирована, а процессоры являются лимитирующим фактором в системе, что и является целью настройки и оптимизации производительности. Кроме того, диаграмма показывает, что подсистема ввода/вывода не является узким местом системы в отношении производительности.

В начало

Заключение

В этой статье рассказывается о ключевых точках установки и настройки конфигурации продукта IBM DB2 Universal Database в аппаратной среде на базе процессоров Intel Itanium 2 для публикации эталонного теста TPC-H. Для повышения масштабируемости рабочая нагрузка была разделена на несколько логических разделов, по одному на каждый процессор. Пространства таблиц были определены с особой тщательностью для обеспечения превосходной производительности дисковой подсистемы. При настройке таких важных параметров базы данных, как размер страниц буферного пула, размер экстента и размер упреждающей выборки следует исходить именно из требований к производительности.

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

Ресурсы

Оригинал статьи: Tuning IBM DB2 databases for Intel Itanium 2-based systems (EN).

При написании этой статьи были использованы следующие ресурсы:

• Примите участие в обсуждении материала на форуме.
  
  
• Эталонный тест TPC-H;(EN)
  
  
• Результаты эталонного теста TPC-H для сервера MAXDATA Platinum 9000-4R Enterprise Server;(EN)
  
  
• Программный продукт IBM DB2 Universal Database;(EN)
  
  
• Microsoft Windows Server 2003, Enterprise Edition;(EN)
  
  

Intel, крупнейший в мире производитель интегральных микросхем, также предоставляет множество ценных продуктов и информации для разработчиков программного обеспечения:

• Программные продукты Intel для разработки программного обеспечения – компиляторы, анализаторы производительности, библиотеки производительности и инструменты для работы с потоками.(EN)
  
  

Об авторах

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Результаты эталонного теста
• Описание системы
• Конфигурация базы данных
• Показатели производительности
• Заключение
• Ресурсы
• Об авторах
• Комментарии