Oracle на NFS vmdk бьет родной NFS?
Мои коллеги занимаются этим с Netapp и Oracle - но я подумал, что я опубликую здесь на случай, если кто-то еще видел это
У нас есть виртуальная машина RedHat 5 (полностью обновленная), на которой работает Oracle 11i с дисками данных, смонтированными через ядро Linux Linux NFS с использованием рекомендуемых параметров монтирования Oracle, и производительность очень противоречива (запросы, которые могут занимать < 2 секунды, иногда занимают> 60 секунд)
Самое смешное, что мы можем выполнять одинаковые запросы совершенно последовательно < 2 секунды в VMDK, находящемся в одном и том же хранилище данных NFS NetApp!
Я хотел бы, чтобы Oracle и NetApp сотрудничали так же тесно, как VMware и NetApp на консоли Virtual Storage Console, которую мы использовали для идеальной настройки параметров NFS и обеспечения их соответствия...
Мы опробовали несколько вариантов Linux NFS, опубликованных другими, и пока не увидели улучшения.
Сейчас мы создаем VMDK для виртуальной машины, чтобы заменить смонтированную Linux NFS и обойти эту проблему, поскольку нашим разработчикам нужна стабильная производительность как можно скорее.
1 ответ
Мы видим такое же поведение с Oracle Unbreakable Linux 5.4, Oracle 11gR2 и OnTap 7.3.2. Монтирование "сырой" NFS намного медленнее по сравнению с доступом к тому же хранилищу через VMDK (с использованием того же базового хоста ESX, монтирующего NFS через VMKernel). И "сырые" тома NFS, и хранилище данных NFS находятся в одном агрегате и, следовательно, в одних и тех же шпинделях и т. Д.
Мы не хотим переходить на использование блочного хранилища или VMDK, поскольку это изменит нашу стратегию резервного копирования и аварийного восстановления, не говоря уже о требованиях к поддержке. Я опубликую любое решение, которое найду здесь, или, если кто-то еще может помочь, пожалуйста, напишите!
С Уважением,
Эд Григсон
ОБНОВЛЕНИЕ: Мы решили наш случай - это были параметры монтирования NFS, в частности параметр noatime в сочетании с параметром actimeo. Установка noatime и НЕ использование actimeo=0 решили эту проблему для нас.
Используемая нами опция монтирования actimeo=0 отключает кэширование атрибутов на клиенте. Это означает, что клиент всегда имеет последние атрибуты файла с сервера, но за счет увеличения задержек из-за увеличения физического ввода-вывода. Наша проблема с производительностью была наиболее острой во время установки, потому что мы расширяли файлы.ZIP и обновляли тысячи отметок даты. Используя noatime (как в параметрах монтирования клиента, так и в свойствах тома Netapp), чтобы отключить обновления с отметкой даты, мы избегаем этой проблемы. ПРИМЕЧАНИЕ. Поведение actimeo варьируется между ядрами Linux версии 2.4 и 2.6, что является еще одной причиной, по которой это не могло произойти раньше. ПРИМЕЧАНИЕ. "Actimeo = 0" - это рекомендуемый параметр Oracle для Oracle 10gR2 в Linux, но нет никаких рекомендаций для Websphere, работающей в Oracle. https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb7518