通过

估计 SharePoint Server 2010 搜索的性能和容量要求

  • 项目

 

适用于： SharePoint Server 2010

上一次修改主题： 2016-11-30

摘要：本文针对 Microsoft SharePoint Server 2010 搜索的不同部署（包括小型、中型和大型 SharePoint Server 2010 服务器场）提供容量规划信息。

本文针对 SharePoint Server 2010 搜索的协作环境部署提供容量规划信息。其中包括以下用于三个示例搜索服务器场配置的信息：

  • 测试环境规范，例如硬件、服务器场拓扑和配置

  • 用于生成数据的工作量，包括用户的数量和种类以及服务器场使用特征

  • 测试服务器场数据集，包括数据库内容和大小

  • 特定于测试环境的运行状况和性能数据

本文还包含一般测试数据和建议，其中涉及如何确定部署类似环境所需要的硬件、拓扑和配置，以及如何针对相应的容量和性能特征优化环境。

与早期版本相比，SharePoint Server 2010 搜索提供了更丰富的功能集和更灵活的拓扑模型。在使用这一体系结构向用户提供更强大的功能之前，您必须认真考虑将对服务器场的容量和性能产生的影响。

阅读本文之后，您将了解如何执行以下操作：

  • 为环境定义性能和容量目标。

  • 规划支持用户的数量和类型所需要的硬件以及您打算部署的功能。

  • 设计物理和逻辑拓扑，以实现最佳可靠性和效率。

  • 测试、验证和缩放环境，以实现性能和容量目标。

  • 监视环境以了解重要指标。

在阅读本文之前，应熟悉以下内容：

规划概述

本文中的方案介绍了小型、中型和大型测试服务器场，并且假设这些方案有助于您开始为服务器场规划正确的容量。这三种服务器场规模是根据以下假设近似得出的：

  • 爬网的存储库主要是 SharePoint Server 内容。

  • 大多数用户查询都可在索引中相同的 33% 的内容中找到。这意味着大部分用户查询的术语都相同。

  • 使用默认元数据设置，以确保属性数据库的增长速度不会太快。

  • 在中型和大型服务器场中，存在可为这些搜索服务器场的爬网组件提供内容的专用爬网目标（前端 Web 服务器）。

  • 在这些服务器场中进行的度量会因网络和环境条件而异，最多允许 10% 的误差范围。

选择方案

若要选择正确的方案，请考虑以下问题：

  • 文档集大小   有多少内容必须可搜索？总项目数应包括文档、网页、列表项和人员等所有对象。

  • 可用性   可用性要求是什么？客户是否需要一个可以排除特定服务器故障的搜索解决方案？

  • 内容新鲜度   您希望搜索结果的新鲜度如何？您希望搜索可在用户更改内容后多长时间在结果中提供更新的内容？您希望内容更改的频率是多久？

  • 吞吐量   将会有多少用户同时搜索内容？这包括用户在查询框中键入内容，隐藏查询（如 Web 部件）自动搜索数据，或 Microsoft Outlook 2010 Social Connectors 请求包含需要从搜索系统进行安全修整的 URL 的活动源。

根据这些问题的答案，选择以下方案之一：

  • 小型服务器场   包括在单个 SharePoint Server 服务器场中共享一些资源的单个 Search Service 应用程序。通常对于小型部署而言，针对其提供搜索的内容量有限（少于一千万个项目）。根据所需的新鲜度目标，在营业时间可能发生增量爬网。

  • 中型服务器场   在一个专用服务器场中包括一个或多个 Search Service 应用程序，后者可向其他服务器场提供搜索服务。针对其提供搜索的内容量适中（最多为四千万个项目），并且为了满足新鲜度目标，在营业时间可能会发生增量爬网。

  • 大型服务器场   在一个专用服务器场中包括一个或多个 Search Service 应用程序，后者可向其他服务器场提供搜索服务。针对其提供搜索的内容量很大（最多为一亿个项目），并且为了满足新鲜度目标，可能会在工作时间发生增量爬网。

搜索生命周期

通过这三个方案，您可以在服务器场的早期阶段估计容量。在爬网过程中，服务器场会经历搜索生命周期的以下阶段：

  • 索引获取   这是数据填充的第一个阶段。此阶段的持续时间取决于内容源的大小。此阶段具有以下特征：

    • 内容的完全爬网（可能是并发的）。

    • 密切监视爬网系统，以确保被爬网主机没有成为爬网的瓶颈。

    • 在更改一定量的索引时为每个查询组件触发的频繁主合并。

  • 索引维护   这是服务器场的最常用阶段。此阶段具有以下特征：

    • 存在所有内容的增量爬网。

    • 对于 SharePoint Server 内容爬网，在爬网过程中遇到的大多数更改都是安全更改。

    • 在更改一定量的索引时为每个查询组件触发的非频繁主合并。

  • 索引清理   当内容更改将服务器场移出索引维护阶段时，会发生此阶段 — 例如，在将内容数据库或网站从一个 Search Service 应用程序移至其他 Search Service 应用程序时。当以下任一情况发生时，会触发此阶段：

    • 搜索爬网程序在较长时间段内找不到提供内容的主机。

    • 从 Search Service 应用程序中删除内容源或开始地址。

方案

本节介绍用于小型、中型和大型服务器场方案的配置。其中还包括用于每个环境的工作量、数据集、性能数据和测试数据。

小型服务器场

由于服务器场很小，因此有些服务器必须执行多个角色。建议您将查询组件与前端 Web 服务器组合，以避免将爬网组件和查询组件放在同一服务器上。此配置使用三台应用程序服务器和一台数据库服务器，如下所述：

  • 由于通常会为企业级搜索建议冗余查询服务器，所以在提供以下配置时，会对查询组件使用两台应用程序服务器：

    • 一台应用程序服务器同时托管搜索中心。如果将小型服务器场用作服务服务器场，则可忽略此配置，并且会在从此父服务服务器场中使用 Search Service 应用程序的子内容服务器场中创建搜索中心。

    • 对于少于一千万个项目的情况，首选的查询配置是具有一个索引分区。然后，每台服务器都会在索引分区中有一个主查询组件。这种活动/活动查询组件设置允许其中一个查询组件出现故障，此时仍保留从其余查询组件中提供查询服务的能力。如果一个查询组件出现故障，搜索会将查询（循环）发送到下一个可用的查询组件。

  • 一台应用程序服务器用于爬网和管理。这意味着将在此服务器上创建管理中心、搜索管理组件和爬网组件。

  • 支持服务器场的单个数据库服务器。该数据库服务器应具有专用每秒输入/输出操作 (IOPS) 数，用于爬网、属性和管理数据库（例如，使用不同的存储阵列）。

规范

本节提供有关测试环境的硬件、软件、拓扑和配置的详细信息。

拓扑

搜索小型服务器场拓扑

硬件

备注

由于测试服务器场运行的是 SharePoint Server 2010 的预发布版本并且团队希望避免潜在问题，因此用于服务器的硬件的容量比通常需要的更大。

Web 服务器

Web 服务器 前端 Web 服务器/查询 (1)

处理器

1px4c@3 GHz

RAM

16 GB

操作系统

64 位 Windows Server 2008 R2

存储

2x450GB 15K SAS: RAID1:OS

2x450GB 15K SAS: RAID1:DATA1

2x450GB 15K SAS: RAID1:DATA2

网络接口卡 (NIC) 的数量

2

NIC 速度

1 GB

身份验证

NTLM

负载平衡器类型

无

软件版本

SharePoint Server 2010（预发布版本）

本地运行的服务

所有服务（包括搜索查询和网站设置服务）

应用程序服务器

服务器 查询 (1) 爬网/管理 (1)

处理器

1px4c@3 GHz

1px4c@3 GHz

RAM

16 GB

16 GB

操作系统

64 位 Windows Server 2008 R2

64 位 Windows Server 2008 R2

存储

2x450GB 15K SAS:RAID1: OS

2x450GB 15K SAS:RAID1: DATA1

2x450GB 15K SAS:RAID1: DATA2

2x450GB 15K SAS: RAID1: OS

2x450GB 15K SAS: RAID1: TEMP

2x450GB 15K SAS: RAID0: DATA

NIC 数量

1

1

NIC 速度

1 GB

1 GB

身份验证

NTLM

NTLM

负载平衡器类型

无

无

软件版本

SharePoint Server 2010（预发布版本）

SharePoint Server 2010（预发布版本）

本地运行的服务

SharePoint Server 搜索、搜索查询和网站设置服务

SharePoint Server 搜索

数据库服务器

数据库 共享 (1)

处理器

2px4c@3 GHz

RAM

16 GB

操作系统

64 位 Windows Server 2008 R2

存储

2x450GB 15K SAS: RAID1: OS

2x450GB 15K SAS: RAID0: DATA

2x450GB 15K SAS: RAID0: LOGS

备注

由于驱动器数量减少，因此将数据库分隔到不同 IO 通道中的最佳实践不适用。

NIC 数量

2

NIC 速度

1 GB

身份验证

NTLM

软件版本

Microsoft SQL Server 2008 Enterprise

工作量

本节介绍用于数据生成的工作量，包括用户的数量和服务器场使用特征。

工作量特征 值

工作量的高级别描述

搜索服务器场

平均查询数/分钟

6

平均并发用户数

1

每日查询总数

8,640

数据集

本节介绍测试服务器场数据集，包括数据库内容和大小、搜索索引和外部数据源。

对象 值

搜索索引大小（项目数量）

900 万

爬网数据库大小

52 GB

爬网数据库日志文件大小

11 GB

属性数据库大小

68 GB

属性数据库日志文件大小

1 GB

搜索管理数据库大小

2 GB

活动索引分区大小

38.4 GB（由于会对索引进行镜像处理，因此总共为 76.8 GB）

搜索数据库总数

3

其他数据库

SharePoint_Config；SharePoint_AdminContent；State_Service；Bdc_Service_db；WSS_UsageApplication；WSS_Content

运行状况和性能数据

本节提供特定于测试环境的运行状况和性能数据。

查询性能数据

以下度量是在索引中包含 900 万个项目的情况下测得的。各列提供了在特定测试期间测得的度量，表的底部还显示了测量结果。对这些度量的描述如下：

  • 查询延迟   这些度量是在查询延迟测试期间测得的，其中测试工具作为一个用户提交一组标准查询，然后度量生成的延迟。在测试期间未进行爬网。

  • 查询吞吐量   这些度量是在查询吞吐量测试期间测得的，其中测试工具作为数量不断增加的并发用户（最多为 80）提交一组针对服务器场的标准查询，然后度量生成的延迟和吞吐量。在测试期间未进行爬网。

记分卡指标 查询延迟 查询吞吐量

CPU 指标

平均 SQL Server CPU

3.4%

