У меня есть Sun M4000, подключенный к массиву EMC CX4-120 с тяжелой для записи базой данных. Пик записи составляет около 1200 операций ввода-вывода в секунду и 12 МБ / с.
По данным EMC, я насыщаю кэш записи на массиве EMC.
Я думаю, что самое простое решение - переместить журналы повтора на SSD на базе DRAM. Это снизит нагрузку на массив EMC наполовину, и приложения не будут видеть ожидания буфера журнала. Да, DBWR может стать узким местом, но приложения не будут ждать его (как они делают при повторных коммитах!)
В настоящее время я просматриваю около 4 журналов повтора по 4 ГБ, поэтому даже 20 ГБ SSD будут иметь большое значение. Поскольку это краткосрочное хранилище и оно постоянно перезаписывается, SSD на основе Flash, вероятно, не лучшая идея.
У M4000 нет дополнительных дисков, поэтому карта PCI-E была бы идеальной, я мог бы пойти на внешний или переместить загрузочные тома в EMC и освободить локальные диски.
Sun продает карту Flash Accelerator F20 PCIe, но, похоже, это кэш для некоторых дисков SATA, а не решение DRAM SSD. Подробности отрывочны, M4000 не указан как поддерживаемый, и я устал бороться с деревом телефонов Sun в поисках помощи человека. :(
Согласны ли другие с тем, что SSD с DRAM - лучший выбор? Есть рекомендации по оборудованию?
ОБНОВИТЬ В дополнение к информации в комментарии ниже, я пробовал различные настройки для "commit_write", и это не имело значения.
Во-первых, я думаю, что у вас очень мало дисков в массиве. 1200IOPS может легко поддерживаться 12 вращающимися дисками (100 IOPS на диск очень разумно). Если кеш не может справиться с этим, это означает, что ваша постоянная скорость записи 1200 IOPS намного больше, чем могут поддерживать ваши диски.
В любом случае SSD для журналов повтора вряд ли поможет. Во-первых, ваш сеанс в основном ожидает выполнения оператора COMMIT? Проверьте самые популярные события ожидания в statspack / AWR, чтобы убедиться. Я бы предположил, что ~ 95% ваших операций ввода-вывода вообще не относятся к журналам повторного выполнения. Например, вставка одной строки в таблицу с 5 индексами может выполнить 1 ввод-вывод для чтения блока таблицы (в котором есть место для строки), чтения 5 блоков индекса (для их обновления), записи 1 блока данных, 1 отмены блок и 5 индексных блоков (или больше, если обновляются нелистовые блоки) и 1 блок повтора. Итак, проверьте пакет статистики и посмотрите свои события ожидания, вы, вероятно, ждете много как READ, так и WRITE для данных / индексов. Ожидание чтения замедляет INSERT, а активность WRITE делает READ еще медленнее - это те же диски (BTW - вам действительно нужны все индексы? Удаление тех, которые не нужны, ускорит вставку).
Еще одна вещь, которую нужно проверить, - это определение RAID - это RAID1 (зеркальное отображение - каждая запись - это две записи) или RAID 5 (каждая запись - это 2 чтения и две записи для расчета контрольной суммы). RAID 5 намного медленнее при интенсивной записи.
Кстати - если диски не могут справиться с нагрузкой записи, DBWR будет узким местом. Ваш SGA будет заполнен грязными блоками, и у вас не останется места для чтения новых блоков (например, индексных блоков, которые необходимо обработать / обновить), пока DBWR не сможет записать некоторые грязные блоки на диски. Опять же, проверьте statspack / awr report / addm, чтобы определить узкое место, обычно на основе пяти основных событий ожидания.
Я видел сообщение о монтировании разделов UFS с использованием опции «принудительное направление» и установке параметра Oracle «filesystemio_options» на «setall».
Я попробовал и увидел улучшение записи Oracle в 4-5 раз! Да!
Ключевыми симптомами были низкая пропускная способность, но хорошее время отклика на диске. Кажется, это помогает одним людям, но не другим. Это определенно помогло мне.
Я могу рассмотреть SSD для новых серверов, но сейчас этот сервер работает нормально.
Роберт
dd - ничто по сравнению с блочным вводом-выводом.
Для некоторых других представлений проверьте, anandtech.com провел исчерпывающий тест (предоставленный с сервером MS SQL) с вращением SAS против SSD в различных комбинациях, а в мире Solaris есть ZFS с SSD, составляющими различные части (журналы, кеш и т. ).
Но да, если RAID 5 и RAID 10 одинаковы (для записи), вы делаете что-то не так. С линейной записью, черт возьми, RAID 5 мог бы быть быстрее (то есть он может выполнять четность в памяти, а затем записывать полосы и четность сразу), но со случайным маленьким блоком (4-8k) вы убиваетесь, обновляя полосы (как отметили другие), рейд 10 должен быть более чем в 2 раза быстрее, если нет, то что-то не так.
Вам нужно копнуть глубже, прежде чем тратить деньги на оборудование.
Если бы этот бокс был только блоком x86 / 64, работающим под Linux, я бы с радостью порекомендовал одну из карт накопителей FusionIO PCIe - они удивительно быстрые и не «умирают» при тяжелой записи, как SSD. К сожалению, они не поддерживаются ни Sparc, ни Solaris, но вы можете связаться с ними, чтобы обсудить это.
Карта F20e PCIe по функциям похожа на Fusion I / O. По сути, это просто флэш-SSD, подключенный к PCIe. При большой рабочей нагрузке записи вам нужно будет беспокоиться как о поддержании достаточного количества свободных блоков (через сборку мусора на основе какого-либо вида), чтобы цикл стирания / программирования на SSD не стал узким местом, а также ограниченные циклы записи, доступные на SSD на базе флэш-памяти. Это определенно быстро, но, возможно, не лучший комплект для этой работы.