Поміщення повторних журналів Oracle на DRAM SSD для великої бази записів?

У мене Sun M4000, підключений до масиву EMC CX4-120 з базовою базою даних для запису. Записує пік близько 1200 IO / s та 12MB / s.

Згідно EMC, я насичую кеш-запис на масиві EMC.

Я думаю, що найпростішим рішенням є переміщення повторних журналів на SSD на основі DRAM. Це зменшить навантаження на масив EMC вдвічі, і програми не побачать буфер журналу очікування. Так, DBWR може стати вузьким місцем, але програми не чекатимуть його (як це робиться при повторних комісіях!)

В даний час я перебираю близько 4 повторних журналів 4 Гб, тому навіть 20 Гб або близько SSD буде мати велике значення. Оскільки це короткочасне зберігання та постійно перезаписується, SSD-накопичувачі на базі Flash, мабуть, не чудова ідея.

У M4000 немає зайвих наборів накопичувачів, тому PCI-E карта була б ідеальною, я міг би вийти назовні або перемістити обсяги завантаження на EMC та звільнити локальні диски.

Sun продає карту Flash Accelerator F20 PCIe, але, схоже, це кеш для деяких SATA дисків, а не рішення DRD SSD. Деталі є схематичними, він не вказує M4000 на підтримку, і я втомився боротися з телефонним деревом Sun, шукаючи допомоги людини. :(

Чи згодні інші, що DRAM SSD - це шлях? Якісь технічні рекомендації?

ОНОВЛЕННЯ Окрім інформації в коментарі нижче, я спробував різні налаштування для "commit_write", і це не змінило значення.

По-перше - я думаю, у вас дуже мало дисків в масиві. 1200IOPS можна легко підтримувати на 12 спінінг-дисках (100 IOPS на диск дуже розумно). Якщо кеш не може впоратися з цим, це означає, що ваша швидкість запису 1200 IOPS набагато більше, ніж можуть підтримувати ваші диски.

У будь-якому випадку, SSD для повторних журналів, ймовірно, не допоможе. По-перше, чи чекаєте ви сесії переважно на заяву COMMIT? Перевірте основні події очікування в statspack / AWR, щоб перевірити. Я б здогадався, ~ 95% ваших вводу-виводу взагалі не відновлені до журналів повторень. Наприклад, одна вставка рядка до таблиці з 5 індексами може зробити 1 введення / вивід для читання блоку таблиці (у якому є простір для рядка), прочитати 5 блоків індексів (оновити їх), написати 1 блок даних, 1 скасувати блок та 5 блоків індексів (або більше, якщо оновлені нелистові блоки) та 1 повторний блок. Отже, перевірте statspack і побачите ваші події очікування, ви, ймовірно, чекаєте багато, як READs та WRITEs для даних / індексів. Очікування читання сповільнює ВСТУП, і активність WRITE робить ЧИТАННЯ ще повільнішими - це ті ж самі диски (BTW - чи справді вам потрібні всі індекси? Відкидання тих, хто цього не повинен мати, прискорить вставки).

Інша річ, яку слід перевірити, це визначення RAID - це RAID1 (дзеркальне відображення - кожне записування - це два записи) або RAID 5 (кожне записування - 2 читання, а два - для розрахунку контрольної суми). RAID 5 набагато повільніше при навантаженні, що інтенсивно записує.

BTW - якщо диски не зможуть перестати завантажувати запис, DBWR буде вузьким місцем. Ваша SGA буде заповнена брудними блоками, і у вас не залишиться місця для читання нових блоків (наприклад, індексних блоків, які потрібно обробляти / оновлювати), поки DBWR не зможе записати кілька брудних блоків на диски. Знову ж таки, перевірте statspack / awr звіт / addm, щоб діагностувати, що є вузьким місцем, як правило, виходячи з перших 5 подій очікування.

dd - це ніщо в порівнянні з блоком вводу-виводу.

Для деяких інших поглядів, перегляньте, anandtech.com зробив обширний тест (наданий MS SQL-сервер) з SAS, що обертається проти SSD, в різних комбінаціях, а світ Solaris має ZFS з SSD, що складається з різних частин (журнали, кеш і т.д. ).

Але так, якщо RAID 5 проти RAID 10 однаковий (для записів), ви робите щось не так. При лінійному записі heck RAID 5 може бути швидшим (тобто він може зробити паритет у пам'яті, потім записати смуги і парність всі відразу), але з випадковим невеликим блоком (4-8k), ви вбиваєтесь оновленням смуг (як зауважили інші), рейд 10 повинен бути більш ніж в 2 рази швидше, якщо ні, то щось не так.

Вам потрібно копати глибше, перш ніж витрачати гроші на обладнання.

Я побачив публікацію про встановлення UFS-розділів за допомогою параметра "forcedirectio" та встановлення параметру Oracle "filesystemio_options" на "setall".

Я спробував це і побачив покращення в 4-5 разів у написанні Oracle! Так!

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

Я можу розглянути SSD для нових серверів, але цей сервер зараз працює нормально.

Роберт

Якби ця скринька була лише коробкою x86 / 64 під управлінням Linux, я б із задоволенням порекомендував одну з флеш-карток FusionIO PCIe - вони дивно швидкі і не «вмирають» з важкими записами, як це роблять SSD. На жаль, вони не підтримуються ні Sparc, ні Solaris, ви можете зв’язатися з ними, щоб обговорити це.

Картка F20e PCIe за функцією схожа на функцію Fusion I / O. Це в основному лише PCIe, прикріплений до Flash SSD. З великим навантаженням для запису вам потрібно буде турбуватися як про підтримку достатньої кількості вільних блоків (через збирання сміття на базі накопичувача), щоб ви не закінчилися циклом стирання / Програми на SSD, що став вузьким місцем, а також обмежені цикли запису, доступні на флеш-диску SSD. Це, безумовно, швидко, але, можливо, не найкращий комплект для цієї роботи.