12%

平均前端 Web 服务器 CPU

8%

51%

平均查询服务器 CPU

13.3%

95%

可靠性

失败率

0

0

前端 Web 服务器故障数

0

0

应用程序服务器故障数

0

0

SQL Server

缓存命中率 (SQL Server)

99.97%

100%

SQL Server 锁定：平均等待时间（毫秒）

0.071

0.038

SQL Server 锁定：锁定等待时间（毫秒）

0.035

0.019

SQL Server 锁定：死锁数/秒

0

0

SQL Server 闩锁：平均等待时间（毫秒）

31

0.017

SQL Server 编译数/秒

14.9

10.2

SQL Server 统计信息：SQL Server 重编译数/秒

0.087

0.05

平均磁盘队列长度 (SQL Server)

0.011

0.01

磁盘队列长度：写入数 (SQL Server)

0.01

0.008

 

磁盘读取数/秒 (SQL Server)

0.894

0.05

磁盘写入数/秒 (SQL Server)

45

106

应用程序服务器

平均磁盘队列长度（查询服务器）

0.013

0.001

磁盘队列长度：写入数（查询服务器）

0

0.001

磁盘读取数/秒（查询服务器）

11.75

0.06

磁盘写入数/秒（查询服务器）

2

5.714

使用的平均内存（查询服务器）

8.73%

9%

使用的最大内存（查询服务器）

8.75%

9%

前端 Web 服务器

排队的 ASP.NET 请求数（所有前端 Web 服务器的平均值）

0

0

使用的平均内存（前端 Web 服务器）

9.67%

95%

使用的最大内存（前端 Web 服务器）

9.74%

100%

测试结果

成功数

1,757

13,608

错误数

0

0

查询 UI 延迟（第 75 个百分点值）

0.331 秒

3.68 秒

查询 UI 延迟（第 95 个百分点值）

0.424 秒

3.93 秒

查询吞吐量

3.29 请求数/秒

22.4 请求数/秒

爬网性能数据

以下度量是在对给定内容源进行初始、顺序完全爬网时测得的。内容源的大小为数百万个项目。各列给出了在特定爬网期间测得的度量，表的底部还显示了测量结果。

记分卡指标 SharePoint 内容 (4M) 文件共享 (1M) HTTP（非 SharePoint）(1M)

CPU 指标

平均 SQL Server CPU

5.4%

11.7%

23%

平均索引器 CPU

41.6%

69%

71%

可靠性

失败率

0

0

0

前端 Web 服务器故障数

0

0

0

应用程序服务器故障数

0

0

0

SQL Server

缓存命中率 (SQL Server)

不适用

不适用

不适用

SQL Server 锁定：平均等待时间（毫秒）

436

51.76

84.73

SQL Server 锁定：锁定等待时间（毫秒）

不适用

不适用

不适用

SQL Server 锁定：死锁数/秒

不适用

不适用

不适用

SQL Server 闩锁：平均等待时间（毫秒）

1.05

1.64

3.53

SQL Server 编译数/秒

不适用

不适用

不适用

SQL Server 统计信息：SQL Server 重编译数/秒

不适用

不适用

不适用

平均磁盘队列长度 (SQL Server)

27.124

6.85

45

磁盘队列长度：写入数 (SQL Server)

17.6

6.7

21.57

应用程序服务器

平均磁盘队列长度（爬网服务器）

0.008

0.032

0.02

磁盘队列长度：写入数（爬网服务器）

0.006

0.025

0.012

使用的平均内存（爬网服务器）

14.16%

10.4%

11.5%

使用的最大内存（爬网服务器）

19.2%

11.13%

12.78%

前端 Web 服务器

排队的 ASP.NET 请求数（所有前端 Web 服务器的平均值）

0

0

0

使用的平均内存（前端 Web 服务器）

不适用

不适用

不适用

使用的最大内存（前端 Web 服务器）

不适用

不适用

不适用

测试结果

成功数

3,934,881

1,247,838

996,982

错误数

9,645

302

2

门户爬网速度（项目数/秒）

46.32

120.436

138.316

定位爬网速度（项目数/秒）

5,197

3,466.219

2,192.982

总爬网速度（项目数/秒）

45.91

116.392

130.086

测试数据

本节提供了说明服务器场执行情况的测试数据。若要了解如何改进服务器场性能，请参阅下文中的优化一节。

查询延迟

下图显示了在用户负载增加时此服务器场的查询延迟百分点值（在查询吞吐量测试期间收集）。查询百分点值 95% 表示测得的查询延迟中有 95% 低于该值。

用户负载对查询延迟百分点值的影响

从此图表中可以看出，索引规模较小时，即使有更多并发用户 (20) 在对此服务器场执行查询，此服务器场仍可保持次秒查询延迟。

查询吞吐量

下图显示了在用户负载增加时此服务器场的查询吞吐量（在查询吞吐量测试期间收集）。

用户负载对查询吞吐量的影响

考虑前两个图表，您会发现，如果添加的用户负载超出大约 20 个并发用户，则此服务器场将不会获得附加查询吞吐量，延迟将增加。

爬网率

下图显示在搜索生命周期的索引获取阶段此服务器场的爬网率。这些值表示完全爬网，以每秒的爬网项目数表达。

按内容类型列出的完全爬网速率

为了对 SharePoint 网站内容源执行有效的完全爬网所涉及的额外开销会导致此服务器场中的总体爬网率降低。

总体方案

此服务器场接近查询服务器的 RAM 容量。由于前端 Web 服务器进程（也占用 RAM）也在其中一台查询服务器上，因此会影响在该服务器上运行的查询的延迟。

改进此服务器场的性能的后续步骤是执行以下操作：

  • 将前端 Web 服务器进程移至它们自己的前端 Web 服务器上（也就是添加另一台前端 Web 服务器，以实现冗余）。

  • 向两台查询服务器中添加更多 RAM。建议在查询服务器中为 33% 的活动查询组件的索引分区提供足够的 RAM，为操作系统和其他进程再提供 3 GB RAM。

  • 添加存储阵列，以便将数据库分隔到数据库服务器上。

中型服务器场

中型服务器场配置使用一台 Web 服务器、六台应用程序服务器和两台数据库服务器，如下所述：

  • 在此测试配置中使用一台 Web 服务器来托管搜索中心。如果始终使用 Search Service 应用程序代理（安装在子服务器场中）从子服务器场中执行搜索，则可忽略此 Web 服务器。否则，您可能要向此服务器场中添加另一台 Web 服务器，以实现冗余。

  • 使用两台应用程序服务器进行爬网和管理。这意味着：

    • 在其中一台应用程序服务器上创建管理中心和搜索管理组件。

    • 每台服务器有两个爬网组件。每个爬网组件附加到不同的爬网数据库，以实现冗余。

  • 其余的四台应用程序服务器用于查询。对于项目数最多为 4 千万的情况，标准配置是具有四个索引分区。实现冗余查询功能的方法是安排查询组件，以便每台服务器都有一个来自其中一个索引分区的活动查询组件和一个来自其他索引分区的故障转移查询组件。但是，此示例演示在规划的项目数多于 4000 万时要执行的操作。最初有八个索引分区（每个分区具有自己的活动和故障转移查询组件）位于四台应用程序服务器上，因此可以尽量减少索引重新分区。假定每台服务器都满足以下原则，以允许四个组件位于同一应用程序服务器上：

    • 有足够的 RAM 和 IOPS 可供使用。

    • 每台服务器有六个以上 CPU 内核，可支持如下处理：

      • 四个 CPU 内核用于两个活动查询组件。

      • 两个 CPU 内核用于两个故障转移查询组件。

  • 两台数据库服务器支持服务器场。一台数据库服务器用于两个爬网数据库。另一台服务器除了用于其他 SharePoint 数据库外，还可用于属性和搜索管理数据库。数据库服务器应具有专用数量的 IOPS 用于每个爬网、属性和搜索管理数据库（例如，使用不同的存储阵列）。

规范

本节提供有关测试环境的硬件、软件、拓扑和配置的详细信息。

拓扑

搜索中型服务器场拓扑

硬件

备注

由于测试服务器场运行的是 SharePoint Server 2010 的预发布版本并且团队希望避免潜在问题，因此用于服务器的硬件的容量比通常需要的更大。

Web 服务器

Web 服务器 前端 Web 服务器 (1)

处理器

2px4c@2.33 GHz

RAM

8 GB

操作系统

64 位 Windows Server 2008 R2

存储

2x148GB 15K SAS: RAID1: OS

NIC 数量

2

NIC 速度

1 GB

身份验证

NTLM

负载平衡器类型

无

软件版本

Microsoft SharePoint Server（预发布版本）

本地运行的服务

所有服务

应用程序服务器

服务器场中有六台应用程序服务器。四台服务器用于服务查询，两台服务器用于爬网。

服务器（计数） 查询 (4) 爬网 (1)，爬网/管理 (1)

处理器

2px4c@2.33 GHz

2px4c@2.33 GHz

RAM

32 GB

8 GB

操作系统

64 位 Windows Server 2008 R2

64 位 Windows Server 2008 R2

存储

2x148 GB 15K SAS: RAID1: OS

4x300GB 15K SAS:RAID10:Data

2x148 GB 15K SAS:RAID1: OS/Data

NIC 数量

2

2

NIC 速度

1 GB

1 GB

身份验证

NTLM

NTLM

负载平衡器类型

无

无

软件版本

SharePoint Server 2010（预发布版本）

SharePoint Server 2010（预发布版本）

本地运行的服务

SharePoint Server 搜索；搜索查询和网站设置服务

SharePoint Server 搜索

数据库服务器

有两台数据库服务器。第一台服务器包含搜索管理、属性和其他 SharePoint Server 数据库。第二台服务器包含两个爬网数据库。请注意，创建的存储卷可对用于测试的现有硬件进行优化。

数据库服务器 搜索管理；属性；SharePoint 数据库 爬网数据库

处理器

2px4c@3.2 GHz

4px2c@2.19 GHz

RAM

32 GB

16 GB

操作系统

64 位 Windows Server 2008 R2

64 位 Windows Server 2008 R2

存储

2x148GB 15K SAS :RAID1: OS

2x148GB 15K SAS :RAID1: TEMP Log

2x450GB 15K SAS :RAID1: TEMP DB

6x450GB 15K SAS :RAID10: Property DB

2x450GB 15K SAS :RAID1:Search Admin, SharePoint DBs

2x450GB 15K SAS :RAID1:Logs

2x148GB 15K SAS :RAID1: OS

2x148GB 15K SAS :RAID1: TEMP Log

2x300GB 15K SAS :RAID1: TEMP DB

6x146GB 15K SAS :RAID10: Crawl DB1

6x146GB 15K SAS :RAID10: Crawl DB2

