Помещение Oracle Redo Logs на DRAM SSD для тяжелой базы данных записи?

У меня Sun M4000 подключен к массиву EMC CX4-120 с базой данных с интенсивной записью. Пиковая запись на уровне 1200 IO / с и 12 МБ / с.

Согласно EMC, я насыщаю кэш записи в массиве EMC.

Я думаю, что самое простое решение - переместить журналы повторов в SSD на основе DRAM. Это снизит нагрузку на массив EMC вдвое, и приложения не будут ожидать буфера журнала. Да, DBWR может стать узким местом, но приложения не будут его ждать (как они делают при повторных фиксациях!)

В настоящее время я перебираю около 4 4 ГБ журналов повторов, так что даже 20 ГБ или около того SSD будет иметь большое значение. Поскольку это кратковременное хранилище, которое постоянно перезаписывается, флэш-накопители на базе Flash, вероятно, не очень хорошая идея.

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

Sun продает карту Flashe Accelerator F20 PCIe, но, похоже, это кеш для некоторых дисков SATA, а не решение DRAM 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 и посмотрите ваши события ожидания, вы, вероятно, ожидаете много как READ, так и WRITE для данных / индексов. Ожидание чтения замедляет INSERT, а операция WRITE делает чтения еще медленнее - это те же диски (кстати, вам действительно нужны все индексы? Удаление тех, кто не должен иметь, ускорит вставки).

Еще одна вещь, которую нужно проверить, - это определение RAID - это RAID1 (зеркальное отображение - каждая запись - две записи) или RAID 5 (каждая запись - 2 чтения и две записи для вычисления контрольной суммы). RAID 5 намного медленнее при интенсивной записи.

КСТАТИ - если диски не могут справиться с загрузкой записи, DBWR будет узким местом. Ваш SGA будет заполнен грязными блоками, и у вас не останется места для чтения новых блоков (например, индексных блоков, которые необходимо обработать / обновить), пока DBWR не сможет записать некоторые грязные блоки на диски. Опять же, проверьте statspack / awr report / addm, чтобы определить узкое место, обычно основанное на 5 лучших событиях ожидания.

дд ничто по сравнению с блоком ввода / вывода.

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

Но да, если RAID 5 и RAID 10 одинаковы (для записи), вы делаете что-то не так. С линейной записью хек RAID 5 может быть быстрее (то есть он может выполнять четность в памяти, а затем записывать полосы и четность одновременно), но при случайном маленьком блоке (4-8 Кб) вы убиваетесь, обновляя полосы (как отмечается другими), рейд 10 должен быть более чем в 2 раза быстрее, если нет, то что-то не так.

Вы должны копать глубже, прежде чем тратить деньги на оборудование.

Я видел пост о монтировании разделов UFS с использованием опции «requiredirectio» и установке параметра Oracle «filesystemio_options» на «setall».

Я попробовал и увидел улучшение в 4-5 раз в Oracle пишет! Да!

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

Я могу рассмотреть SSD для новых серверов, но сейчас этот сервер работает нормально.

Роберт

Если бы этот блок был только x86 / 64 с Linux, я бы с радостью порекомендовал одну из карт FusionIO PCIe - они удивительно быстрые и не «умирают» при тяжелых записях, как это делают SSD. К сожалению, они не поддерживаются ни Sparc, ни Solaris, вы можете связаться с ними, чтобы обсудить это.

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