1. DB2 pureXML
2. Еталонний тест TPoX
3. Малюнок 1. Інформаційні об'єкти TPoX.
4. Таблиця 1. Бізнес-опису транзакцій TPoX.
5. Тестована система
6. Малюнок 2. Тестована система.
7. Таблиця 2. Процесори Intel Xeon, які використовувалися при проведенні даного еталонного тестування.
8. Конфігурація і точна настройка DB2
9. Результати відносно витрати ресурсів сховища і стиснення
10. Таблиця 3. Витрата дискового простору і стиснення
11. Малюнок 3. Кількість транзакцій в секунду і використання ресурсів ЦП.
12. Малюнок 4. Докладні результати виконання транзакцій при 200 користувачів.
13. Продуктивність буферних пулів при «самонастройке управління пам'яттю»
14. Малюнок 5. Результативність пошуку в буферних пулах.
15. Малюнок 6. Конфігурація бази даних за допомогою п'яти команд.
16. Малюнок 7. Масштабованість при переході з чотириядерних на шестиядерних ЦП Intel.
17. Малюнок 8. Продуктивність інкрементних операцій вставки XML.
18. Ресурси для скачування

В даний час підприємства з усіх сил намагаються організувати управління збільшується обсягом даних XML, які вони генерують і споживають. Корпорації Intel і IBM провели еталонне тестування першої в галузі терабайтной бази даних XML на підставі сценарію застосування у фінансовій індустрії. Тестування показало здійсненність управління великими обсягами даних XML на економічною апаратній платформі.

Не викликає сумнівів той факт, що XML перетворився в фактичний стандарт для обміну даними, сервіс-орієнтованих архітектур (SOA) і обробки транзакцій на основі повідомлень. У міру зростання обсягу накопичуваних даних XML у компаній виникає потреба в чомусь більшому, ніж просто технологія обробки повідомлень, яка одноразово працює з одним документом XML. Компанії почали зберігати великі обсяги документів XML, іноді для дотримання вимог закону, а іноді - внаслідок гнучкості XML або через широко відомих труднощів, пов'язаних з перетворенням даних XML в реляційний формат і назад. Звиклі до переваг розвинених реляційних баз даних, компанії очікують наявності таких же можливостей для даних XML (мова йде про можливості зберігання, запиту, індексування, поновлення і перевірки даних XML з повною відповідністю принципам ACID, можливості відновлення, високої доступності та високої продуктивності).

XML іноді вважають багатослівним і повільним форматом даних, особливо при обробці великої кількості документів. Подібне ставлення до XML часто грунтується на досвіді того часу, коли ще не існувало належних технологій. Наприклад, збереження безлічі документів XML в файлової системі і написання коду програми для їх синтаксичного розбору і аналізу часто призводять до незадовільної продуктивності і є джерелом розчарувань. Завдяки появі сучасних технологій баз даних та процесорів від такого сценарію можна відмовитися.

Використовуючи доступні в DB2 можливості pureXML і багатоядерні ЦП Intel, корпорації Intel і IBM провели еталонне тестування першої в галузі терабайтной бази даних XML для демонстрації того, що високопродуктивна обробка транзакцій при роботі з терабайтом даних XML більше не є безпідставною фантазією. У цій статті описуються ці тести продуктивності, апаратні засоби і конфігурація DB2, а також наводяться результати і розбираються отримані уроки. Свою ключову роль підтвердили різні технології DB2, включаючи глибоке стиснення, автоматичне збереження даних, пам'ять з самонастроювання і, зрозуміло, pureXML. Результати дозволяють кількісно оцінити багато користувачів масштабованість DB2 з використанням платформи Linux на чотири- і шестиядерних процесорах Intel (процесорах Intel Xeon серій 7300 і 7400). Підготовка конфігурацій всіх систем і проведення тестів, зазначених у цій статті, здійснювалися корпорацією Intel у власній лабораторії.