2x300GB 15K SAS :RAID1:Crawl DB Log1

2x300GB 15K SAS :RAID1:Crawl DB Log2

NIC 数量

2

2

NIC 速度

1 GB

1 GB

身份验证

NTLM

NTLM

软件版本

SQL Server 2008 Enterprise

SQL Server 2008 Enterprise

工作量

本节介绍用于数据生成的工作量，包括用户数量和服务器场使用特征。

工作量特征 值

工作量的高级别描述

搜索服务器场

平均查询数/分钟

12

平均并发用户数

1

每日查询总数

17,280

计时器作业

搜索运行状况监视 – 跟踪事件；爬网日志报告；运行状况分析作业；搜索和处理

数据集

本节介绍测试服务器场数据集，包括数据库内容和大小、搜索索引和外部数据源。

对象 值

搜索索引大小（项目数量）

4600 万

爬网数据库大小

356 GB

爬网数据库日志文件大小

85 GB

属性数据库大小

304 GB

属性数据库日志文件大小

9 GB

搜索管理数据库大小

5 GB

活动索引分区大小

 316 GB（每个活动组件 79 GB）。

数据库总数

2

其他数据库

SharePoint_Config；SharePoint_AdminContent；State_Service；Bdc_Service_db；WSS_UsageApplication；WSS_Content

运行状况和性能数据

本节提供特定于测试环境的运行状况和性能数据。

查询性能数据

以下度量是在搜索索引中包含 4600 万个项目的情况下测得的。各列给出了在特定测试期间测得的度量，表的底部还显示了测量结果。对这些度量的描述如下：

  • 查询延迟   这些度量是在查询延迟测试期间测得的，其中测试工具作为一个用户提交一组标准查询，然后度量生成的延迟。在测试期间未进行爬网。

  • 查询吞吐量   这些度量是在查询吞吐量测试期间测得的，其中测试工具作为数量不断增加的并发用户（最多为 80）提交一组针对服务器场的标准查询，然后度量生成的延迟和吞吐量。在测试期间未进行爬网。

记分卡指标 查询延迟 查询吞吐量

CPU 指标

平均 SQL Server CPU（属性数据库服务器）

5%

98%

平均前端 Web 服务器 CPU

3%

33%

平均查询服务器 CPU

3%

47%

可靠性

失败率

0.07%

0%

前端 Web 服务器故障数

0

0

应用程序服务器故障数

0

0

SQL Server

（属性数据库服务器）

缓存命中率 (SQL Server)

100%

99.9%

SQL Server 锁定：平均等待时间（毫秒）

0

0.159

SQL Server 锁定：锁定等待时间（毫秒）

0

0.080

SQL Server 锁定：死锁数/秒

0

0

SQL Server 闩锁：平均等待时间（毫秒）

0.041

1.626

SQL Server 编译数/秒

9.776

93.361

SQL Server 统计信息：SQL Server 重编译数/秒

0.059

0.071

读/写比率（IO/数据库）

0.01

0.81

平均磁盘队列长度 (SQL Server)

0.001

0.037

磁盘队列长度：写入数 (SQL Server)

0

0.003

 

磁盘读取数/秒 (SQL Server)

0.057

14.139

磁盘写入数/秒 (SQL Server)

4.554

17.515

应用程序服务器

平均磁盘队列长度（查询服务器）

0

0.001

磁盘队列长度：写入数（查询服务器）

0

0.001

磁盘读取数/秒（查询服务器）

0.043

0.266

磁盘写入数/秒（查询服务器）

4.132

5.564

使用的平均内存（查询服务器）

9%

10%

使用的最大内存（查询服务器）

9%

10%

前端 Web 服务器

排队的 ASP.NET 请求数（所有前端 Web 服务器的平均值）

0

0

使用的平均内存（前端 Web 服务器）

47%

48%

使用的最大内存（前端 Web 服务器）

47%

49%

测试结果

成功数

1,398

14,406

错误数

1

0

查询 UI 延迟（第 75 个百分点值）

0.47 秒

2.57 秒

查询 UI 延迟（第 95 个百分点值）

0.65 秒

3.85 秒

查询吞吐量

2.38 请求/秒

27.05 请求/秒

爬网性能数据

以下度量是在对给定内容源进行初始、顺序完全爬网时测得的。内容源的大小为数百万个项目。各列给出了在特定爬网期间测得的度量，表的底部还显示了测量结果。

记分卡指标 SharePoint 内容（350 万） 文件共享（100 万） HTTP（非 SharePoint）（100 万）

CPU 指标

平均 SQL Server CPU（爬网数据库服务器、属性数据库服务器）

11%, 19%

22%, 7%

23%, 5%

最大 SQL Server CPU（爬网数据库服务器、属性数据库服务器）

96%, 100%

86%, 45%

79%, 28%

平均索引器 CPU

41.6%

69%

71%

可靠性

失败率

0.2%

0.02%

0%

前端 Web 服务器故障数

0

0

0

应用程序服务器故障数

0

0

0

SQL Server

（爬网数据库服务器、属性数据库服务器）

缓存命中率 (SQL Server)

99.5%, 99.8%

未收集

99.9%, 99.3%

SQL Server 锁定：平均等待时间 [毫秒]

1,881.749, 1,106.314

1,617.980, 2.882

983.137, 0.904

SQL Server 锁定：最长等待时间 [毫秒]

69,919.500, 1,081,703

55,412.000, 304.500

24,000.500, 47

SQL Server 锁定：平均锁定等待时间 [毫秒]

339.658, 10,147.012

未收集

739.232, 0.136

SQL Server 锁定：最大锁定等待时间 [毫秒]

598,106.544, 234,708,784

未收集

52,711.592, 23.511

SQL Server 锁定：死锁数/秒

0.001, 0

未收集

0.008, 0

SQL Server 闩锁：平均等待时间 [毫秒]

2.288, 13.684

3.042, 13.516

2.469, 20.093

SQL Server 闩锁：最长等待时间 [毫秒]

2,636, 1,809

928, 858.5

242.929, 938.706

SQL Server 编译数/秒：平均

20.384, 5.449

未收集

76.157, 6.510

SQL Server 编译数/秒：最大

332.975, 88.992

未收集

295.076, 42.999

SQL Server 统计信息：SQL Server 重编译数/秒：平均

0.560, 0.081

未收集

0.229, 0.125

SQL Server 统计信息：SQL Server 重编译数/秒：最大

22.999, 88.492

未收集

17.999, 15.5

读/写比率（IO/数据库）：最大

2.15, 1.25

未收集

1.45, 0.364

平均磁盘队列长度 (SQL Server)

66.765, 27.314

129.032, 20.665

182.110, 11.816

最大磁盘队列长度 (SQL Server)

4,201.185, 5,497.980

3,050.015, 762.542

1,833.765, 775.7

磁盘队列长度：写入 (SQL Server)：平均

58.023, 13.532

114.197, 19.9

175.621, 10.417

磁盘队列长度：写入 (SQL Server)：最大

1,005.691, 881.892

1,551.437, 761.891

1,018.642, 768.289

 

磁盘读取数/秒 (SQL Server)：平均

245.945, 94.131

未收集

137.435, 154.103

磁盘读取数/秒 (SQL Server)：最大

6,420.412, 6,450.870

未收集

3,863.283, 1,494.805

磁盘写入数/秒 (SQL Server)：平均

458.144, 286.884

未收集

984.668, 278.175

磁盘写入数/秒 (SQL Server)：最大

2,990.779, 5,164.949

未收集

2,666.285, 4,105.897

应用程序服务器

平均磁盘队列长度（爬网服务器）

0.052

0.043

0.030

磁盘队列长度：写入数（爬网服务器）

0.029

0.031

0.026

磁盘读取数/秒（爬网服务器）

5.405

未收集

0.798

磁盘写入数/秒（爬网服务器）

48.052

未收集

102.235

使用的平均内存（爬网服务器）

68%

45%

52%

使用的最大内存（爬网服务器）

76%

47%

59%

前端 Web 服务器

排队的 ASP.NET 请求数（所有前端 Web 服务器的平均值）

0

0

0

使用的平均内存（前端 Web 服务器）

不适用

不适用

不适用

使用的最大内存（前端 Web 服务器）

不适用

不适用

不适用

测试结果

成功数

3,631,080

1,247,838

200,000

错误数

7,930

304

0

门户爬网速度（项目数/秒）

82

148

81

定位爬网速度（项目数/秒）

1,573

1,580

1,149

总爬网速度（项目数/秒）

79

136

76

测试数据

本节提供了说明服务器场在有负载时的执行情况的测试数据。

查询延迟

下图显示了在用户负载增加时此服务器场的查询延迟百分点值（在查询吞吐量测试期间收集）。查询百分点值 95% 表示测得的查询延迟中有 95% 低于该值。

用户负载对查询延迟百分点值的影响

从此图表中可以看出，索引规模较小时，即使有更多并发用户 (22) 在对此服务器场执行查询，此服务器场仍可在 95% 的百分点值处保持次秒查询延迟。

查询吞吐量

下图显示了在用户负载增加时此服务器场的查询吞吐量（在查询吞吐量测试期间收集）。

用户负载对查询吞吐量的影响

考虑此图表和上一图表，可以看出，当索引中包含 330 万个项目时，服务器场可在并发用户约为 30 个时在 75% 的百分点值处保持次秒延迟。还可以容纳更多的并发用户负载，但查询延迟将增加到次秒标记之上。

但是，当索引中包含 460 万个项目时，无法容纳更多并发用户负载，查询延迟也会增加。

爬网率

下图显示在搜索生命周期的索引获取阶段此服务器场的爬网率。这些值表示完全爬网，以每秒的爬网项目数表达。

按内容类型列出的完全爬网速率

为了对 SharePoint 网站内容源有效执行爬网所涉及的额外开销会导致此服务器场中的总体爬网率降低。

总体方案

此服务器场接近查询服务器的 RAM 容量。

改进此服务器场性能的后续步骤是执行以下操作：

  • 向两台查询服务器中添加更多 RAM。建议在查询服务器中为 33% 的活动查询组件的索引分区提供足够的 RAM，为操作系统和其他进程再提供 3 GB RAM。

  • 向托管属性数据库的数据库服务器中添加更多 RAM。在此配置中，键表的大小约为 92 GB（包括索引），这需要 30 GB RAM。但是，数据库服务器只有 32 GB RAM 来为属性数据库、搜索管理数据库和其他 SharePoint Server 数据库提供服务。

  • 添加存储阵列，以便将数据库分隔到数据库服务器上。

  • 向外扩展，以增加吞吐量和/或减小查询延迟。

