SharePoint Server 2013 的容量规划
适用于：
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
本文介绍如何规划 SharePoint Server 2013 服务器场的容量。 当您对容量规划和管理具有强烈的爱好和深入的了解后，您就可以将知识应用到系统大小调整。 大小调整一词用于描述合适数据体系结构、逻辑和物理拓扑以及解决方案平台硬件的选择和配置。 有一系列容量管理和使用注意事项会影响你应如何确定最合适的硬件和配置选项。
阅读本文之前，您应该阅读 SharePoint Server 2013 的容量管理和调整大小概述。
重要
本文中的某些信息和值是基于测试结果和与 SharePoint 2010 产品相关的其他信息，并不代表 SharePoint Server 2013 的最终值。
在本文中，我们将介绍为您的环境执行有效的容量管理而应采取的步骤。 每个步骤都需要某些信息来成功执行，并且有一组可在后续步骤中使用的可交付结果。 对于每个步骤，表中概述了这些要求和可交付物。
步骤 1：模型
基于 SharePoint Server 2013 的环境建模首先分析现有解决方案，并估算计划设置的部署的预期需求和目标。 首先收集有关用户群、数据要求、延迟和吞吐量目标的信息，并记录要部署的 SharePoint Server 2013 功能。 使用本节了解您应收集的信息、如何收集以及如何将其用于后续步骤。
了解预期的工作负载和数据集
要对 SharePoint Server 2013 实施正确地进行大小调整，需要研究和了解您的解决方案需处理的需求特性。 了解需求需要能够描述工作负载特征（例如用户数和最常用的操作）和数据集特征（如内容大小和内容分发）。
本节可以帮助您了解您应收集的某些特定度量和参数以及收集时使用的机制。
Workload
工作负载描述系统将需要维持的需求，即用户群和使用特征。 下表提供了用于确定工作负载的某些关键度量。 您可以使用此表在收集时记录这些度量。
| 工作负载特性 | 值 |
|---|---|
| 每日平均 RPS |
|
| 平均峰值 RPS |
|
| 每天的唯一用户总数 |
|
| 每日平均并发用户数 |
|
| 高峰时的峰值并发用户数 |
|
| 每日的请求总数 |
|
| 预期的工作负载分布 |
|
| 不正确。 每天的请求数 |
|
| Web 浏览器 - 搜索爬网 |
|
| Web 浏览器 - 常规协作交互 |
|
| Web 浏览器 - 社交交互 |
|
| Web 浏览器 - 常规交互 |
|
| Web 浏览器 - Office Web Apps |
|
| Office 客户端 |
|
| OneNote 客户端 |
|
| SharePoint Workspace |
|
| Outlook RSS 同步 |
|
| Outlook Social Connector |
|
| 其他交互（自定义应用程序/Web 服务） |
并发用户 - 最常见的做法是在服务器场上执行操作的并发性，即在给定时间范围内生成请求的不同用户数。 关键指标是每日平均和峰值负载时的并发用户数。
每秒请求数 (RPS) - RPS 是用于描述服务器场上需求的常用指标，表示为服务器场每秒处理的请求数，但请求类型或大小并无区别。 每个组织的用户群生成系统负载的速率取决于组织的唯一使用特征。 有关详细信息，请参阅 术语表。
每日请求总数 - 每日请求总数是系统将需要处理的整体负载的良好指标。 在 24 小时内测量除身份验证握手请求 (HTTP 状态 401) 之外的所有请求都是最常见的。
每日用户总数 - 用户总数是系统将需要处理的整体负载的另一个关键指标。 此度量是 24 小时内唯一用户的实际数量，而不是组织中的员工总数。
注意
每日用户总数可能表示服务器场上的负载潜在增长。 例如，如果潜在用户数为 10 万名员工，每日 1.5 万名用户指示随着用户采用率增加负载可能随时间大大增加。
工作负载分布 - 了解基于与场交互的客户端应用程序的请求分布有助于预测迁移到 SharePoint Server 2013 后的预期趋势和负载变化。 随着用户过渡到更新的客户端版本（如 Office 2013）并开始使用新功能，新的加载模式、RPS 和总请求量预计将增加。 对于每个客户端，我们可以描述在一天的时间范围内使用它的不同用户的数量，以及客户端或功能在服务器上生成的请求总数。
例如，下图显示提供典型社交解决方案的在线内部 Microsoft 环境的快照。 在此示例中，可以看到大部分负载是由搜索爬网程序和典型的最终用户 Web 浏览生成的。 还可以观察到 Outlook 社交连接器功能引入了大量负载， (6.2% 的请求) 。
估计您的生产工作负载
估计服务器场需要能够承受的所需吞吐量时，首先估计服务器场中将使用的事务组合。 专注于分析系统将提供的最常用事务，并了解它们的使用频率以及用户数量。 以后在验证场是否可以在预生产测试中承受此类负载时，这种理解将有所帮助。
下图描述了系统上的工作负载和负载的关系：
要估计您预期的工作负载，请收集以下信息：
标识用户交互。 例如：
- 网页浏览。
- 文件下载和上传。
- 在浏览器中查看和编辑 Office Web 应用程序。
- 共同创作交互。
- SharePoint 工作区网站同步。
- Outlook 社交连接。
- Outlook 或其他查看者) 中的 RSS 同步 (。
- PowerPoint 广播。
- OneNote 共享笔记本。
- Excel 服务共享工作簿。
- 访问服务共享应用程序
有关详细信息，请参阅 服务和功能。 专注于识别可能特定于部署的交互。 识别此类负载的预期影响。 例如，大量使用 InfoPath 窗体、Excel 服务计算和类似的专用解决方案。
确定搜索增量爬网、每日备份、配置文件同步计时器作业、Web 分析处理、日志记录计时器作业等系统操作。
估计以下项目：
- 预计每天使用每项功能的用户总数。
- 派生估计的并发用户数和每秒高级请求数。
你将做出一些假设。 例如：
- 呈现并发性。
- 不同功能的每个并发用户的 RPS 因素
使用本部分前面的工作负荷表进行估算。 请务必关注高峰时段，而不是平均吞吐量。 通过规划高峰活动，您可以正确调整基于 SharePoint Server 2013 的解决方案的大小。
如果您有现有的 Office SharePoint Server 2007 解决方案，则可以挖掘 IIS 日志文件或查看其他 Web 监视工具，以便更好地了解现有解决方案中的某些预期行为。 否则，请参阅以下部分中的说明了解更多详细信息。 如果不从现有解决方案迁移，则应使用粗略估计值填写表。 在后续步骤中，需要验证假设并优化系统。
分析 SharePoint Server 2013 IIS 日志
需要从 ULS 和 IIS 日志中提取数据，以发现有关现有 SharePoint Server 2013 部署的关键指标。 例如：
- 活动用户数。
- 他们使用系统的量。
- 传入的请求类型。
- 请求源自哪种类型的客户端。
查找此数据的最简单方法之一是使用 Log Parser，这是一种可从 Microsoft 免费下载的强大工具。 日志分析器可以读取和写入许多文本和二进制格式，包括所有 IIS 格式。
可以在 下载 Log Parser 2.2 https://www.microsoft.com/downloads/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07。
数据集
数据集描述存储在系统中的内容卷及其在数据存储中的分配方式。 下表提供了用于确定数据集的部分关键指标。 您可以在收集这些指标时使用该表进行记录。
| Object | 值 |
|---|---|
| 数据库大小（以 GB 为单位） | |
| 内容数据库的数目 | |
| 网站集的数量 | |
| Web 应用程序的数目 | |
| 网站的数量 | |
| 搜索索引大小（项数） | |
| 文档数量 | |
| 列表数目 | |
| 网站平均大小 | |
| 最大网站大小 | |
| 用户配置文件数量 |
内容大小 - 了解您预期存储在 SharePoint Server 2013 系统中的内容大小对于规划和构建系统存储，以及对爬网和索引此内容的搜索解决方案进行大小调整至关重要。 内容大小描述为总磁盘空间。 如果要从现有部署迁移内容，你可能会发现确定要移动的总内容大小很简单。 在规划期间，应为随时间推移的增长留出空间。
文档总数 - 除了数据料料库大小外，跟踪项的总数很重要。 如果 100 GB 的数据由 50 个 2 GB 文件和 100,000 个 1 KB 文件组成，系统的反应将大不相同。 在大型部署中，单个项目、文档或文档区域的压力越小，性能就越好。 与包含大型文件的单个大型文档库相比，跨多个网站和网站集的多个较小文件等广泛分布的内容更易于提供。
最大网站集大小 - 请务必确定在 SharePoint Server 2013 中存储的最大内容单元;通常，这是一个组织需求，会阻止你拆分该内容单元。 所有网站集的平均大小和估计的网站集总数是有助于确定首选数据体系结构的其他指标。
服务应用程序数据特征 - 除了分析内容存储的存储需求外，还应分析和估计其他 SharePoint Server 2013 存储的大小，包括：
搜索索引的总大小
基于配置文件存储区中的用户数的配置文件数据库总大小
基于预期的标记、同事和活动数的社交数据库总大小
元数据存储区大小
使用数据库的大小
Web 分析数据库的大小
设置服务器场的性能和可靠性目标
步骤 1：模型的可交付结果之一是更好的了解最符合组织需求的性能和可靠性目标。 设计正确的 SharePoint Server 2013 解决方案应能够实现“四个 9” (99.99% ) 运行时间，并且服务器响应能力低于秒。
用于描述服务器场的性能和可靠性指标包括：
服务器可用性：按系统总运行时间百分比描述。 您应该跟踪任何非预期的停机时间并将总体可用性与您设定的组织目标相比较。 目标通常由许多九 (描述，即 99%、99.9%、99.99%)
服务器响应能力：服务器场处理请求所花费的时间是跟踪服务器场运行状况的良好指标。 此指示器称为 服务器端延迟。 Tt 通常使用平均值或中位数 (所处理的每日请求的第 50 个百分位) 延迟。 目标通常以秒或秒为单位进行描述。 如果目标是在不到两秒内提供页面，则服务器端目标应为几分之一秒。 这种提高的性能允许页面到达客户端并在浏览器中呈现。 此外，服务器响应时间较长通常表明服务器场运行不正常。 如果你在服务器上花费超过一秒的时间处理大多数请求，则 RPS 很少能跟上。
服务器高峰度：值得跟踪的另一个良好的服务器端延迟指示器是所有请求中速度最慢的 5% 的行为。 较慢的请求通常是在系统负载较高时（甚至更常见的）在用户与系统交互时发生的不太频繁的活动影响的请求;正常的系统也是具有控制最慢请求的系统。 此处的目标类似于服务器响应能力，但若要在服务器高峰度上实现亚秒级响应，需要生成具有大量备用资源的系统来处理负载高峰。
系统资源利用率：用于跟踪系统运行状况的其他常见指标是系统计数器的集合，这些计数器指示服务器场拓扑中每个服务器的运行状况。 最常用的跟踪指标是 CPU 使用率百分比和可用内存;但是，还有几个计数器可以帮助识别非健康系统：可在 步骤 5：监视和维护中找到更多详细信息。
步骤 2：设计
现在，你已经收集了有关需要交付的解决方案的一些事实或估计，接下来可以开始下一步，设计一个建议的体系结构，你预测该体系结构能够维持预期的需求。
此步骤结束时，您应该已经设计好物理拓扑并具有逻辑拓扑的布局，因此您应该能够继续完成任何必要的采购订单。
硬件规范和您布局的计算机数量与处理存在可选择部署的多个解决方案的特定负载密切相关。 通常，要么使用一小组强计算机 (纵向扩展) ，要么使用一组更大的小型计算机 (横向扩展) ;在容量、冗余、电源、成本、空间和其他注意事项方面，每个解决方案都有其优缺点。
我们建议您首先确定体系结构和拓扑。 定义计划如何布局不同的场和每个服务器场中的不同服务，然后为设计中的每个单独服务器选择硬件规格。 还可以通过确定预期部署的硬件规范来执行此过程， (许多组织都受特定公司标准) ，然后定义体系结构和拓扑。
使用下表记录您的设计参数。 包含的数据是示例数据，不用于调整服务器场的大小。 它旨在演示如何将此表用于你自己的数据。
| Role | 类型（标准或虚拟） | 计算机数量 | 处理器数量 | RAM | IOPS 需求 | 磁盘大小 OS + 日志 | 数据驱动器 |
|---|---|---|---|---|---|---|---|
| Web 服务器 | 虚拟 | 4 | 4 核 | 8 | 不适用 | 400 GB | N/A |
| 内容数据库服务器 | 标准 | 1 个群集 | 4 个四核 2.33 (GHz) | 48 | 2k | 400 GB | 20 个磁盘（300 GB） @ 15K RPM |
| 应用程序服务器 | 虚拟 | 4 | 4 核 | 16 | 不适用 | 400 GB | 不适用 |
| 搜索爬网目标 Web 服务器 | 虚拟 | 1 | 4 核 | 8 | 不适用 | 400 GB | 不适用 |
| 搜索查询服务器 | 标准 | 2 | 2 个四核 2.33 (GHz) | 32 | 不适用 | 400 GB | 500 GB |
| 搜索爬网服务器 | 标准 | 2 | 2 个四核 2.33 (GHz) | 16 | 400 | 400 GB | 不适用 |
| 搜索爬网数据库服务器 | 标准 | 1 个群集 | 4 个四核 2.33 (GHz) | 48 | 4k（针对读取进行优化） | 100 GB | 16 个磁盘，150 GB @ 15K RPM |
| 搜索属性存储数据库 + 管理数据库服务器 | 标准 | 1 个群集 | 4 个四核 2.33 (GHz) | 48 | 2k（针对写入进行优化） | 100 GB | 16 个磁盘，150 GB @ 15K RPM |
确定起点体系结构
本节介绍如何选择起点体系结构。
部署 SharePoint Server 2013 时，可以从一系列拓扑中进行选择来实现解决方案;您可以使用群集或镜像数据库服务器以及各种服务的谨慎应用程序服务器部署单个服务器或横向扩展到 SharePoint Server 2013 场。 稍后，根据每个角色的要求，根据容量、可用性和冗余需求选择硬件配置。
首先检查不同的参考体系结构并确定您的服务器场结构，确定您是否应在多个服务器场之间拆分解决方案或在专用服务器场联合多种服务，例如搜索。 有关详细信息，请参阅 参考体系结构。
SharePoint Server 2010 技术案例研究
SharePoint Server 2013 的容量管理指南包括现有生产环境的许多技术案例研究，这些案例研究详细说明了基于 SharePoint Server 2013 的现有生产环境。 特定于 SharePoint Server 2013 的技术案例研究将在可用时发布：现有 SharePoint Server 2010 案例研究可以作为有关如何为特定目的设计基于 SharePoint Server 2013 的环境的参考。
在设计 SharePoint Server 2013 解决方案的体系结构时，可以将这些案例研究用作参考，尤其是当您发现这些部署特定关键差异的说明与所构建的解决方案的需求和目标类似时。
这些文档介绍了每个记录在案的案例研究的以下信息：
规范，例如硬件、场拓扑和配置;
工作负载 ，包括用户群和使用特征；
数据集，包括内容大小、内容特征和内容分发
运行状况和性能 ，包括描述服务器场的可靠性和性能特征的一组记录指标。
有关详细信息，请从 Performance and capacity technical case studies (SharePoint Server 2010)（性能和容量技术案例研究 (SharePoint Server 2010)）页下载相关文档。
选择硬件
为服务器场中的计算机选择正确的规范是确保部署的相应可靠性和性能的关键步骤，需要牢记的一个关键概念是您应规划峰值负载和峰值时间；换句话说，当您的服务器场在平均负载条件下运行时，应有足够可用的资源来处理最大的预期需求，同时仍达到延迟和吞吐量目标。
服务器的核心容量和性能硬件功能分为四个主要类别：系统的处理能力、磁盘性能、网络容量和内存功能。
要注意的另一事项是使用虚拟机。 可以使用虚拟机部署 SharePoint Server 2013 场。 尽管尚未发现虚拟化可以添加任何性能优势，但它确实提供了可管理性优势。 不建议虚拟化基于 SQL Server 的计算机，但虚拟化 Web 服务器和应用程序服务器层可能会带来一些好处。 有关详细信息，请参阅 虚拟化规划 (/previous-versions/office/sharepoint-server-2010/ff607968 (v=office.14) ) 。
有关硬件要求的详细信息，请参阅 SharePoint Server 2016 的硬件和软件要求。
硬件选择指南
选择处理器
SharePoint Server 2013 仅适用于 64 位处理器。 通常情况下，处理器更多，即可满足更多的需求。
在 SharePoint Server 2013 中，当您添加更多内核时，各个 Web 服务器将向上扩展。 服务器拥有的内核越多，它能承受的负载越多，所有负载均相等。 在大型 SharePoint Server 2013 部署中，建议分配多个可) 虚拟化的 4 核 Web 服务器 (，或者) Web 服务器分配更少的 (8-/16-/24 核。
应用程序服务器的处理器容量要求因服务器的角色及其正在运行的服务而异。 某些 SharePoint Server 2013 功能需要比其他功能更高的处理能力。 例如，SharePoint Search Service 高度依赖于应用程序服务器的处理能力。
SQL Server 的处理器容量要求也取决于基于 SQL Server 的计算机托管的服务数据库。
选择内存
您的服务器所需的内存量因服务器功能和角色而异。 例如，如果运行搜索爬网组件的服务器具有大量内存，它处理数据的速度将更快，因为文档将读取到内存中进行处理。 利用 SharePoint Server 2013 的众多缓存功能的 Web 服务器也可能需要更多内存。
Web 服务器内存要求通常主要取决于服务器场中启用的应用程序池数量以及当前服务的并发请求数。 在大多数生产 SharePoint Server 2013 部署中，建议在每个 Web 服务器上至少分配 8 GB RAM，对于流量较大的服务器或部署，建议为隔离设置多个应用程序池的服务器分配 16 GB RAM。
应用程序服务器的内存要求也不同：某些 SharePoint Server 2013 功能对应用程序层的内存要求比其他功能更高。 在大多数生产 SharePoint Server 2013 部署中，建议在每个应用程序服务器上至少分配 8 GB RAM;如果在同一服务器上启用了许多应用程序服务，或者启用了高度依赖内存的服务（如 Excel Calculation Service 和 SharePoint Server 2013 Search Service），则 16 GB、32 GB 和 64 GB 应用程序服务器很常见。
数据库服务器的内存要求与数据库大小密切相关。 有关为基于 SQL Server 的计算机选择内存的详细信息，请参阅 存储和 SQL Server 容量规划和配置 (SharePoint Server) 。
选择网络
除了为用户提供的好处外，如果客户端可以通过网络快速访问数据，分布式场还必须具有服务器间通信的快速访问权限。 当您在多个服务器之间分配服务或将某些服务联合到其他服务器场时，这一点尤为明显。 服务器场中跨 Web 服务器层、应用程序服务器层和数据库服务器层的大量流量，在某些情况下（例如处理大型文件或高负载）时，网络很容易成为瓶颈。
Web 服务器和应用程序服务器应该配置为至少使用两个网络接口卡 (NIC)：一个 NIC 用于处理最终用户流量，另一个用于处理服务器间通信。 服务器之间的网络延迟对性能具有重大影响。 因此，在 Web 服务器与托管内容数据库的基于 SQL Server 的计算机之间保持小于 1 毫秒的网络延迟非常重要。 托管每个服务应用程序数据的、基于 SQL Server 的计算机还应尽量与使用应用程序服务器靠近。 服务器场服务器之间的网络应至少具有 1 GB 带宽。
选择磁盘和存储
磁盘管理不仅仅是为数据提供足够空间的功能。 必须评估持续的需求和增长，并确保存储体系结构不会降低系统速度。 应始终确保每个磁盘上至少有 30% 的额外容量（高于最高数据要求估计值），以便为将来的增长留出空间。 此外，在大多数生产环境中，磁盘速度 (IOps) 对于提供足够的吞吐量以满足服务器的存储需求至关重要。 您必须估计主要数据库在您的部署中所需的流量 (IOps) 并分配足够的磁盘以满足此流量需求。
有关如何为数据库服务器选择磁盘的详细信息，请参阅 存储和 SQL Server 容量规划和配置 (SharePoint Server) 。
Web 服务器和应用程序服务器还具有存储需求。 在大多数生产环境中，我们建议您为操作系统和临时服务器分配至少 200 GB 的磁盘空间，为日志分配 150 GB 的磁盘空间。
步骤 3：试点、测试和优化
测试和优化阶段是有效容量管理的重要组成部分。 您应在将新体系结构部署到生产之前对其进行测试，并根据以下监视最佳做法执行验收测试，确保您设计的体系结构达到性能和容量目标。 这样您即可在影响实际部署中的用户之前识别和优化潜在瓶颈。 如果要从 Office SharePoint Server 2007 环境升级并计划进行体系结构更改，或者正在估算新 SharePoint Server 2013 功能的用户负载，则测试非常重要，以确保新的基于 SharePoint Server 2013 的环境满足性能和容量目标。
测试环境后，您即可分析测试结果以确定必须进行哪些变更以满足您在步骤 1：模型中设定的性能和容量目标。
下面是预生产的子步骤：
模仿您在步骤 2：设计中设计的初始体系结构创建测试环境。
使用您在步骤 1：模型中识别的数据集或部分数据集填充存储。
使用代表您在步骤 1：模型中识别的工作负荷的综合负荷来为系统增加压力。
运行测试、分析结果并优化您的体系结构。
将已优化的体系结构部署到数据中心，然后推出具有较小用户组的试验。
分析试验结果、标识潜在瓶颈，并优化体系结构。 如果需要，请重新测试。
部署到生产环境。
测试
测试是确定系统设计支持工作负载和使用特征的能力的关键因素。 有关如何测试 SharePoint Server 2013 部署的详细信息，请参阅SharePoint Server 2013 的性能测试。
创建测试计划
创建测试环境
创建测试和工具
部署试生产环境
在将 SharePoint Server 2013 部署到生产环境之前，请务必首先部署一个试点环境，并彻底测试服务器场，以确保它能够满足预期峰值负载的容量和性能目标。 我们建议先使用合成负载（尤其是大型部署）测试试点环境，然后通过一小组实时用户和实时内容进行压力测试。 通过对使用少量活动用户的试生产环境进行分析，可以有机会在完全进入生产中之前验证您对使用特征和内容增长的一些假设。
优化
如果无法通过缩放场硬件或更改拓扑来满足容量和性能目标，则可能必须考虑修改解决方案。 例如，如果您的初始要求是针对单个服务器场的协作、搜索和社交，您可能必须将搜索等几项服务联合到专用服务场，或在多个服务器场之间拆分工作负载。 一种替代方法是部署一个专用服务器场用于社交，另一个用于团队协作。
步骤 4：部署
执行最后一轮测试并确认体系结构后，选择可以实现在 步骤 1：模型中建立的性能和容量目标后，可以将基于 SharePoint Server 2013 的环境部署到生产环境。
相应的部署策略根据环境和具体情况而有所不同。 虽然 SharePoint Server 2013 部署通常超出了本文档的范围，但容量规划练习中可能会有某些建议的活动。 下面是一些示例：
部署新的 SharePoint Server 2013 场： 容量规划练习应指导和确认 SharePoint Server 2016 的设计和部署计划。 在这种情况下，部署将为 SharePoint Server 2013 的首次广泛部署。 它要求将在容量规划做法中使用的服务器和服务移动或重新构建到生产。 这是最直接的方案，因为不需要对现有场进行任何升级或修改。
将 Office SharePoint Server 2007 场升级到 SharePoint Server 2013： 容量规划练习应已验证满足现有需求并纵向扩展以满足 SharePoint Server 2013 场增加的需求和使用量的服务器场的设计。 容量规划练习的一部分应包括测试迁移，以验证升级过程需要多长时间、是否必须修改或替换任何自定义代码、是否需要更新任何第三方工具等。 在容量规划结束时，你应该有一个经过验证的设计，并了解升级所需的时间，并计划如何最好地完成升级过程（例如，就地升级或将内容数据库迁移到新场）。 如果要执行就地升级，则在容量规划期间，你可能发现需要额外的或升级的硬件，以及停机时间的注意事项。 规划做法的部分输出应为所需硬件变更的列表以及将硬件变更部署到服务器场的详细计划。 在容量规划期间验证的硬件平台到位后，可以继续升级到 SharePoint Server 2013 的过程。
提高现有 SharePoint Server 2013 场的性能： 容量规划练习应已帮助你识别当前实现中的瓶颈，规划减少或消除这些瓶颈的方法，并验证满足 SharePoint Server 2013 服务业务需求的改进实现。 可以通过不同的方法解决性能问题，例如跨现有硬件重新分配服务、升级现有硬件或添加更多硬件和向其添加更多服务等。 应在容量规划做法中对不同的方法进行测试和验证，然后根据测试结果设计部署计划。
步骤 5：监视和维护
要维护系统性能，您必须监视服务器以发现潜在的瓶颈。 为了有效地进行监视，您必须了解指示服务器场的某个特定部件是否需要关注的关键指标，以及如何解释这些指标。 如果您发现您的服务器场未达到您定义的运行目标，您可以通过添加或删除硬件资源、更改拓扑或更改数据存储方式来调整服务器场。
请参阅监视和维护 SharePoint Server 2013 查看您在早期阶段可以更改以监视环境的设置列表，这将帮助您确定是否需要进行任何更改。 请记住，提高您的监视功能会影响使用数据库将需要多少磁盘空间。 环境稳定且不再需要此详细监视后，可能需要将下面的设置反转为默认设置。
有关使用 SharePoint Server 2013 管理中心界面中内置的运行状况监视工具进行运行状况监视和故障排除的详细信息，请参阅：
SharePoint Server 2016 中的监视和报告功能
另请参阅
概念
SharePoint Server 2016 的软件边界和限制
性能和容量测试结果和建议 (SharePoint Server 2013)
其他资源
Capacity management and sizing overview for SharePoint Server 2013
Performance and capacity technical case studies (SharePoint Server 2010)