SharePoint 2010 服务器场性能下降答案

【问题标题】：SharePoint 2010 farm performance degradationSharePoint 2010 服务器场性能下降
【发布时间】：2014-04-14 20:15:01
【问题描述】：

在 SharePoint 2010 中开发 - 已安装所有最新更新（SP2 等）

具有 2 台应用程序服务器、2 台前端服务器、Active Directory 服务器和 2 台 SQL 服务器的标准场。所有这些东西都由虚拟网络中的 Windows Azure 虚拟机托管。

在执行简单的SPWebApplication.Lookup() 时注意到它需要非常非常长的时间才能完成 - 大约 16 秒。比较 - 在本地大约需要 1 秒。在另一个非常相似的场上，也托管在 Azure 中 - 大约 2 秒。

为解决性能下降问题做了哪些尝试：

已检查配置和网络设置、ping 等 - 看起来 100% 正常。
使用 SQL Profiler 进行分析 - 未发现瓶颈 - 实际上此请求没有硬 SQL。
仔细检查所有服务器和数据库是否已升级并保持最新状态。
消除在 ULS 和 Windows 日志中发现的所有可能的错误 - 现在已经很清楚了。
使用 Metalogix 诊断管理器调查指标 - 结果未发现任何关键问题。它只是有时表明处理器队列长度很大。但据我所知，它的正常数字是#of cores +1。所以在我的情况下4-5很好。另外需要注意的是，从我的角度来看——对于虚拟机来说，有这样的数字也是正常的。
编写了非常简单的控制台应用程序来执行 Web 应用程序的查找。使用 Ants 分析器进行分析。注意到调用树与本地收到的结果不同。也许没关系，因为在本地我有独立安装。农场的结果并不乐观 - 几个电话有大量的点击数。不过，调用树中的瓶颈在哪里很清楚——所有关于源的想法都已经完成。分析结果如下：http://1drv.ms/1kYT3rT

如果您能提供建议，那就太好了。

提前致谢。

【问题讨论】：

配置数据库的大小是多少？
3 个数据库：11.5GBs、1.5GBs 和 40MBs - 这实际上很好。一种内容数据库大小的最佳实践约为 100GB。查看 ant profiler 调用树 - 它看起来不像 SQL 问题。
我的意思是共享点配置数据库而不是内容数据库。它的名称类似于“SharePoint_Config”。之前当 timerjob 历史表变得很大时，我遇到了问题。
哦，抱歉 - 不匹配。大约 500MB。

【解决方案1】：

您的虚拟机上有多少个磁盘？

Azure 的 IOPS 有限，每个磁盘 500...组织您的数据库，使它们位于不同的磁盘上以获得更多 IOPS。每个 VM 可以有 16 个磁盘。

【讨论】：

是的，我知道这一点。 SQL 现在在这个环境中有 4 个单独的磁盘。我可以同意这样的理论，但是一次查找没什么大不了的，也不会产生很大的工作量。还要注意类似的环境，只有一张用于 SQL 的磁盘 - 在 1-2 秒内执行查找。