在这个具有两个爬网数据库和四个爬网组件的服务器场中，尽管爬网速度很快，但服务器场具有某些更新鲜的索引部分是一个重要目标；也就是说，需要非常频繁地爬网某些内容。为所需内容源中的主机（使用主机分布规则）添加另一个专用的爬网数据库并将其他两个爬网组件与该数据库关联，将支持这一索引新鲜度目标。

大型服务器场

预期配置使用一台 Web 服务器、13 台应用程序服务器和三台数据库服务器，如下所述：

  • 一台 Web 服务器用于托管搜索中心。如果始终使用 Search Service 应用程序代理（安装在内容服务器场中）从内容服务器场中执行搜索，则可忽略此 Web 服务器。

  • 使用三台应用程序服务器进行爬网和管理。这意味着：

    • 在其中一台应用程序服务器上创建管理中心和搜索管理组件。

    • 每台服务器有两个爬网组件。每个爬网组件附加到不同的爬网数据库。

  • 其余的十台应用程序服务器用于查询。首选配置是具有十个索引分区。这样，每台服务器将具有一个来自其中一个索引分区的主查询组件，以及一个来自其他索引分区的故障转移查询组件。

  • 四台数据库服务器支持服务器场。一台服务器用于属性和搜索管理数据库。第二台服务器用于属性数据库。第三台服务器用于两个爬网数据库。第四台服务器用于一个爬网数据库和另一个 SharePoint 数据库。数据库服务器应具有专用数量的 IOPS 用于每个爬网、属性和搜索管理数据库（例如，使用不同的存储阵列）。

规范

本节提供有关测试环境的硬件、软件、拓扑和配置的详细信息。

拓扑

本节介绍测试环境的拓扑。

搜索大型服务器场拓扑

硬件

本节介绍用于测试的硬件。

备注

由于测试服务器场运行的是 SharePoint Server 2010 的预发布版本并且团队希望避免潜在问题，因此用于服务器的硬件的容量比通常需要的更大。

Web 服务器

Web 服务器 前端 Web 服务器 (1)

处理器

2px4c@2.33 GHz

RAM

8 GB

操作系统

64 位 Windows Server 2008 R2

存储

2x148GB 15K SAS: RAID1: OS

NIC 数量

2

NIC 速度

1 GB

身份验证

NTLM

负载平衡器类型

无

软件版本

SharePoint Server 2010（预发布版本）

本地运行的服务

所有服务

应用程序服务器

服务器场中有 13 台应用程序服务器。其中 10 台服务器用于服务查询，3 台服务器用于爬网。

服务器（计数） 查询 (10) 爬网 (2)，爬网/管理 (1)

处理器

2px4c@2.5 GHz

2px4c@2.5 GHz

RAM

32 GB

32 GB

操作系统

64 位 Windows Server 2008 R2

64 位 Windows Server 2008 R2

存储

2x148GB 15K SAS: RAID1: OS

4x300GB 15K SAS:RAID10:Data

2x148GB 15K SAS:RAID1: OS/Data

NIC 数量

2

2

NIC 速度

1 GB

1 GB

身份验证

NTLM

NTLM

负载平衡器类型

无

无

软件版本

SharePoint Server 2010（预发布版本）

SharePoint Server 2010（预发布版本）

本地运行的服务

SharePoint Server 搜索；搜索查询和网站设置服务

SharePoint Server 搜索

数据库服务器

有四台数据库服务器。第一台服务器包含搜索管理和属性数据库；第二台服务器包含一个属性数据库；第三台服务器包含两个爬网数据库；第四台服务器包含一个爬网数据库和一个 SharePoint 数据库。请注意，创建的存储卷可对用于测试的现有硬件进行优化。

数据库服务器 搜索管理、属性和 SharePoint 数据库 爬网数据库

处理器

2px4c@3.2 GHz

4px2c@2.19 GHz

RAM

32 GB

16 GB

操作系统

64 位 Windows Server 2008 R2

64 位 Windows Server 2008 R2

存储

2x148GB 15K SAS :RAID1: OS

2x148GB 15K SAS :RAID1: TEMP Log

2x450GB 15K SAS :RAID1: TEMP DB

6x450GB 15K SAS :RAID10: Property DB

2x450GB 15K SAS :RAID1:Search Admin, SharePoint DBs

2x450GB 15K SAS :RAID1:Logs

2x148GB 15K SAS :RAID1: OS

2x148GB 15K SAS :RAID1: TEMP Log

2x300GB 15K SAS :RAID1: TEMP DB

6x146GB 15K SAS :RAID10: Crawl DB1

6x146GB 15K SAS :RAID10: Crawl DB2

2x300GB 15K SAS :RAID1:Crawl DB Log1

2x300GB 15K SAS :RAID1:Crawl DB Log2

NIC 数量

2

2

NIC 速度

1 GB

1 GB

身份验证

NTLM

NTLM

软件版本

SQL Server 2008 Enterprise

SQL Server 2008 Enterprise

查询性能数据

以下度量是在索引中包含 1.03 亿个项目的情况下测得的。各列给出了在特定测试期间测得的度量，表的底部还显示了测量结果。对这些度量的描述如下：

  • 查询延迟   这些度量是在查询延迟测试期间测得的，其中测试工具作为一个用户提交一组标准查询，然后度量生成的延迟。在测试期间未进行爬网。

  • 查询吞吐量   这些度量是在查询吞吐量测试期间测得的，其中测试工具作为数量不断增加的并发用户（最多为 120）提交一组针对服务器场的标准查询，然后度量生成的延迟和吞吐量。在测试期间未进行爬网。

记分卡指标 查询吞吐量

CPU 指标

平均 SQL Server CPU（属性数据库服务器）

34%

平均前端 Web 服务器 CPU

45%

平均查询服务器 CPU

20%

可靠性

失败率

0%

前端 Web 服务器故障数

0

应用程序服务器故障数

0

SQL Server

（属性数据库服务器）

缓存命中率 (SQL Server)

100%

SQL Server 锁定：平均等待时间（毫秒）

0

SQL Server 锁定：锁定等待时间（毫秒）

0

SQL Server 锁定：死锁数/秒

0

SQL Server 闩锁：平均等待时间（毫秒）

1.401

SQL Server 编译数/秒

73.349

SQL Server 统计信息：SQL Server 重编译数/秒

0.006

读/写比率（IO/数据库）

0.81

平均磁盘队列长度 (SQL Server)

0.037

磁盘队列长度：写入数 (SQL Server)

0.003

 

磁盘读取数/秒 (SQL Server)

9.88

磁盘写入数/秒 (SQL Server)

354.1

应用程序服务器

平均磁盘队列长度（查询服务器）

0.002

磁盘队列长度：写入数（查询服务器）

0.002

磁盘读取数/秒（查询服务器）

0.035

磁盘写入数/秒（查询服务器）

6.575

使用的平均内存（查询服务器）

6.548%

使用的最大内存（查询服务器）

6.601%

前端 Web 服务器

排队的 ASP.NET 请求数（所有前端 Web 服务器的平均值）

0

使用的平均内存（前端 Web 服务器）

18.081%

使用的最大内存（前端 Web 服务器）

19.983%

测试结果

成功数

10,925

错误数

0

查询 UI 延迟（第 75 个百分点值）

3.431 秒

查询 UI 延迟（第 95 个百分点值）

3.512 秒

查询吞吐量

36.42 请求/秒

爬网性能数据

以下度量是在对给定内容源的进行的初始、顺序完全爬网中测得的。内容的大小为数百万个项目。各列给出了在特定爬网期间测得的度量，表的底部还显示了测量结果。

记分卡指标 SharePoint 内容（350 万） 文件共享（100 万）

CPU 指标

平均 SQL Server CPU（爬网数据库服务器、属性数据库服务器）

15.74%，不适用

24%, 6.6%

最大 SQL Server CPU（爬网数据库服务器、属性数据库服务器）

100%，不适用

100%, 45%

平均索引器 CPU

44%

49%

可靠性

失败率

0.0%

0.00%

前端 Web 服务器故障数

0

0

应用程序服务器故障数

0

0

SQL Server

（爬网数据库服务器、属性数据库服务器）

缓存命中率 (SQL Server)

99.8%，不适用

99.797%, 99.49%

SQL Server 锁定：平均等待时间 [毫秒]

734.916，不适用

1,165, 5.866

SQL Server 锁定：最长等待时间 [毫秒]

15,335，不适用

28,683, 210.5

SQL Server 锁定：平均锁定等待时间 [毫秒]

108.98，不适用

847.72, 5.325

SQL Server 锁定：最大锁定等待时间 [毫秒]

17,236.96，不适用

124,353, 12,920

SQL Server 锁定：死锁数/秒

0，不适用

0.012, 0

SQL Server 闩锁：平均等待时间 [毫秒]

1.4，不适用

2.233, 40.6

SQL Server 闩锁：最长等待时间 [毫秒]

1,606，不适用

917.8, 1,895

SQL Server 编译数/秒：平均

24.28，不适用

72.7, 11.39

SQL Server 编译数/秒：最大

416，不适用

460, 76.62

SQL Server 统计信息：SQL Server 重编译数/秒：平均

0.560，不适用

0.295, 0.099

SQL Server 统计信息：SQL Server 重编译数/秒：最大

0.24，不适用

17.50, 17.393

读/写比率（IO/数据库）：最大

20.3，不适用

1.18/0.214

平均磁盘队列长度 (SQL Server)

90.113，不适用

138.64, 27.478

最大磁盘队列长度 (SQL Server)

3,179，不适用

2,783.543, 847.574

磁盘队列长度：写入数 (SQL Server)：平均

86.93，不适用

130,853, 26.086

磁盘队列长度：写入数 (SQL Server)：最大

1,882，不适用

2,781.197, 884.801

 

磁盘读取数/秒 (SQL Server)：平均

99，不适用

147.462, 159.159

磁盘读取数/秒 (SQL Server)：最大

3,772，不适用

2,403.336, 896.462

磁盘写入数/秒 (SQL Server)：平均

373，不适用

475.886, 539.497

磁盘写入数/秒 (SQL Server)：最大

18,522，不适用

2,031.888, 4,174.271

应用程序服务器

平均磁盘队列长度（爬网服务器）

0.075

0.063

磁盘队列长度：写入数（爬网服务器）

0.046

0.053

磁盘读取数/秒（爬网服务器）

1.958

1.693

磁盘写入数/秒（爬网服务器）

62.33

101.093

使用的平均内存（爬网服务器）

59%

56.38%

使用的最大内存（爬网服务器）

70%

58.93%

前端 Web 服务器

排队的 ASP.NET 请求数（所有前端 Web 服务器的平均值）

不适用

不适用

使用的平均内存（前端 Web 服务器）

不适用

不适用

使用的最大内存（前端 Web 服务器）

不适用

不适用

测试结果

成功数

1,909,739

1,247,838

错误数

9,361