DB2 pureXML

pureXML DB2 забезпечує підтримку управління даними XML, в тому числі сховище XML, індексацію XML, запити та оновлення XML, а також в якості опції перевірку документів з використанням схем XML. Користувачі можуть визначати стовпці типу XML, в яких можна зберігати по одному документу XML на рядок. Таблиці можуть містити комбінацію XML- і реляційних стовпців, що спрощує інтеграцію XML і реляційних даних. Коли документи XML вставляються або завантажуються в стовпець XML, вони піддаються синтаксичному аналізу і зберігаються в проаналізованому деревовидному форматі. Це дозволяє виконувати запити та оновлення для роботи з даними XML без розбору XML, що є одним з ключових переваг з точки зору продуктивності. XML можна індексувати щодо конкретних елементів або атрибутів для досягнення високої продуктивності запитів. Запити та поновлення ґрунтуються на стандартах SQL / XML і XQuery і в разі необхідності можуть звертатися в одному операторі як до XML, так і до реляційних даних.

Еталонний тест TPoX

Для підтвердження високої продуктивності XML ми вирішили провести еталонне тестування TPoX. TPoX (обробка транзакцій по XML) являє собою еталонний тест бази даних XML з відкритим вихідним кодом і тест рівня додатки, заснований на сценарії застосування у фінансовій галузі. Він оцінює продуктивність систем баз даних XML, фокусуючись на XQuery, SQL / XML, сховище і індексації XML, підтримки схем XML, операціях вставки, оновлення та видалення XML, реєстрації, паралелізм і інших аспектах баз даних. TPoX імітує сценарій торгівлі цінними паперами і використовує реальну схему XML (FIXML) для моделювання деяких зі своїх даних. TPoX розроблений для виконання реалістичного і репрезентативного набору операцій з XML.

Основними логічними інформаційними об'єктами в TPoX є такі об'єкти:

• клієнт (customer): один клієнт може мати один або кілька рахунків;
• рахунок (account): кожен рахунок містить один або кілька вкладів;
• внесок (holding): акція, облігація або взаємний фонд;
• цінний папір (security): один клієнт може мати один або кілька рахунків;
• замовлення (order): кожне замовлення передбачає покупку або продаж акцій рівно одного цінного паперу для конкретної один обліковий запис.

Для кожного клієнта є документ XML, який містить всю персональну інформацію, інформацію про рахунки і інформацію про вклади для даного клієнта (див. Малюнок 1). Кожне замовлення представлений повідомленням XML, яке відповідає схемі FIXML 4.4. FIXML - це стандартна для галузі складна схема XML, призначена для повідомлень, пов'язаних з біржовою торгівлею, наприклад, замовлень на покупку або продаж. Кожна цінний папір описується за допомогою окремого документа XML. Колекція з 20833 документів-описів цінних паперів представляє більшість акцій, облігацій і взаємних фондів, які звертаються в США. Незважаючи на те, що кількість документів цінних паперів є фіксованим, сценарій еталонного тестування масштабується за кількістю документів custacc (клієнтський рахунок) і order (замовлення). У базі даних TPoX об'ємом 1 ТБ використовується 300000000 документів order і 60000000 документів custacc.

Малюнок 1. Інформаційні об'єкти TPoX.

Робоче навантаження TPoX складається з 17 транзакцій, перерахованих в таблиці 1. Їх відносна вага в структурі транзакцій вказано в крайньому правому стовпчику. Операції вставки, оновлення та видалення складають 30 відсотків робочого навантаження; запити - 70 відсотків робочого навантаження. У транзакціях I2, U2 і U4 виконується перевірка схеми XML.

Таблиця 1. Бізнес-опису транзакцій TPoX.

