我的同事们正在与Netapp和甲骨文公司进行合作 – 但是我认为我会在这里发布其他人看到这个的机会
我们有一台运行Oracle 11i的RedHat 5虚拟机（完全是最新版本），使用Oracle推荐的挂载选项通过VM的linux内核NFS挂载数据磁盘，性能非常不稳定（Querys应该less于2秒，有时需要超过60秒）
有趣的是，我们可以一致地运行相同的查询<2秒，驻留在同一个NetApp NFS数据存储上的VMDK！
让我希望甲骨文和NetApp与VMware和NetApp在我们用来完美设置NFS选项并保持合规的虚拟存储控制台上紧密合作。
我们已经尝试了一些其他人发布的Linux NFS选项，到目前为止还没有看到改进。
我们现在正在为虚拟机创buildVMDK，以取代已安装的Linux NFS，并解决了这个问题，因为我们的开发人员需要一致的性能尽快。
我们看到与Oracle Unbreakable Linux 5.4，Oracle 11gR2和OnTap 7.3.2相同的行为。 与通过VMDK访问相同的存储（使用相同的底层ESX主机通过VMKernel挂载NFS）相比，挂载“原始”NFS要慢得多。 “原始”NFS卷和NFS数据存储都在相同的聚合中，因此也是相同的主轴等。
我们不想改变使用块存储或VMDK，因为这将改变我们的备份和灾难恢复战略，更不用说支持要求了。 我会发布任何解决scheme，我发现在这里或如果有人可以贡献请发布！
问候，
Ed Grigson
更新：我们解决了我们的情况 – 这是NFS挂载选项，特别是与“actimeo”参数组合的“noatime”参数。 设置'noatime'而不使用'actimeo = 0'为我们解决了它。
我们使用的mount选项actimeo = 0closures了客户端上的属性caching。 这意味着客户端始终拥有来自服务器的最新文件属性，但是由于物理IO增加，导致延迟增加。 在安装过程中，我们的性能问题最为严重，因为我们正在扩展.ZIP文件和更新数千个date戳。 通过在客户端安装选项和Netapp卷属性上使用“noatime”来禁用date戳更新，我们可以避免这个问题。 注：actimeo的行为在2.4和2.6 Linux内核之间有所不同，这也是为什么可能不会很快遇到的另一个原因。 注意：“actimeo = 0”是Oracle推荐的Oracle 10gR2参数，但是没有关于在Oracle上运行的Websphere的指导。 https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb7518