331

门户爬网速度（项目数/秒）

70.3

131.44

定位爬网速度（项目数/秒）

764

525.84

总爬网速度（项目数/秒）

64

105

建议和疑难解答

以下各节针对在部署与这些方案类似的环境时如何确定所需要的硬件、拓扑和配置以及如何为适当的容量和性能特征优化环境提供了建议。

建议

本节介绍为实现适当的容量和性能特征而优化环境时，可以执行的特定操作。

硬件建议

有关总体的最低和建议系统要求的特定信息，请参阅硬件和软件要求 (SharePoint Server 2010)。请注意，对用于搜索的服务器的要求将取代总体系统要求。可使用以下用于 RAM、处理器和 IOPS 的建议原则来满足性能目标。

搜索大小

本节对搜索系统进行了说明，包括每个组件的大小要求和原则。

可以采用多种方式部署和配置 SharePoint Server 2010。所以，没有简单的方法可以估计给定数量的服务器可以支持的用户或项目数量。因此，请确保在生产环境中部署 SharePoint Server 2010 之前，在您自己的环境中进行测试。

搜索查询系统

本节显示了用于给定 Search Service 应用程序的搜索查询系统的组件。在下图后面的缩放详细信息表中，列出了对每个组件的大小要求。

搜索查询系统

对象说明

以下列表定义了上图中的搜索查询系统对象：

  • 搜索查询   此 Search Service 应用程序代理安装在从此 Search Service 应用程序中使用搜索的任何服务器场中。它在与该 Search Service 应用程序代理关联的 Web 应用程序的上下文中运行。

  • 搜索查询和网站设置服务   也称为查询处理器。从 Search Service 应用程序代理连接中接收查询后，查询处理器会执行以下操作：

    • 将查询发送到每个索引分区的一个活动查询组件（或发送到属性数据库或以上两个位置，具体取决于查询）

    • 检索最佳匹配并删除重复项，以获取结果集

    • 根据搜索管理数据库中的安全说明对结果进行安全修整

    • 检索从属性数据库中设置的最终结果的元数据

    • 将查询结果发送回代理

  • 索引分区   这是查询组件的逻辑组，表示全文检索的子集。索引分区的总和构成了全文检索。但请注意，查询组件包含索引的实际子集。一个索引分区与一个属性数据库关联。

  • 搜索查询组件   查询组件包含所有或部分全文检索。当查询处理器进行查询时，查询组件将从其索引中确定最佳结果并返回这些项目。查询组件可以创建为下列任一类型：

    • 活动查询组件，这意味着它在默认情况下回响应查询。为同一索引分区添加多个活动查询组件将增加吞吐量。

    • 故障转移查询组件，这意味着，仅当同一索引分区的所有活动组件都已失败时，它才响应查询。

  • 搜索管理数据库   与 Search Service 应用程序同时创建，搜索管理数据库除了包含用于管理的应用程序设置外，还包含 Search Service 应用程序范围内用于查询的数据，如最佳匹配和安全说明。

  • 属性数据库   属性数据库包含索引中项目的元数据（标题、作者、相关字段）。除了检索显示最终结果所需要的元数据外，属性数据库还可用于基于属性的查询。如果存在多个索引分区，则可将索引分区映射到不同的属性数据库。

缩放详细信息

对象 缩放注意事项 RAM IOPS（读/写）

搜索代理

此服务通过与之关联的前端 Web 服务器来进行缩放。

不适用

不适用

搜索查询和网站设置服务

此服务在管理中心的“服务器上的服务”页面中安装，应在具有查询组件的每台服务器上启动。可将其移至单独的服务器上（或成对，以实现高可用性），以避免在包含查询组件的服务器上使用 RAM。而且，如果使用自定义安全修整程序，则它会影响 CPU 和 RAM 资源。

此服务使用 RAM（进程缓存）来缓存索引的安全说明。

不适用

索引分区

增加索引分区数可减少索引分区中的项目数，从而可减少在托管分配给索引分区的查询组件的查询服务器上需要的 RAM 和磁盘空间。

不适用

不适用

查询组件

服务器上的每个活动查询组件在为查询服务时都会使用内存。每个活动查询组件都作为 Search Service 应用程序拓扑的一部分来创建或修改。进行爬网时，活动和故障转移组件都会使用 IO。假定已满足 RAM 和 IO 要求，则服务器可专用于查询组件（例如，两个活动组件和两个故障转移组件在同一台服务器上）。

如果可能，每台服务器上的每个活动组件至少有两个专用的 CPU 内核，每台服务器上的每个故障转移组件至少有一个专用 CPU 内核。

对于应用程序服务器上的每个活动查询组件，其索引中应有 33% 位于 RAM（操作系统缓存）中。

给定服务器上的每对（活动/故障转移）查询组件需要 2 K。

查询组件需要用于以下用途的 IO：

为查询将索引加载到 RAM 中

写入从每个爬网组件中收到的索引段

将索引段合并到它的索引中，如在主合并期间

搜索管理数据库

对于每个查询，都将从搜索管理数据库中加载最佳匹配和安全描述符。确保数据库服务器中有足够的 RAM 可从缓存中提供此服务。请尽可能避免将其放在包含爬网数据库的服务器上，因为爬网通常会重置其数据库服务器的缓存。

确保数据库服务器有足够 RAM 来使临界表 (MSSSecurityDescriptors) 保留在 RAM 中。

700

属性数据库

对于每个查询，都会从文档结果的属性数据库中检索元数据，以使您可以向数据库服务器中添加 RAM，以改进性能。如果存在多个索引分区，则可对属性数据库分区并移至不同的数据库服务器，以降低 RAM 和 IO 要求。

确保数据库服务器有足够的 RAM，可在缓存中保留 33% 的临界表 (MSSDocSDID + MSSDocProp + MSSDocresult)。

2 K

30% 读取，70% 写入

搜索爬网系统

本节显示搜索爬网系统的组件。下图后面的表中显示了每个组件的大小要求。

搜索爬网系统

对象说明

本节定义上图中的搜索爬网系统对象：

  • 管理组件   除了对爬网系统执行管理任务时之外，在启动爬网时也会使用管理组件。

  • 爬网组件   爬网组件可处理爬网、将生成的索引段文件传播到查询组件，并将有关内容源的位置和爬网计划的信息添加到关联的爬网数据库中。

  • 搜索管理数据库   搜索管理数据库与 Search Service 应用程序同时创建，除了存储用于管理的应用程序设置外，还存储在爬网期间发现的安全说明。

  • 爬网数据库   爬网数据库包含于内容源位置、爬网计划相关的数据以及特定于爬网操作的其他信息。可通过创建主机分布规则将爬网数据库专用于特定主机。爬网数据库只存储数据。与给定爬网数据库关联的爬网组件执行爬网。

  • 搜索查询系统

缩放详细信息

对象 缩放注意事项 RAM IOPS（可选，读/写百分比）

管理组件

单个管理组件不可缩放。默认情况下，它位于托管爬网组件的服务器上（以及小型服务器场得管理中心）。

最低

最低

爬网组件

爬网组件集中使用 CPU 带宽。最佳情况下，给定爬网组件可以利用四个 CPU 内核。RAM 不是关键项。在大型服务器场中，用专用服务器托管爬网组件可以最大程度地减少爬网程序对其他组件的影响（特别是在需要冗余时，使用与不同爬网数据库关联的爬网组件时）。

适度。请注意，在爬网东亚文档时，RAM 要求将因分词系统而增加。

300-400

搜索管理数据库

请参阅上面的搜索查询系统。避免在包含爬网数据库的服务器上放置此数据库，因为爬网数据库通常会重置其数据库服务器的缓存。

请参阅上面的搜索查询系统。

700

爬网数据库

爬网数据库集中使用 IO 带宽。RAM 不是关键项。爬网数据库需要 3.5 K IOPS 来爬网活动；根据可用带宽，它最多会使用 6 K IOPS。

适度

3.5 – 7 K

73% 读取，27% 写入

计算存储大小

计算以下因素可帮助估计存储要求。大小因素基于具有索引的预部署系统，其中主要包含 SharePoint 内容（内容数据库的大小为 13.3 TB）。SharePoint 搜索大约需要内容数据库磁盘空间的 20%。因此，请确保在生产环境中部署 SharePoint Server 2010 之前，在您自己的环境中进行测试。

警告：

  • 用于派生这些数字的文档集主要是（英文）SharePoint 内容，因此如果您的内容不同（例如，主要包含文件共享或非 SharePoint HTTP 网站），则需要允许更多变化。

  • 即使内容主要是 SharePoint 内容，仍可在以下情况下变化系数：

    • 如果具有大型文档库，系数将显著变大。

    • 如果内容主要是图像，则可减少系数。

    • 使用不同语言的内容很可能会影响系数。

1. 计算内容数据库大小系数 (ContentDBSum)

确定将爬网的 SharePoint 内容数据库的总和。此 ContentDBSum 值将在下一存储计算中用作关联。

2. 计算与索引相关的大小（TotalIndexSize 和 QueryComponentIndexSize）

确定总索引的大小（位于查询组件上并用于全文查询）：

将 ContentDBSum 乘以 .035。这是在分区并为合并和重新分区保留空间之前的 TotalIndexSize。

接下来，根据您的方案确定您将具有的索引分区数。通常的原则是一个索引分区应包含 500 万到 1000 万个项目。确定索引分区的数量后，可以计算查询组件存储的大小。

  • 将 TotalIndexSize 除以 （索引分区数）。这是 QueryComponentIndexSize。它用于计算以下大小：

    • 对于 RAM，将 QueryComponentIndexSize 乘以 0.33。这是此查询组件（如果它是活动的）需要的最小 RAM。

      • 如果组件是故障转移组件，则在它变为活动组件之前不需要 RAM。

      • 对于给定服务器，多个活动查询组件位于同一台服务器上意味着，需要对每个活动查询组件的 RAM 求和，才能达到服务器的 RAM 需求。

    • 对于磁盘存储，请通过以下方式使用 QueryComponentIndexSize 来估计磁盘要求，具体取决于是否要对索引重新分区（意味着，您预计索引会大于每个分区 1000 万个项目的边界）：

      • 将 QueryComponentIndexSize 乘以 3，计算用于单个查询组件的磁盘存储，以为索引合并留出空间。

      • 将 QueryComponentIndexSize 乘以 4，计算用于单个查询组件的磁盘存储，以为索引重新分区留出空间。

对于给定服务器，多个查询组件位于同一台服务器上意味着，必须根据上文的“搜索查询系统”部分的“缩放详细信息”一节中的 IOPS 要求为每个查询组件安排存储。

3. 计算属性数据库大小