Робоче навантаження виконується драйвером робочого навантаження Java, який породжує конфігурується безліч паралельних потоків для моделювання одночасних дій декількох користувачів. Кожен потік підключається до бази даних і виконує деяку послідовність транзакцій без часу на обдумування. Коли транзакція фіксується, потік, що зафіксував дану транзакцію, негайно обирає ще одну транзакцію з таблиці 1 (вибір здійснюється випадковим чином з асиметричним розподілом ймовірностей, що враховує вагові коефіцієнти транзакцій). Під час виконання драйвер робочого навантаження замінює маркери параметрів в транзакціях конкретними значеннями, вилучаються з випадкових розподілів. Код Java драйвера робочого навантаження доступний у вигляді відкритого вихідного коду і може використовуватися для різноманітних тестів баз даних, а не тільки для еталонного тестування TPoX.

Тестована система

Тестова система (рисунок 2) складається з наступних апаратних і програмних компонентів:

• сервер бази даних;
• сервер з процесором Intel Xeon 7400;
• оперативна пам'ять 64 ГБ;
• клієнтська машина: сервер з процесором Intel Xeon 5400;
• операційна система для клієнта і сервера: Linux SLES 10, 64-розрядна;
• програмне забезпечення бази даних: DB2 9.5 для Linux, UNIX та Windows, Fixpack 2;
• клієнтське програмне забезпечення: драйвер робочого навантаження з відкритим вихідним кодом TPoX, Java 1.5;
• сховище;
• EMC CX3-80
• 15 дисків на один LUN (RAID 0);
• 120 дисків (8 LUN) для бази даних;
• 15 дисків (1 LUN) для журналу;
• 30 дисків (2 LUN) для необроблених даних;
• 2 плати RAID-контролерів (одна для неформатованих файлів, одна для бази даних і журналу);
• по 2 оптоволоконних каналу (4 Гбіт / с) на кожну плату контролера.

Малюнок 2. Тестована система.

Процесори Intel Xeon серій 7400 і 7300

Для аналізу масштабованості продуктивності DB2 зі збільшенням кількості ядер на один ЦП ми виконали еталонне тестування двічі з використанням різних процесорів. При проведенні першого набору тестів використовувалися чотири ЦП Intel Xeon серії 7400 з шістьма ядрами кожен. Потім ми повторили еталонне тестування з використанням чотирьох ЦП Intel Xeon 7300 з чотирма ядрами кожен. Наведене в таблиці 2 порівняння показує, що ЦП відрізняються один від одного не тільки кількістю ядер. Незважаючи на те, що процесор Intel Xeon серії 7400 має на 50 відсотків більше ядер, ніж процесор серії 7300, що його тактова частота на 10 відсотків нижче. Однак при цьому він має кеш 3-го рівня обсягом 16 МБ, в той час як у процесора Intel Xeon серії 7300 подібний кеш відсутня.

Таблиця 2. Процесори Intel Xeon, які використовувалися при проведенні даного еталонного тестування.

При заміні ЦП всі інші апаратні і програмні засоби залишалися колишніми. У процесорах Xeon серій 7400 і 7300 використовується однаковий чіпсет, тому заміна одного процесора іншим є простою «перестановку», яка потребує внесення будь-яких інших змін.

Конфігурація і точна настройка DB2

База даних DB2 була створена з функцією автоматичного сховища DB2 і розміром сторінок 16 КБ, з використанням восьми логічних томів і одним додатковим томом для журналу. Схема бази даних, обрана нами для реалізації сценарію TPoX, є вкрай простий. Вона складається з трьох стовпців XML в трьох таблицях, по одній для кожного з трьох типів документів XML в TPoX (order, custacc, security):

create table custacc (cadoc xml inline length 16288) in custacc_tbs index in custacc_idx_tbs compress yes;

create table order (odoc xml inline length 16288) in orders_tbs index in orders_idx_tbs compress yes;

create table security (sdoc xml inline length 16288) in security_tbs index in security_tbs compress yes;

