我的同事正在与 Netapp 和 Oracle 合作，但我想在这里发布一下，希望其他人能看到这个
我们有一台 RedHat 5 VM（完全最新），运行 Oracle 11i，数据磁盘通过 VM 的 Linux 内核 NFS 使用 Oracle 推荐的挂载选项挂载，性能非常不一致（应该花费 <2 秒的查询有时需要 >60 秒）
有趣的是，我们可以在位于相同 NetApp NFS 数据存储上的 VMDK 上完美一致地运行相同的查询，所需时间不到 2 秒！
我希望 Oracle 和 NetApp 能够像 VMware 和 NetApp 在虚拟存储控制台上那样紧密合作，以便我们完美地设置 NFS 选项并保持它们的合规性......
我们尝试了其他人发布的一些 Linux NFS 选项，但到目前为止尚未看到改善。
我们现在正在为 VM 创建 VMDK 来替换已安装的 Linux NFS 并解决该问题，因为我们的开发人员需要尽快获得一致的性能。
答案1
我们发现 Oracle Unbreakable Linux 5.4、Oracle 11gR2 和 OnTap 7.3.2 也存在同样的行为。与通过 VMDK 访问同一存储（使用通过 VMKernel 安装 NFS 的同一底层 ESX 主机）相比，安装“原始”NFS 的速度要慢得多。“原始”NFS 卷和 NFS 数据存储区都位于同一聚合中，因此具有相同的主轴等。
我们不想改用块存储或 VMDK，因为这会改变我们的备份和 DR 策略，更不用说支持要求了。我会在这里发布我找到的任何解决方案，或者如果其他人可以贡献，请发布！
问候，
艾德·格里格森
更新：我们解决了这个问题 - 是 NFS 挂载选项的问题，特别是“noatime”参数与“actimeo”参数的组合。设置“noatime”而不是使用“actimeo=0”为我们解决了这个问题。
我们使用的安装选项 actimeo=0 关闭了客户端上的属性缓存。这意味着客户端始终具有来自服务器的最新文件属性，但代价是延迟增加，因为物理 IO 增加了。我们的性能问题在安装期间最为严重，因为我们要扩展 .ZIP 文件并更新数千个日期戳。通过使用“noatime”（在客户端安装选项和 Netapp 卷属性上）禁用日期戳更新，我们避免了此问题。注意：actimeo 的行为在 2.4 和 2.6 Linux 内核之间有所不同，这也是为什么可能不会更早遇到此问题的另一个原因。注意：'actimeo=0' 是 Oracle 为 Linux 上的 Oracle 10gR2 推荐的参数，但没有针对在 Oracle 上运行的 Websphere 的指导。https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb7518