通过以下方式确定属性数据库的大小：

  • 将 ContentDBSum 乘以 0.015。这是分区之前的 TotalPropertyDBSize。

  • 将 ContentDBSum 乘以 0.0031。这是分区之前的 TotalPropertyDBLogSize。此方法假定对 SQL Server 数据库使用简单恢复模型。

  • 将 ContentDBSum 乘以 0.00034。这是属性数据库 TempDBSize。由于我们建议属性数据库中有 33% 的键表位于 RAM 中，因此，不会频繁使用临时数据库。

接下来，根据您的方案确定您将具有的属性数据库数。一般原则是，假定没有查询性能问题且您具有数量有限的托管属性（标准配置），属性数据库最多应包含 5000 万个项目。

  • 将 TotalPropertyDBSize 除以**（属性数据库数）**。这是 PropertyDatabaseSize。

  • 将 TotalPropertyDBLogSize 除以**（属性数据库数）**。这是 PropertyDatabaseLogSize。

  • 对于 RAM，将 PropertyDatabaseSize 乘以 0.33。这是建议用于此属性数据库的最小 RAM。

对于给定数据库服务器，多个属性数据库位于同一台服务器上意味着，必须根据上文的“搜索查询系统”部分的“缩放详细信息”一节中的 IOPS 和 RAM 要求为每个属性数据库安排存储和 RAM。

4. 计算爬网数据库大小

接下来，通过以下方式确定爬网数据库需要的大小：

  • 将 ContentDBSum 乘以 .046。这是分区之前的 TotalCrawlDBSize。

  • 将 ContentDBSum 乘以 .011。这是分区之前的 TotalCrawlDBLogSize。此方法假定对 SQL Server 数据库使用简单恢复模型。

  • 将 ContentDBSum 乘以 .0011。这是爬网数据库 TempDBSize。由于搜索爬网系统会影响临时数据库的性能，因此建议不要将其他数据库放在托管爬网数据库或将受此用途影响的数据库的服务器上。

接下来，根据您的方案确定您将具有的爬网数据库数。一般原则是假定没有爬网性能问题，一个爬网数据库应最多包含 2500 万个项目。

  • 将 TotalCrawlDBSize 除以**（爬网数据库数）**。这是 CrawlDatabaseSize。

  • 将 TotalCrawlDBLogSize 除以**（爬网数据库数）**。这是 CrawlDatabaseLogSize。

对于给定数据库服务器，多个爬网数据库位于同一台服务器上意味着，需要根据上文的“搜索爬网系统”部分的“缩放详细信息”一节中的 IOPS 要求为每个爬网数据库安排存储。对于 RAM，建议数据库服务器上至少有 16 GB 专用于爬网数据库。

5. 计算搜索管理数据库大小

通过以下方式确定搜索管理数据库的大小（假定使用 Windows 身份验证）：

  • 将**索引中的项目数（以百万计）**乘以 0.3。这是 SearchAdminDBSize。

  • 对于 RAM，将 SearchAdminDBSize 乘以 0.33。这是建议用于此搜索管理数据库的最小 RAM。

对于给定数据库服务器，多个数据库位于同一台服务器上意味着，必须根据上文的“搜索查询系统”部分的“缩放详细信息”一节中的 IOPS 和 RAM 要求为每个数据库安排存储和 RAM。

可选：计算备份大小

若要确定备份一个 Search Service 应用程序需要的磁盘空间，请执行以下计算：

  • TotalCrawlDBSize + TotalPropertyDBSize + TotalIndexSize + SearchAdminDBSize = 基本备份大小。

此基本备份大小是一个起点。它将受以下因素的影响：

  • TotalIndexSize 中为自上次主合并以来发生的任何爬网包含的附加索引大小。

  • 由于其他项目、查询和安全描述符而随时间增大。

此外，处理为下一备份保留空间外，您可能还要在不同时间保留多个备份。

调整大小练习

使用上文提及的调整大小因素，下面是面向包含 1 亿个项目的服务器场的调整大小练习，该服务器场将主要对 SharePoint 内容查询提供服务。使用大型服务器场方案时，您应假定以下内容：

  • 需要 10 个逻辑索引分区来容纳 1 亿个项目。

  • 若要提供查询服务，您需要 10 个活动查询组件，每个索引分区一个。

  • 查询冗余很重要，因此您有 10 个故障转移查询组件，每个索引分区一个（与活动组件位于不同服务器上）。

若要确定存储和 RAM 需求，请执行以下步骤：

  1. 在具有多个内容数据库的 SharePoint 内容服务器场中，加上要爬网的内容数据库，共得到 20 TB。

  2. 使用上述索引系数，将 20 TB 乘以 0.035（索引系数），得到 716.8 GB。这是 TotalIndexSize。如果只有一个分区，则此值为静止索引的大小。

  3. 将 TotalIndexSize 除以分区数：716.8 GB / 71.68 GB。这是在使用一个索引分区时每个查询组件需要的索引大小 (QueryComponentIndexSize)。活动或故障转移查询组件的这一大小相同。

  4. 如果计划重新分区，请将 TotalIndexSize 乘以 4；否则，将其乘以 3，以支持主合并。71.68 GB * 4 = 286.72 GB。查询服务器的磁盘中应有 286.72 GB 可用空间来支持一个查询组件。如果同一应用程序服务器上有两个查询组件（正如我们在大型服务器场方案中建议的活动/故障转移拓扑），则应具有如下所述的磁盘驱动器布局：

    1. 操作系统驱动器（标准大小）。

    2. 额外存储系统 1：Query Component1_Share（大小 = 至少 300 GB），用于索引分区 1 中的活动查询组件。

    3. 额外存储系统 2：Query Component2_Share（大小 = 至少 300 GB）用于索引分区 2 中的故障转移（镜像）查询组件。

备注

在此应用程序服务器上，使用一个活动查询组件时，您至少需要 71.68 GB * 0.33 = 23.65 GB 的 RAM + 3 GB RAM 来用于操作系统，（我们使用 32 GB），以缓存大部分查询。

软件限制

下表给出了为了支持可接受的搜索体验而实施的软件限制。

对象 限制 其他注释

SharePoint Search Service 应用程序

每个服务器场建议的最大值是 20。服务应用程序总计的绝对最大值为 256。

由于可将搜索组件和数据库分配到不同的服务器中，因此可在同一个服务器场中部署多个 Search Service 应用程序。

编入索引的文档

建议的最大总项目数是每个索引分区 1000 万个项目，每个 Search Service 应用程序 10,000 万个项目。

SharePoint 搜索支持索引分区，其中每个索引分区包含整个搜索索引的子集。建议的最大值是给定分区中可包含 1,000 万个项目。建议的最大总项目（包括人员、列表项、文档和网页）数量是 10,000 万。

索引分区

每个 Search Service 应用程序建议的最大值是 20

此索引分区是 Search Service 应用程序的索引的逻辑子集。建议的限制是 20。增大索引分区数会减少索引分区中的项目数，从而减少查询服务器上保留分配给索引分区的查询组件所需的 RAM 和磁盘空间。但是，由于索引分区中的项目数减少，因此会影响相关性。索引分区的硬限制为 128。

属性数据库

建议限制为每个 Search Service 应用程序 10 个

属性数据库存储与之关联的每个关联索引分区中的项目的元数据。一个索引分区只能与一个属性存储相关联。建议限制为每个 Search Service 应用程序 10 个，应限制为 255（与索引分区相同）。

爬网数据库

限制为每个应用程序 32 个爬网数据库

爬网数据库存储有关已爬网的所有项目的爬网数据（包括时间和状态）。建议的限制是每个爬网数据库可包含 2,500 万个项目，或每个 Search Service 应用程序总计包含四个爬网数据库。

爬网组件

假定服务器至少具有八个处理器（内核），则每个应用程序建议的限制为总计包含 16 个爬网组件，其中，每个爬网数据库对应两个爬网组件，每台服务器对应两个爬网组件。

每台服务器可包含的爬网组件总数必须少于 128/（总查询组件数），从而最大程度地减少传播 I/O 性能下降。超过建议的限制不会提高爬网性能。实际上，爬网性能可能会根据爬网服务器、数据库和内容主机上的可用资源而相应降低。

查询组件

每个应用程序的建议限制为 128，每台服务器对应 64/（总爬网组件数）。

查询组件的总数受到爬网组件复制文件的能力的限制。每台服务器的最大查询组件数受到查询组件接收从爬网组件传播的文件的能力的限制。

并发爬网

建议限制为每个 Search Service 应用程序 20 个爬网

这是同时进行的爬网数。爬网是成本极高的搜索任务，不仅会影响其他应用程序负载，还会影响数据库负载。同时爬网数超过 20 个会导致总爬网率下降。

内容源

建议限制为每个 Search Service 应用程序 50 个内容源。

可超过建议的限制值，最大可达每个 Search Service 应用程序的硬边界 500。但是，应使用较少的起始地址，并且必须遵循并发爬网限制。

起始地址

建议限制为每个内容源 100 个起始地址。

可超过建议的限制，最大可达每个内容源的硬限制 500。但是，应使用较少的内容源。当您具有许多起始地址时，较好的方法是将其作为链接放在 HTML 页面上，然后让 HTTP 爬网程序遵循链接来爬网该页面。

爬网规则

建议限制为每个 Search Service 应用程序 100 个

可超过建议值；但是，爬网规则在搜索管理中的显示效果将降低。

爬网日志

建议限制为每个应用程序 100 00 万

这是爬网日志中各个日志条目的数量。它将遵循编入索引的文档限制。

按项目识别的元数据属性

硬限制是 10,000。

这是在对项目进行爬网时可确定的元数据属性的数量（并可能映射和用于查询）。

已爬网属性

每个 Search Service 应用程序 500,000 个

这些是在爬网过程中发现的属性。

托管属性

每个 Search Service 应用程序 100,000 个

这些是搜索系统在查询中使用的属性。已爬网属性将会映射到托管属性。建议每个托管属性最多有 100 个映射。超过此限制可能会降低爬网速度和查询性能。

范围

每个网站建议的限制值是 200

这是每个网站建议的限制。超过此限制可能会降低爬网效率，如果将作用域添加到显示组，这还会影响最终用户的浏览器延迟。另外，当作用域数超过建议的限制时，作用域在搜索管理中的显示效果也将降低。

显示组

每个网站 25 篇

用于通过用户界面分组显示作用域。超过此限制将使搜索管理作用域体验降级。

作用域规则

建议限制是每个作用域 100 条作用域规则，每个 Search Service 应用程序总共 600 条作用域规则。

超过此限制将降低新鲜度并推迟来自限定作用域的查询的可能结果。

关键字

每个网站集的建议限制值为 200