З метою зменшення простору сховища для 1 ТБ необроблених даних XML застосовувалися підстановка і стиснення XML. Ми створили п'ять табличних просторів (по одному табличному простору для кожної з трьох таблиць, а також одне табличний простір для індексів custacc і одне для індексів order). Всі табличні простору були сконфігуровані з параметрами NO FILE SYSTEM CACHING ( «Без кешування файлової системи») і AUTOMATIC STORAGE ( «Автоматичне сховище»). Кожне табличний простір має свій власний буферний пул. Крім того, є один додатковий буферний пул для тимчасового табличного простору. Ми використовували різні табличні простору і буферні пули головним чином для зручності моніторингу. Згодом нами було підтверджено, що при об'єднанні всіх таблиць і всіх індексів в одне табличний простір і один великий буферний пул продуктивність практично не змінилася (пропускна спроможність знизилася всього на 6 відсотків у порівнянні з ручним конфигурированием).

Для конфігурації розмірів буферних пулів, купи сортування, списку блокувань, кеша пакетів, num_iocleaner, num_ioserver і т. Д. Ми застосували наступний підхід. Щоб уникнути тривалих і повторюваних ітерацій точного налаштування ми, виходячи з розумних припущень, просто поставили значення для всіх зазначених параметрів. Обрані нами показники не замислювалися як оптимальні для даної робочої навантаження, і нам не було відомо про те, чи є вони такими. Вони всього лише грали роль відправної точки для самонастроювання DB2. Наприклад, ми знали, що нам необхідні великі буферні пули для таблиць custacc і order, але нам не було відомо про те, які розміри могли б бути оптимальними. Ми вирішили надати обчислення оптимального розміру самоналагоджувальна диспетчеру пам'яті (STMM) DB2. Ми не хотіли починати з встановленого за замовчуванням значення 1000 сторінок, оскільки знали, що це занадто мало. Ми хотіли допомогти STMM швидко прийти до оптимальних розмірів буферних пулів. Наприклад, спочатку ми встановили розмір буферного пулу для таблиці custacc рівним 770000 сторінок, а потім вибрати автоматичне визначення розміру, щоб було потрібно менше ітеративних регулювань STMM для досягнення оптимального розміру в порівнянні з 1000 сторінок. Для налаштування параметрів INSTANCE_MEMORY і DATABASE_MEMORY також був обраний автоматичний режим.

• наш повний сценарій DDL можна побачити в репозиторії відкритого вихідного коду TPoX тут.
• результати вимірювання продуктивності.

Тепер давайте поглянемо на наступні види підсумкових даних:

• витрата ресурсів сховища і стиснення;
• пропускна здатність транзакцій змішаної робочого навантаження (70 відсотків для запитів, 30 відсотків для операцій вставки / оновлення / видалення);
• результативність пошуку в буферних пулах;
• продуктивність готового продукту з мінімальною кількістю ручних операцій конфігурації і точної настройки;
• масштабованість при переході з 4-ядерних на 6-ядерні ЦП;
• продуктивність інкрементних операцій вставки.

Результати відносно витрати ресурсів сховища і стиснення

Оскільки розмір таблиці security дуже малий (20833 документа), ми вивчали витрата дискового простору і коефіцієнт стиснення головним чином для двох великих таблиць - custacc і order (див. Таблицю 3). 60 мільйонів документів custacc стискаються на 64 відсотки і вимагають 121,4 ГБ в табличному просторі DB2. 300 мільйонів документів order стискаються на 57 відсотків і вимагають 269,2 ГБ в DB2. З урахуванням всіх даних і індексів підсумковий розмір бази даних становив приблизно 440 ГБ. Підстановка і стиснення XML грали критично важливу роль у вирішенні проблеми нестачі ресурсів введення-виведення.

Таблиця 3. Витрата дискового простору і стиснення

Пропускна здатність транзакцій змішаної робочого навантаження

