мои коллеги занимаются этим с NetApp и Oracle, но я подумал, что опубликую здесь, если кто-то еще видел это
У нас есть виртуальная машина RedHat 5 (полностью обновленная), на которой запущен Oracle 11i с дисками данных, смонтированными через NFS ядра Linux виртуальной машины с использованием рекомендуемых параметров монтирования Oracle, и производительность очень непостоянна (запросы, которые должны занимать <2 секунд, иногда занимают> 60 секунд)
Забавно то, что мы можем выполнять одни и те же запросы совершенно последовательно <2 секунд на VMDK, находящемся в ТАКОМ хранилище данных NetApp NFS!
Заставляет меня пожелать, чтобы Oracle и NetApp сотрудничали так же тесно, как VMware и NetApp, над консолью виртуального хранилища, которую мы использовали для идеальной настройки параметров NFS и обеспечения их соответствия ...
Мы попробовали несколько опций Linux NFS, опубликованных другими, и пока не заметили улучшений.
Сейчас мы создаем VMDK для виртуальной машины, чтобы заменить смонтированную NFS Linux и решить проблему, поскольку нашим разработчикам требуется стабильная производительность как можно скорее.
Мы наблюдаем такое же поведение с 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