可超过建议的限制，最大可达到 ASP.NET 应用的每个网站集的最大限制 5,000（针对每个关键字给出五个最佳匹配）。关键字在网站管理用户界面上的显示效果将变差。通过编辑 Web.config 和 Client.config 文件 (MaxItemsInObjectGraph)，可修改 ASP.NET 应用的限制。

权威页面

建议限制为一个顶级权威页面，以及尽量少的二级和三级页面，同时实现所需相关性。

每个 Search Service 应用程序的每一相关级别的硬限制是 200，但添加其他页面可能不会实现所需的相关性。向第一相关级别添加关键网站。在第二或第三相关级别添加后续关键网站（一次添加一个），并在每次添加后评估相关性以确保实现所需的相关性效果。

通知

每个 Search Service 应用程序的建议限制值为 1,000,000

这是经测试的限制。

结果删除

一次操作中 100 个 URL

这是在一个操作中应从系统中删除的 URL 最大建议数。

优化

以下各节讨论了用于改进服务器场性能的方法。

许多因素都会影响性能。这些因素包括用户数量；用户操作的类型、复杂性和频率；操作中的回发数量；以及数据连接的性能。上述每个因素都会对服务器场吞吐量产生主要影响。在规划部署时，应仔细考虑上述每个因素。

搜索系统的容量和性能对其拓扑的依赖性很大。可通过增加现有服务器计算机的容量来向上扩展，或通过向拓扑中添加服务器来向外扩展。

搜索查询系统优化

通常，在出现以下任一情况后，需要进行搜索查询优化：

  • 用户抱怨查询延迟，因此我必须减少查询延迟。

  • 出现的搜索请求多于规划数量，性能开始下降，所以我必须增加查询吞吐量。

向外扩展或向上扩展查询子系统始终需要创建更多查询组件。如果现有查询服务器上有过多容量（RAM、IO 和 CPU），则可在遇到瓶颈时选择通过在该服务器上创建更多查询组件、增加 RAM、CPU 或 IO 来向上扩展。否则，可以选择向新服务器中创建更多查询组件（或移动现有组件）来向外扩展。

下一节显示项搜索查询系统中添加查询资源的各种方法。

如何减少查询延迟

添加查询组件以减少延迟

下图演示了在不同服务器上添加活动查询组件而不更改索引大小的效果。

用户负载对查询延迟的影响（第 75 个百分点值）

添加更多活动查询组件，以便在系统中的用户负载（以同时进行的用户查询数量度量）增加时保持次秒查询延迟。

添加查询处理器（查询和网站设置服务）以减少延迟

下图演示了在不同服务器上添加活动查询处理器服务而不更改查询系统的其他任何部分的效果。

用户负载对查询延迟的影响（第 75 个百分点值）

在不同服务器上启动查询和网站设置服务的其他活动实例，以便在系统中的用户负载（以同时进行的用户查询数量度量）增加时保持次秒查询延迟。

向外扩展以增加查询吞吐量

添加查询组件以增加查询吞吐量

下图演示了在不同服务器上添加活动查询组件而不更改索引大小的效果。

用户负载对具有不同数量查询组件的查询吞吐量的影响

添加更多活动查询组件，以便在系统中的用户负载（以同时进行的用户查询数量度量）增加时增加查询吞吐量。

添加查询处理器（查询和网站设置服务）以增加查询吞吐量

下图演示了在不同服务器上添加活动查询处理器服务而不更改查询系统的其他任何部分的效果。

用户负载对具有附加查询服务的查询吞吐量的影响

方案：在不同服务器上启动查询和网站设置服务的其他活动实例，以便在系统中的用户负载（以同时进行的用户查询数量度量）增加时增加吞吐量。

搜索爬网系统优化

通常，当用户抱怨结果本应存在但却不存在或者虽然存在但已过期时，需执行搜索爬网优化。

当您尝试在新鲜度目标内爬网内容源起始地址时，可能会遇到以下爬网性能问题：

  • 由于搜索爬网子系统中的 IOPS 瓶颈，导致爬网率很低。

  • 由于搜索爬网子系统中缺少 CPU 线程，导致爬网率很低。

  • 由于存储库的响应速度慢导致爬网率很低。

上述每个问题都假定爬网率很低。请参阅使用搜索管理报告 (SharePoint Server 2010)（给定软件生命周期的阶段），以便为一段时间内系统的典型爬网率建立基准。当此基准倒退时，下面的小节将显示用于解决这些爬网性能问题的各种方法。

爬网 IOPS 瓶颈

在确定爬网数据库或属性数据库为瓶颈后，必须向上或向外扩展爬网系统，以适应适当的解决方案解决瓶颈。下表显示添加 IOPS（另一个爬网数据库）如何改进爬网率（直至添加更多组件使其再次成为瓶颈）。

方案：始终检查爬网数据库，确保它不是瓶颈。如果爬网数据库 IOPS 已经成为瓶颈，则添加爬网组件或增加线程数没有帮助。

拓扑 （爬网组件/ 爬网数据库） CPU 百分比 RAM：缓存命中率 % 读取延迟 写入延迟 爬网速度（文档数/秒）

2 / 1 数据库

19.5

99.6

142 毫秒

73 毫秒

50

4 / 2 数据库

8.502

99.55

45 毫秒

75 毫秒

~75

6 / 2 数据库

22

99.92

55 毫秒

1050 毫秒

~75

爬网 CPU 线程瓶颈

如果有大量主机并且没有其他爬网瓶颈，则必须使用适当解决方案向上或向外扩展爬网系统。爬网程序对于每个 Search Service 应用程序最多可容纳 256 个线程。建议使用四核处理器，以充分发挥最大线程数量的全部功效。当确定存储库提供数据的速度足够快（请参阅下文中的“存储库中的爬网瓶颈”）时，可通过增加爬网程序线程数来提高从存储库中请求数据的速度，从而增加爬网吞吐量。可通过以下三种方法实现此目标：

  1. 使用以下 Windows PowerShell cmdlet 将索引器性能基本更改为“部分降低”或“最大”：

    • Get-SPEnterpriseSearchService | Set-SPEnterpriseSearchService –PerformanceLevel “Maximum”

      如果您所使用处理器的内核数少于四个，则使用“最大”值。

  2. 使用爬网程序影响规则增加每台主机的线程数。该规则应考虑支持的最大线程数为 256，为较少的主机分配大量线程会降低从其他存储库检索数据的速度。

  3. 如果有大量主机，则理想的解决方案是在单独的索引器上添加另一个爬网组件，以爬网要提高索引速度的主机。

如果搜索子系统不是 IOPS 的瓶颈并且存储库提供内容的速度很快，则无缝增加爬网吞吐量的理想方法是添加另一个索引器。

存储库中的爬网瓶颈

有时候，当爬网具有许多嵌套网站集或远程文件共享的 SharePoint Web 应用程序时，搜索爬网程序可能成为存储库的瓶颈。如果下列两种情况存在，则可确定存储库瓶颈：

  • 爬网服务器上的 CPU 利用率很低（低于 20%）。

  • 网络中有大量正在等待的线程（最糟糕的情况下，几乎所有线程都在等待）。

    通过查看 OSS Search Gatherer/线程访问网络性能计数器可以确定瓶颈。

此情况表示，线程在等待存储库中的数据时被阻止。在具有多个内容源的环境中，标识响应速度慢的主机可能很有用，具体方法是暂停所有其他爬网，然后使用以可疑主机作为一个起始地址的内容源执行爬网。

确定存在问题的主机后，需要研究响应速度慢的原因。特别是对于 SharePoint 内容，请参阅 Capacity management and sizing for SharePoint Server 2010一文。

通过对爬网的数据存储库进行性能调整，可以显著改进爬网吞吐量。

排查性能和缩放问题

在排查性能问题之前了解服务器场中的负载是非常关键的。下一节使用包含 6000 万个项目的活动场中的数据显示在搜索生命周期的不同阶段的各个系统指标。

搜索生命周期期间的性能示例

度量 索引获取 索引维护 索引清理

SQL Server CPU (%)

属性数据库/爬网数据库

14.8/19.13

35/55

11/63

SQL Server 页面生命预期

属性数据库/爬网数据库

60,548/5,913

83,366/5,373

33,927/2,806

SQL Server 平均磁盘写入/秒

属性数据库/爬网数据库

 9 ms / 48 ms

最大值：

466 ms / 1,277 ms

12 ms / 28 ms

20 ms / 49 ms

最大值：

253 ms / 1156 ms

SQL Server 平均磁盘读取/秒

属性数据库/爬网数据库

 8 ms / 43 ms

最大值：

1,362 ms / 2,688 ms

11 ms / 24 ms

24 ms / 29 ms

最大值：

2 039 ms / 2 142 ms

爬网程序 CPU（以百分比度量）

索引服务器 1（2 个爬网组件）/索引服务器 2（2 个爬网组件）

18/11

25.76/21.62

8.34/7.49

最大峰值达 99%

磁盘写入次数/秒

索引服务器 1（2 个爬网组件）/索引服务器 2（2 个爬网组件）

64.32/42.35

93.31/92.45

99.81/110.98

磁盘读取次数/秒

索引服务器 1（2 个爬网组件）/索引服务器 2（2 个爬网组件）

0.23/0.20

4.92/2.03

1.38/1.97

平均磁盘秒数/写入

索引服务器 1（2 个爬网组件）/索引服务器 2（2 个爬网组件）

 11 ms / 11 ms

1 ms / 2 ms

5 ms / 4 ms

最大值：

1,962 ms / 3,235 ms

平均磁盘秒数/读取

索引服务器 1（2 个爬网组件）/索引服务器 2（2 个爬网组件）

 1 ms / 2 ms

12 ms / 11 ms

10 ms / 16 ms

最大值：

2,366 ms / 5,206 ms

排查查询性能问题

SharePoint 搜索应用查询管道和关联的管理报告，可帮助您排查基于服务器的查询性能问题。有关详细信息，请参阅使用搜索管理报告 (SharePoint Server 2010)。本节显示报告，然后使用这些报告帮助了解如何排查服务器中的问题。此外，本节还包含有助于解决基于客户端（浏览器）的性能问题的工具和指导。

基于服务器的查询问题

基于服务器的查询性能问题可分为以下两个级别：

  • 搜索前端性能问题

  • 搜索后端性能问题

以下两个小节提供了用于排查每种问题的详细信息。请注意，这些是高级别的指导。

前端性能问题

排查前端性能的第一步应该是查看总体查询延迟搜索管理报告。下面是一个示例报告：

搜索查询延迟示例报表

在此报告中，前端性能由以下数据系列来表示：

  • 服务器呈现：此值表示对于给定的分钟，在前端 Web 服务器中的各个搜索 Web 部件中，每个查询所用的平均时间。

  • 对象模型：对于给定的分钟，此值表示在前端 Web 服务器与搜索后端之间的通信中所用的平均时间。

排查服务器呈现问题

