尝试使用 SQL Server 等待和队列调整 Sharepoint 站点

Question

我对使用 Waits 和 Queues 进行性能调整还很陌生 - 很吸引人，但也不总是那么直观......

现在，我的一个客户有一个 SQL Server 2008 64 位企业版，目前分配给它 16 GB 的 RAM，在具有 64 GB RAM 的物理服务器上运行（在同一台上还有其他和更改的 SQL Server 实例）机）。

他正在运行的这个应用程序是一个 Sharepoint 2010 解决方案，在大多数情况下，它的性能 - 很好 - 对于 Sharepoint 站点来说还可以。除了搜索，这是非常缓慢的。

现在从 SQL Server 的角度来看，我已经观察了几天的等待统计数据，前三种等待类型是：

1) CXPACKET 约为 49%
2) SOS_SCHEDULER_YIELD 约为 10.5%
3) OLEDB 约为 9.5%

这似乎非常一致——随着时间的推移没有大的变化。

• PAGEIOLATCH_SH 排在第七位 - 占总等待时间的 2.5%，平均资源等待时间为 14 毫秒。
• ASYNC_IO_COMPLETION 有八个——不到总等待时间的 2%，但平均资源等待时间高达 38 秒（是的，秒——不是毫秒！）

信号等待时间极短，所以这似乎并不表示 CPU 压力。那么是什么导致了这种模式——我们可以做些什么来 (a) 找到更多相关信息，或 (b) 找到加快速度的解决方案？

有什么想法吗？见解？想法？我对任何事情都持开放态度——我们不能改变的是基本架构（单独的 SQL Server 实例，在物理服务器之间移动——以及基于 Unix 的 SAN，它不能保证数据和登录到单独的物理磁盘上的分离）

再说一遍：这是一个SharePoint网站 - 据我所知，尝试通过索引或重组数据库来解决问题是困难和不可能之间的事情。

Answer 1

因为这是 SharePoint，所以您的手被束缚了。您无法在不失去 Microsoft 支持的情况下创建索引或统计信息。

CXPACKET 只是意味着并行查询的一个线程正在等待另一个线程完成等待其他线程。SOS_SCHEDULER_YIELD 可能意味着一些事情，通常这意味着您需要修复索引，因为您有未正确调整的查询，因此 SQL Server 正在暂停这些查询（产生它们），以便它可以处理其他内容（如下所示）是 SharePoint，您对此无能为力）。OLEDB 意味着 SQL Server 正在等待 OLEDB 驱动程序，因此可能存在链接服务器查询或沿着这些线路调用另一个数据库服务器的内容。对此你也无能为力。

从这听起来像是没有投入更多硬件来解决问题，您几乎无能为力。使用 Profiler、Server Side Tracing 或 Extended Events，找出运行时间很长的查询，检查它们的执行计划，看看它们有多糟糕。很可能那些搜索查询正在执行大型扫描操作。

内容数据库有多大？Microsoft 建议将内容数据库保持在 100 Gig 以下，以便将扫描保持在最低限度。