На малюнку 3 показаний результат для пропускної здатності транзакцій змішаної робочого навантаження на 24-ядерної платформі Intel Xeon 7400 з тактовою частотою 2,66 ГГц. По горизонтальній осі показано мінливий число одночасних користувачів, яке моделює драйвер робочих навантажень TPoX. Кожен користувач видає потік транзакцій без часу на обдумування між транзакціями. Синя крива представляє кількість транзакцій в секунду і відноситься до вертикальної осі, розташованої зліва. Рожева кривапоказує використання ресурсів ЦП і відноситься до вертикальної осі, розташованої праворуч. Пропускна здатність і використання ресурсів ЦП зростають у міру збільшення кількості одночасних користувачів. Коли число користувачів збільшується з 100 до 150 і 200, використання ресурсів ЦП наближається до рівня максимальної обчислювальної потужності системи, і зростання пропускної здатності сповільнюється. При 200 користувачів максимальна пропускна здатність становить 6763 транзакції TPoX в секунду.

Малюнок 3. Кількість транзакцій в секунду і використання ресурсів ЦП.

Збільшення кількості користувачів понад 200 не приводить до зростання пропускної здатності, при цьому лише збільшується час реакції транзакцій. Вирівнювання кривої пропускної здатності і вичерпання обчислювальної потужності системи при 200 користувачів безпосередньо пов'язані з тим фактом, що все що моделюються користувачі відправляють транзакції без часу на обдумування між ними. Якби кожен користувач відправляв, наприклад, по одній транзакції в секунду, система могла б підтримувати тисячі користувачів.

На малюнку 4 показані вихідні дані драйвера робочого навантаження для змішаної робочого навантаження при 200 користувачів і тривалості тесту 2 години. Детальна статистика по всім 17 транзакцій в структурі робочого навантаження включає їх максимальне і середній час відгуку, а також їх «число», т. Е. Інформацію про те, скільки разів виконувалася кожна транзакція по всім 200 користувачам. Протягом двогодинного тесту було виконано 48,5 мільйонів транзакцій. Середній час відгуку всіх транзакцій склала менше 0,1 секунди. Оскільки драйвер робочого навантаження працював на окремій клієнтської машині, час реагування включає час на передачу і підтвердження прийому по мережі.

Малюнок 4. Докладні результати виконання транзакцій при 200 користувачів.

При необхідності драйвер робочого навантаження можна налаштувати на висновок подібної зведеної інформації по транзакціях через кожні n хвилин під час тестування. Ця особливість дозволила нам упевнитися в тому, що пропускна здатність весь час залишається стабільною. Драйвер робочого навантаження також може обчислювати 90-й, 95-й або 99-й процентиль часу відгуку транзакцій. Процентилю корисні, якщо ви хочете упевнитися в тому, що 90, 95 або 99 відсотків часу відгуку транзакцій знаходяться нижче певного порогового рівня.

Нагадаємо, що драйвер робочого навантаження доступний безкоштовно у вигляді відкритого вихідного коду і може використовуватися для виконання робочого навантаження SQL, SQL / XML або XQuery будь-якого певного вами виду. Він являє собою універсальний інструмент для всіх видів тестування продуктивності баз даних.

Продуктивність буферних пулів при «самонастройке управління пам'яттю»

Сумарний розмір всіх буферних пулів, відрегульований самонастраивающимся диспетчером пам'яті DB2, досяг 46 ГБ (з 64 ГБ фізичної пам'яті). Оскільки розмір бази даних після стиснення становив приблизно 440 ГБ, співвідношення розмірів буферних пулів та бази даних склало 10,5 відсотків (46 ГБ / 440 ГБ). На малюнку 5 показано, що буферні пули для індексів custacc і order мали результативність пошуку від 95 до 100 відсотків. Результативність пошуку для таблиць custacc і order перебувала в межах від 60 до 70 відсотків. Без стиснення DB2 ці показники результативності пошуку були б нижчими, а продуктивність - гірше.