在提供搜索结果页面的前端 Web 服务器上出现的任何情况都会影响服务器呈现问题。通常，您要了解检索各个 Web 部件所用的时间，以确定要添加额外延迟的位置。在详细延迟报告的搜索结果页面上启用开发人员仪表板（该链接可能指向英文页面）。表明服务器呈现延迟过长的常见问题包括：

  • 诸如以下的平台问题：

    • Active Directory 查找速度慢

    • SQL Server 时间慢

    • 在 SharePoint Server 2010 的人员查询或 FAST Search Server 2010 for SharePoint 的所有查询中对用户配置文件应用程序的请求慢

    • 用于获取用户首选项的请求慢

    • 用于从安全令牌服务获取用户令牌的调用慢

  • 代码后隐藏的问题，如签入但未发布的已修改搜索结果页面（如 results.aspx 和 peopleresults.aspx）。

排查对象模型问题

对象模型问题可能受以下因素的影响：

  • Windows Communication Foundation (WCF) 层的问题，例如：

    • 部署中的 WCF 调用中的超时和 threadabortexception。

    • 前端 Web 服务器和应用程序服务器之间的通信速度较慢。这可能是由于 IPsec 问题或网络连接速度慢引起的。

  • 内容和服务服务器场之间的通信问题（如果已配置）。

后端性能问题

排查后端查询性能问题的第一步应是查看 SharePoint 后端查询延迟搜索管理报告。下面是一个示例报告：

搜索后端查询延迟示例报表

在此报告中，后端性能由以下数据系列来表示（每个是给定分钟内每个查询所用的平均时间），按功能组件分组：

  • 查询组件：

    • 全文查询：用于查询结果的全文检索的平均时间。

  • 属性数据库：

    • 多个结果检索：用于检索要显示在查询结果中的文档元数据（例如标题或作者）的平均时间。

    • 属性存储查询：用于查询属性数据库的平均时间（适用于基于属性的查询）。

  • 搜索管理数据库：

    • 最佳匹配：用于确定是否存在查询词的最佳匹配项的平均时间。

    • 高可信度结果：用于检索查询的高可信度结果的平均时间。

  • 查询处理器：

    • 安全修整：用于移除用户无权访问的项目的平均时间。

    • 重复移除：用于移除重复项的平均时间。

    • 总体结果：用于创建要传回给对象模型的内存表的平均时间。

排查查询组件性能问题

查询组件会占用大量资源，特别是在组件处于活动状态（即响应查询请求）时。排查查询组件性能是最复杂的搜索区域之一。下面是要考虑的一般区域：

  • 占用资源最多的查询组件事件是主合并，其中映像索引与主索引合并。此事件针对每个查询组件独立发生。在下午 1:30 之前，在上文提及的 SharePoint 后端查询延迟报告中可以看到影响示例。如果此事件影响查询延迟，则除非更改百分比超出定义的限制，否则在此时间段内可避免主合并事件。

  • 如果环境值一直较高，则意味着可能应该执行以下操作：

    • 检查服务器上每个组件的索引大小。确保服务器上存在足够的 RAM，以允许缓存总索引大小的 33%。

    • 检查服务器上的查询组件 IO 通道。确保未遭遇 IO 瓶颈。

    • 如果 IO 和 RAM 不是造成性能问题的原因，则应对查询组件重新分区（添加索引分区），将其他查询组件向外扩展到新服务器。

排查属性数据库问题

使用存储和 SQL Server 容量规划和配置 (SharePoint Server 2010) 中的概念检查 SQL Server 运行状况。如果执行自定义查询，则可能需要查看提示来指导正确的查询计划。

排查搜索管理数据库问题

使用存储和 SQL Server 容量规划和配置 (SharePoint Server 2010) 中的概念检查 SQL Server 运行状况。

排查查询处理器问题

排查查询处理器问题取决于查询处理器的以下哪些区域正在影响查询延迟：

  • 安全修整：

    • 对于 Windows 声明，检查与托管查询处理器的服务器的 Active Directory 连接。

    • 对于所有情况，如果大量 SQL Server 循环之间存在关联（由 SQL Server 探查器确定），则可增加查询处理器使用的缓存大小。25% 以上的查询应不需要 SQL Server 调用来从搜索管理数据库中检索安全描述符。如果需要，请调整查询处理器缓存大小。

  • 重复移除：

    • 查看是否要在多个位置爬网相同的内容。在搜索中心中禁用重复检测。

  • 多个结果检索：

基于浏览器的查询问题

用户可能因搜索结果的速度而兴奋或恼怒。页面加载时间在影响用户对搜索体验满意度的重要因素之一。关于页面加载时间的大部分焦点都在服务器端，特别是服务器返回结果所需的时间。但是，客户端呈现构成了页面加载时间的重要部分，也是需要考虑的重要因素。

搜索用户体验的设计可为总页面加载时间提供次秒响应。在该时间之外，客户端呈现所需时间通常少于 280 毫秒，具体取决于浏览器和呈现度量。此体验可快速显示结果，用户一定会为之兴奋。

自定义结果体验很容易降低呈现性能。搜索管理员和开发人员必须在每次修改后注意度量呈现时间，以确保性能未显著下降。每次向页面中添加内容（从新的 Web 部件到新的级联样式表样式）都会延长浏览器中的呈现时间并为用户延迟结果。但是，延迟量会因您在自定义页面时是否遵循了最佳做法而存在显著差异。

下面是一些一般原则：

  • 页面的基本品牌和样式自定义导致的页面加载时间的延长量不应大于 25 毫秒。在实现自定义之前和之后都要度量页面加载时间，以观察更改。

  • 用户通常会注意到增量为 20% 的更改（更快或更慢）。在进行更改时请记住这一点。20% 的标准呈现时间只有 50 毫秒。（来源：设计和工程时间（该链接可能指向英文页面））

  • 级联样式表和 JScript 是高呈现性能的最常见也是最大原因。如果您必须自定义级联样式表和 JScript，则应确保分别将其最小化为一个文件。

  • JScript 可在页面呈现后按需加载，以快速为用户提供可视结果。性能注意事项一文详细讨论了如何执行此操作。

  • 添加到页面中的自定义项越多，页面加载速度越慢。请考虑与为用户带来结果的额外延迟相比，添加的功能和样式是否物有所值。

除了上述原则外，Internet 中还有大量关于如何缩短页面加载时间以及页面速度慢对用户体验的影响的信息。

排查爬网性能问题

当系统依次经历索引获取、维护和删除阶段时，SharePoint 搜索可能会在爬网子系统中遇到瓶颈。为了有效排查爬网性能问题，应将搜索运行状况监视报告与下文中的“常见瓶颈及其原因”一节结合使用，以消除爬网问题。

在索引获取阶段进行故障排除

确定爬网问题的第一个位置是“每个内容源的爬网率”运行状况报告。如下文所示，该报告概述了系统中每个内容源的爬网率。通常，人员内容源的爬网率应大于 15 个文档/秒，所有其他类型内容源的爬网率应大于 35 个文档/秒。

搜索爬网速率示例报表

在确定具有次优爬网率的内容源时，建议执行以下步骤：

  1. 暂停除了正在研究的内容源之外的所有其他爬网。爬网率经过改进是否超出指定的 15 到 35 个文档/秒的目标？

  2. 如果上一步没有帮助，则确保正在爬网的存储库的响应速度足够快，不是爬网缓慢的原因。请参考上文中的“存储库中的爬网瓶颈”一节。

  3. 如果存储库不是瓶颈，请在爬网服务器或数据库服务器中确定瓶颈并对其进行优化。在上文的“爬网 IOPS 瓶颈”和“爬网 CPU 线程瓶颈”部分可找到相关原则。

在索引维护阶段进行故障排除

在索引维护阶段的主要目标是尽量使索引保持新鲜。下面是两个重要指标：

  • **索引新鲜度：**爬网是否按照预算时间并根据索引新鲜度的 IT 原则完成？

  • **增量爬网速度：**如果不满足索引新鲜度目标，则研究人员内容源的增量爬网速度是否为 10 个文档/秒，所有其他内容源的增强爬网速度为 35 个文档/秒。如果增量爬网速度为次优，则应按如上所述对爬网的存储库和爬网子系统执行瓶颈分析。

常见瓶颈及其原因

在性能测试过程中，揭示了一些常见瓶颈。瓶颈是指达到了服务器场特定组成部分的容量的情况。这会导致服务器场吞吐量停滞或下降。

下表列出了一些常见瓶颈并介绍了其原因和可能的解决方法。

瓶颈 症状（性能计数器） 解决方法

数据库 RAM

属性数据库、

搜索管理数据库展示以下特点：

SQL Server 缓冲管理器/页面生命预期小于 300(s)（应大于 1000 (s)）

SQL Server 缓冲管理器/缓冲缓存命中率小于 96%（应大于 98%）

向数据库服务器中添加内存。

如果已禁用每周分段规则，则对属性数据库分段。

确保您使用的是 SQL Server 2008 Enterprise Edition，以启用页面压缩。

将数据库移至单独的服务器，并在必要时添加多个属性数据库。

数据库服务器 IOPS

属性数据库或爬网数据库展示以下特点：

平均磁盘秒数/读取和平均磁盘秒数/写入约等于 50 ms 或大于 50 ms

确保数据库服务器有足够的 RAM，可在缓存中保留 33% 的临界表 (MSSDocSDID + MSSDocProp + MSSDocresult)。

通过执行以下操作，为数据库增加专用的 IOPS 数量：

使用不同存储阵列

优化存储配置；例如，通过向存储阵列中添加轴（磁盘驱动器）。

运行 SharePoint Health Analyzer Search - 一个或多个属性数据库具有分段的索引规则（如果已禁用）。

运行 SharePoint Health Analyzer Search - 一个或多个爬网数据库具有分段的索引规则。

确保您使用的是 SQL Server 2008 Enterprise Edition，以便启用页面压缩。

将数据库移至单独服务器，必要时添加多个属性数据库和/或爬网数据库。

查询组件 IOPS

用于查询组件的索引的逻辑磁盘展示以下特点：

在持续的一段时间内，平均磁盘秒数/读取和平均磁盘秒数/写入约等于 30 ms 或大于 30 ms（也就是一天中的大部分时间；而不是只在索引合并期间）。

确保每台应用程序服务器有足够 RAM 在缓存（操作系统缓存）中保留每个查询组件索引的 33%（在该服务器上）。

通过执行以下操作为用于查询组件索引的驱动器增加专用的 IOPS 的数量：

对不同组件使用不同的存储阵列。

优化存储配置；例如，通过向存储阵列中添加轴（磁盘驱动器）。

关于作者

Brion Stone 是 Microsoft 的 SharePoint Server 搜索领域的高级项目经理。