Малюнок 5. Результативність пошуку в буферних пулах.

Продуктивність готового продукту DB2

Наскільки ж важко налаштувати DB2 для отримання продуктивності, досягнутої нами при проведенні даного тесту? Наприклад, чи дійсно необхідно мати п'ять окремих табличних просторів і буферних пулів для різних таблиць і індексів? Чи можемо ми досягти аналогічної продуктивності з використанням набагато більш простих налаштувань бази даних, ніж той сценарій DDL, який ми використовували спочатку?

У спробі відповісти на ці питання ми повторили еталонне тестування і сконфигурировали базу даних DB2, виконавши всього чотири простих кроки:

• створення бази даних з автоматичним сховищем;
• зміна місця розташування журналу на окремий шлях до сховища;
• створення окремого буферного пулу для тимчасового табличного простору;
• використання команди DB2 AUTOCONFIGURE ( «Автоматична конфігурація»), щоб система DB2 могла виконати власну настройку самостійно.

Дані кроки показані на малюнку 6. Зауважте, що ця база даних використовує лише одне встановлене за замовчуванням табличний простір і один встановлений за замовчуванням буферний пул для всіх таблиць і індексів. З такою налаштуванням змішана робоча навантаження при 200 користувачів досягла 6368 транзакцій в секунду, що всього на 6 відсотків менше, ніж показник 6763 транзакції в секунду, якого ми досягли при більш детальному конфігурації бази даних. Цей результат показує, що висока продуктивність не завжди вимагає точної експертної настройки бази даних і що внутрішні можливості настройки DB2 працюють в надзвичайно якісно.

Малюнок 6. Конфігурація бази даних за допомогою п'яти команд.

Масштабованість на багатоядерних ЦП

На малюнку 7 порівнюється пропускна здатність, вимірювана в трьох різних випадках. Ці випадки представлені нижче (зліва направо):

• 150 одночасних користувачів, чотири ЦП Intel Xeon 7300 (всього 16 ядер, 2,93 ГГц);
• 150 одночасних користувачів, чотири ЦП Intel Xeon 7400 (всього 24 ядра, 2,66 ГГц);
• 200 одночасних користувачів, чотири ЦП Intel Xeon 7400 (всього 24 ядра, 2,66 ГГц).

У першому тесті чотириядерні ЦП Intel Xeon 7300 навантажуються 150 одночасними користувачами. Робоче навантаження досягає максимальної пропускної здатності 4558 транзакцій в секунду при використанні ресурсів ЦП на 99,3%. У тесті 2 перехід з чотириядерних (Xeon 7300) на шестиядерних (Xeon 7400) ЦП збільшує частоту транзакцій для 150 користувачів на 42 відсотки при використанні ресурсів ЦП всього на 84,7 відсотка. Оскільки машина не навантажена, в тесті 3 кількість користувачів збільшується до 200. Це забезпечує використання ресурсів ЦП на 95,2 відсотка і 6763 транзакцій в секунду (приріст продуктивності шестиядерних процесорів в порівнянні з чотирьохядерними становить 48 відсотків).

Приріст продуктивності в 1,42 і 1,48 рази, показаний на малюнку 7, вражає уяву, оскільки при обліку лише кількості ядер і тактової частоти можна було б очікувати, що ЦП Intel Xeon 7400 будуть мати продуктивність в 1,36 рази вище, ніж ЦП Intel Xeon 7300. Додаткове збільшення швидкодії головним чином пояснюється наявністю кешу 3-го рівня обсягом 16 МБ, який є нововведенням в процесорах Intel Xeon серії 7400. в рівній мірі важливим є той факт, що ЦП Intel Xeon 7400 забезпечують більш високу продуктивність при збереженні то про ж рівня споживання потужності, що і у ЦП Intel Xeon 7300. Підвищення продуктивності в розрахунку на ват споживаної потужності важливо для того, щоб зробити обчислення більш економічними і рентабельними.

Малюнок 7. Масштабованість при переході з чотириядерних на шестиядерних ЦП Intel.

Продуктивність операцій вставки XML

Вставка рядків в порожню таблицю з порожніми індексами відбуватиметься значно швидше, ніж вставка в таблицю, яка вже містить великий обсяг даних. Для отримання значимої оцінки продуктивності операцій вставки XML ми вимірювали робоче навантаження тільки операцій вставки в заповнену базу даних об'ємом 1 ТБ. Тест вставки передбачав додавання 2 мільйонів документів XML в таблицю custacc і 3 мільйонів документів в таблицю order (див. Малюнок 8). Обидві таблиці мають два індекси XML. Перевірка схеми XML не проводилася. Документи custacc вставлялися зі швидкістю приблизно 4900 документів в секунду, що становить ~ 100 ГБ / год. Менш об'ємні документи order вставлялися зі швидкістю 11900 документів в секунду, або 69 ГБ / год. Для документів обох типів тести вставки передбачали використання 600 одночасних користувачів, які видавали оператори вставки без пауз на обдумування. Фіксація виконувалася після кожної окремої вставки. Менш часті фіксації або використання утиліти контролю навантаження DB2 можуть забезпечувати ще більш високі швидкості введення XML.

Малюнок 8. Продуктивність інкрементних операцій вставки XML.

отримані уроки

Які ж уроки ми витягли з вивчення продуктивності XML об'ємом 1 ТБ? Крім фактичних результатів тестування продуктивності і масштабованості, цінними є ще кілька спостережень.

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

Необхідною передумовою досягнення гарної продуктивності є збалансовані апаратні засоби, т. Е. Використання «правильного» співвідношення між кількістю ядер ЦП, об'ємом оперативної пам'яті і кількістю дисків. При використанні 24 ядер, 64 ГБ пам'яті і 120 дисків для зберігання даних наша тестова система мала по 5 дисків і по 2,66 ГБ пам'яті на одне ядро. Оптимальне співвідношення залежить від робочого навантаження. В умовах змішаної робочого навантаження TPoX ми спостерігали в середньому по 1,7 запиту фізичного введення-виведення на одну транзакцію. Таким чином, при піковому частоті 6763 транзакції в секунду система зберігання була змушена витримувати приблизно 11500 операцій введення-виведення в секунду (IOPS). Відповідно до емпіричним правилом про те, що сучасний диск SCSI може підтримувати приблизно 100 IOPS при помірно малих затримках, для запобігання ситуацій з нестачею ресурсів введення-виведення і забезпечення високого коефіцієнта використання ресурсів ЦП необхідно приблизно 115 дисків.

Стиснення DB2 грало критично важливу роль. Без стиснення для досягнення тієї ж продуктивності треба було б більше дисків і пам'яті. Стиснення забезпечило скорочення необхідної кількості ресурсів введення-виведення, і це перевага значно переважує потреба в додатковій кількості циклів ЦП для стиснення та розпакування даних.

Для розуміння характеристик продуктивності бази даних вкрай корисними виявилися контроль моментальних знімків DB2 і створення моментальних знімків через однакові проміжки часу, наприклад через кожні 5 хвилин. Таким чином, зібрані дані дозволяють вам аналізувати характеристики введення-виведення і очищення сторінок з плином часу.

Для систем Linux і UNIX DB2 9.5 має модель процесів, що докорінно відрізняється від DB2 9.1. У той час як DB2 9.1 породжує окремий процес для кожного агента, DB2 9.5 працює в якості окремого процесу, що має по одному потоку на агента.Наші результати підтверджують, що механізм організації потокової обробки DB2 використовує ресурси багатоядерних ЦП з високим ступенем ефективності і досягає хороших показників збільшення швидкодії при переході з 4-ядерних процесорів Intel Xeon на 6-ядерні.

Ресурси для скачування

Схожі тими

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів