SharePoint Server 2010 的容量规划

项目
03/04/2017

适用于： SharePoint Server 2010

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

本文介绍如何规划 Microsoft SharePoint Server 2010 场的容量。如果您对容量规划和管理有良好的评价和了解，可以将您的知识应用于系统大小调整。大小调整一词用于描述适当数据体系结构的选择和配置、逻辑和物理拓扑以及解决方案平台的硬件。有许多容量管理和使用注意事项都会影响您应如何确定最适当的硬件和配置选项。

在阅读本文之前，您应阅读 SharePoint Server 2010 的容量管理和调整大小概述。

在本文中，我们将介绍对环境实施有效的容量管理所应采取的步骤。每个步骤都需要某些信息才能成功执行，并具有一组将在后续步骤中使用的可交付结果。对于每个步骤，表中列出了这些要求和可交付结果。

本文内容：

步骤 1：建模
步骤 2：设计
步骤 3：试验、测试和优化
步骤 4：部署
步骤 5：监视和维护

步骤 1：建模

为基于 SharePoint Server 2010 的环境建模应首先分析现有解决方案并估计计划设置的部署的预期需求和目标。首先收集有关您的用户群、数据要求、延迟和吞吐量目标的信息，并记录要部署的 SharePoint Server 功能。使用本节了解应收集的数据、收集方法以及在后续步骤中使用这些数据的方法。

了解预期工作量和数据集

适当调整所实施的 SharePoint Server 2010 的大小要求您研究并了解您的解决方案预期处理的需求特征。了解需求要求您能够描述工作量特征（例如用户数和最常用的操作）及数据集特性（例如内容大小和内容分发）。

本节可帮助您了解一些应收集的特定指标和参数以及收集它们所采用的机制。

工作量

工作量描述系统将需要满足的需求、用户群和使用特征。下表提供了一些有助于确定您的工作量的关键指标。在收集这些指标时，可使用此表进行记录。

工作量特征	值
平均每日 RPS
高峰时段的平均 RPS
每日唯一用户总数
平均每日并发用户数
高峰时段的最大并发用户数
每日请求总数
预期工作量分配	每日请求数
Web 浏览器 - 搜索爬网
Web 浏览器 - 常规协作交互
Web 浏览器 - 社会交互
Web 浏览器 - 常规交互
Web 浏览器 - Office Web Apps
Office 客户端
OneNote 客户端
SharePoint Workspace
Outlook RSS 同步
Outlook Social Connector
其他交互（自定义应用程序/Web 服务）

并发用户数 - 最常见的情况是通过给定时间段内生成请求的不同用户数来测量服务器场上执行的操作的并发性。关键指标是每日平均数和最大负载时的并发用户数。
每秒的请求数 (RPS) - RPS 是用于描述服务器场上的需求的常用指标，由服务器场每秒处理的请求数表示，但不区分请求的类型或大小。每个组织的用户群产生系统负荷的速率取决于组织的独特使用特征。有关此术语的详细信息，请参阅 SharePoint Server 2010 的容量管理和调整大小概述中的“词汇表”一节。
每日请求总数 - 每日请求总数是系统将需要处理的总负载的很好指标。最常测量 24 小时内的所有请求数，身份验证握手请求（HTTP 状态 401）除外。
每日用户总数 - 用户总数是系统将需要处理的总负载的另一个关键指标。此度量值是 24 小时内唯一用户的实际数，而不是组织中的员工总数。

备注

每日用户总数可以指示服务器场上负载的增加潜力。例如，如果潜在用户数是 10 万员工，则 1.5 万的每日用户数指示负载可能会随着用户使用率的不断增加而大幅增加。
工作量分配 - 了解基于与服务器场交互的客户端应用程序的请求分配可以帮助在迁移到 SharePoint Server 2010 后预测预期趋势和负载更改。在用户切换到较新的客户端版本（例如 Office 2010）并开始使用新功能新负载模式时，RPS 和请求总数预计会增加。对于每个客户端，我们可以描述在一天的某个时间段内使用它的不同用户数以及客户端或功能在服务器上产生的请求总数。

例如，下图显示了为典型社会解决方案服务的实时内部 Microsoft 环境的快照。在此示例中，可以看到大部分负载由搜索爬网程序和典型的最终用户 Web 浏览产生。您还可以观察到新的 Outlook Social Connector 功能引入了大量负载（占请求数的 6.2%）。

典型的每日请求负载分配

估计您的生产工作量

在估计您的服务器场需要能够维持的所需吞吐量时，首先估计您的服务器场中将使用的事务混合。重点分析系统将服务于的最常用事务，了解它们将由多少用户多久使用一次。这将帮助您稍后在预生产测试中验证服务器场是否可以承受此类负载。

下图说明工作量和系统上的负载之间的关系：

容量 - 工作负荷示意图

若要估计您的预期工作量，请收集以下信息：

识别用户交互，例如典型网页浏览、文件下载和上载、浏览器中的 Office Web Application 查看和编辑、共同创作交互、SharePoint Workspace 网站同步、Outlook Social Connector、RSS 同步（在 Outlook 或其他查看器中）、PowerPoint 广播、OneNote 共享笔记本、Excel Service 共享工作簿、Access Service 共享应用程序等。有关详细信息，请参阅 SharePoint Server 2010 的容量管理和调整大小概述一文的服务和功能一节。重点识别您的部署可能独有的交互并识别此类负载的预期影响，例如大量使用 InfoPath 表单、Excel Service 计算及类似的专用解决方案。
识别系统操作，例如搜索增量爬网、每日备份、配置文件同步计时器作业、Web 分析处理、日志记录计时器作业及其他。
估计每天预计利用各功能的用户总数，派生出估计的并发用户数和每秒的高级请求数，您将进行一些假定（例如当前的并发性和各功能不同的每个并发用户的 RPS 的因素），您应使用本节中前面的工作量表进行估计。关注高峰时段（而不是平均吞吐量）很重要。通过规划高峰活动，您能够适当调整基于 SharePoint Server 2010 的解决方案的大小。

如果您已有 Office SharePoint Server 2007 解决方案，可以挖掘 IIS 日志文件或查看您具有的其他 Web 监视工具以更好地了解现有解决方案的一些预期行为或查看下节中的说明来了解详细信息。如果您不是从现有解决方案迁移的，则应使用粗略估计值填写表格。在后续步骤中，您将需要验证您的假定并调整系统。

分析 SharePoint Server 2010 IIS 日志

若要发现有关现有 SharePoint Server 2010 部署的关键指标（例如活动的用户数、他们使用系统的频繁程度、进来哪类请求及其源自哪类客户端），需要从 ULS 和 IIS 日志中提取数据。获得此数据的最简单方法之一是使用日志分析程序，它是可从 Microsoft 免费下载的功能强大的工具。日志分析程序可以读取和写入许多文本和二进制格式，包括所有 IIS 格式。

有关如何使用日志分析程序分析 SharePoint Server 2010 使用情况的详细信息，请阅读分析 Microsoft SharePoint 产品和技术使用情况（该链接可能指向英文页面） (https://www.microsoft.com/downloads/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e\&displaylang=en)。

可以在 https://www.microsoft.com/download/en/details.aspx?id=24659（该链接可能指向英文页面）上下载 Log Parser 2.2。

数据集

数据集描述系统中存储的内容量及其如何分布在数据存储中。下表提供了一些有助于确定您的数据集的关键指标。在您收集这些指标时，可以使用此表来记录这些指标。

对象	值
数据库大小（以 GB 为单位）
内容数据库的数量
网站集数量
Web 应用程序的数量
网站数量
搜索索引大小（项目数）
文档数量
列表数量
网站的平均大小
网站的最大大小
用户配置文件的数量

内容大小 - 了解预期存储在 SharePoint Server 2010 系统中的内容大小对规划和构建系统存储非常重要，同时对适当调整将对此内容进行爬网和编制索引的搜索解决方案大小也非常重要。以总磁盘空间描述内容大小。如果您要从现有部署迁移内容，则可能会发现确定将移动的总大小很简单；而在规划时，应基于预测趋势为随时间的增长留出空间。
文档的总数量 - 除了数据集大小之外，跟踪项目的总数量也很重要。对于由 50 个 2 GB 文件组成的 100 GB 数据与由 100,000 个 1 KB 文件组成的 100 GB 数据，系统的反应会有所不同。在大型部署中，单个项目、文档或文档区域上的压力越小，性能将越好。与具有非常大的文件的单个大型文档库相比，广泛分布的内容（例如跨许多网站和网站集的多个较小文件）更易于处理。
网站集的最大大小 - 识别将存储在 SharePoint Server 2010 中的内容的最大单位很重要；通常，这是组织需求，可防止拆分该单位内容。所有网站集的平均大小和网站集的估计总数量是可帮助您确定首选数据体系结构的其他指标。
服务应用程序数据特征 - 除了分析内容存储的存储需要，您还应该分析和估计其他 SharePoint Server 2010 存储的大小，其中包括：
搜索索引的总大小
基于配置文件存储中的用户数的配置文件数据库总大小
基于预期数量的标记、同事和活动的社会数据库总大小
元数据存储大小
使用率数据库的大小
Web Analytics 数据库的大小

有关如何估计数据库大小的详细信息，请参阅存储和 SQL Server 容量规划和配置 (SharePoint Server 2010)。

设置服务器场性能和可靠性目标

步骤 1：建模的可交付结果之一是很好地了解最符合组织需要的性能和可靠性目标。设计合理的 SharePoint Server 解决方案的运行时间应能达到“四个九”(99.99%)，服务器响应速度应在一秒以内。

用于描述服务器场的性能和可靠性的指标包括：

服务器可用性 - 通常由系统的总运行时间百分比来描述。您应该跟踪任何意外停机时间并将总体可用性与所设置的组织目标进行比较。目标通常由多个 9 来描述（即 99%、99.9%、99.99%）
服务器响应速度 - 服务器场为请求提供服务所需的时间是用于跟踪服务器场运行状况的一个很好指标。此指标通常称为服务器端延迟，并且通常使用所服务的每日请求的延迟的平均数或中间数（第 50 个百分点值）。目标通常以一秒或几秒以内来描述。请注意，如果组织的目标是以两秒以内的时间为 SharePoint Server 2010 的网页提供服务，则服务器端目标需要在一秒以内，以便为网页通过网络到达客户端并呈现在浏览器中留出时间。另外，服务器响应时间较长通常指示服务器场运行状况不佳，因为这通常会影响吞吐量，并且如果服务器为大多数请求花费的时间超过一秒，则 RPS 很少能够维持下去
服务器峰值 - 另一个值得跟踪的很好的服务器端延迟指标是所有请求中最慢的 5% 的行为。较慢的请求通常是在系统负载较高时到达系统的请求，更常见的是受用户与系统交互时发生的不太常用的活动影响的请求；运行状况良好的系统是最慢的请求也在控制之下的系统。它的目标与服务器响应速度类似，但若要在服务器峰值时实现一秒以内的响应时间，您构建的系统将需要具有许多备用资源以处理负载峰值。
系统资源利用率 - 用于跟踪系统运行状况的其他常用指标是一组系统计数器，用于指示服务器场拓扑中每台服务器的运行状况。要跟踪的最常用指标是 CPU 使用率和可用内存；但是，有几个其他计数器可帮助识别运行状况不佳的系统；可在步骤 5：维护中找到更多详细信息。

步骤 2：设计

现在您已完成有关所需提供的解决方案的一些事实或估计的收集，可以开始下一步了，即设计您预测将能够满足预期需求的建议的体系结构。

在此步骤末尾，您应该具有物理拓扑设计和逻辑拓扑布局，因此您应该能够继续执行任何必要的采购订单。

您设计的硬件规格和计算机数量紧密相关，若要处理特定负载，可从多个解决方案中选择要部署的解决方案。通常使用一小组强大的计算机（向上扩展）或较大一组较小计算机（向外扩展）；每个解决方案在容量、冗余、电源、成本、空间及其他注意事项方面都有其优缺点。

我们建议您执行此步骤时首先确定体系结构和拓扑。定义您计划如何设计不同的服务器场及每个服务器场中的不同服务，然后为设计中的每台服务器选取硬件规格。还可以通过确定希望部署的硬件规格（许多组织受某个公司标准约束）来执行此过程，然后定义体系结构和拓扑。

使用下表来记录您的设计参数。包括的数据是示例数据，不应用于调整您的服务器场大小。它旨在演示如何为您自己的数据使用此表。

角色	类型（标准或虚拟）	计算机数量	处理器	RAM	IOPS 需求	操作系统 + 日志的磁盘大小	数据驱动器
Web 服务器	虚拟	4	4 核	8	暂缺	400 GB	暂缺
内容数据库服务器	标准	1 个群集	4 个四核 2.33 (GHz)	48	2k	400 GB	20 个 300GB @ 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 个 150GB @ 15K RPM 磁盘
搜索属性存储数据库 + 管理数据库服务器	标准	1 个群集	4 个四核 2.33 (GHz)	48	2k（为写入调整）	100 GB	16 个 150GB @ 15K RPM 磁盘

确定起点体系结构

本节介绍如何选择起点体系结构。

当您部署 SharePoint Server 2010 时，可以从一系列拓扑中选择来实现您的解决方案；您可以将单个服务器部署到或将许多服务器向外扩展到具有群集或镜像数据库服务器以及各种服务的谨慎应用程序服务器的 SharePoint Server 场中。稍后，您将基于每个角色的要求并基于您的容量、可用性和冗余要求选择硬件配置。

首先查看不同的参考体系结构并确定您的服务器场结构，决定是应将解决方案拆分到多个服务器场中，还是在专用服务器场中联合一些服务（例如搜索）。有关详细信息，请参阅 SharePoint Server 2010 的容量管理和调整大小概述中的参考体系结构一节。

SharePoint Server 2010 技术案例研究

SharePoint Server 2010 的容量管理指南包括现有生产环境的许多技术案例研究，这些研究详细说明了基于 SharePoint Server 的现有生产环境。将随时间发布其他技术案例研究；这些可作为有关如何为特定目的设计基于 SharePoint Server 的环境的参考。

在设计 SharePoint Server 解决方案的体系结构时，尤其在您发现这些部署特定的关键区别的说明类似于要构建的解决方案的需求和目标时，可以使用这些案例研究作为参考。

这些文档介绍了每个记录的案例研究的以下信息：

规格，例如硬件、服务器场拓扑和配置；
工作量，包括用户群和使用特征；
数据集，包括内容大小、内容特征和内容分发
运行状况和性能，包括一组记录的描述服务器场的可靠性和性能特性的指标

有关详细信息，请从性能和容量技术案例研究（该链接可能指向英文页面）网页 (https://technet.microsoft.com/zh-cn/library/cc261716.aspx（该链接可能指向英文页面）) 中下载相关文档。

选择硬件

为您的服务器场中的计算机选择正确的规格是确保部署具有适当可靠性和性能的重要步骤，要记住的一个关键概念是您应规划高峰负载和高峰时段；换句话说，当您的服务器场在平均负载情况下运行时，应有足够的可用资源来处理预期的最大需求，同时仍能达到延迟和吞吐量目标。

服务器的核心容量和性能硬件功能表现为 4 大类：系统的处理能力、磁盘性能、网络容量和内存功能。

要考虑的另一件事是使用虚拟化计算机。可以使用虚拟机部署 SharePoint Server 场。虽然尚未发现这可添加任何性能好处，但它提供了可管理性好处。一般建议不要虚拟化基于 SQL Server 的计算机，但虚拟化 Web 服务器和应用程序服务器层可能有某些好处。有关详细信息，请参阅虚拟化规划 (https://technet.microsoft.com/zh-cn/library/ff607968.aspx)。

硬件选择指南

选择处理器

SharePoint Server 2010 只适用于 64 位处理器。一般情况下，增加处理器数量使您能够满足更高的需求。

在 SharePoint Server 2010 中，各个 Web 服务器将随着您添加更多核心而扩展（我们最多测试了 24 个核心）；服务器具有的核心越多，它可以承受的负载就越高，其他所有情况同样如此。在大型 SharePoint Server 部署中，建议分配多个 4 核 Web 服务器（可虚拟化），或更少更强大的（8/16/24 核）Web 服务器。

应用程序服务器的处理器容量要求会随服务器的角色和它运行的服务的不同而不同。一些 SharePoint Server 功能比其他功能需要更高的处理能力。例如，SharePoint Search Service 高度依赖应用程序服务器的处理能力。有关 SharePoint Server 功能和服务的资源要求的详细信息，请参阅 SharePoint Server 2010 的容量管理和调整大小概述一文的服务和功能一节。

SQL Server 的处理器容量要求还依赖基于 SQL Server 的计算机所承载的服务数据库。有关每个数据库的典型行为和要求的详细信息，请参阅存储和 SQL Server 容量规划和配置 (SharePoint Server 2010)。

选择内存

您的服务器将需要不同数量的内存，具体取决于服务器功能和角色。例如，如果运行搜索爬网组件的服务器具有大量内存，它们将可以更快地处理数据，这是因为将文档读取到内存中进行处理。利用 SharePoint Server 2010 的许多缓存功能的 Web 服务器可能也需要更多内存。

一般来说，Web 服务器内存要求高度依赖服务器场中启用的应用程序池数量和所服务的并发请求数。在大多数生产 SharePoint Server 部署中，建议为每个 Web 服务器至少分配 8 GB RAM，并建议为具有较高流量的服务器或将多个应用程序池设置为隔离的部署至少分配 16 GB RAM。

应用程序服务器的内存要求也不同；一些 SharePoint Server 功能对应用程序层的内存要求比其他功能高。在大多数生产 SharePoint Server 部署中，建议为每个应用程序服务器至少分配 8 GB RAM；当在同一服务器上启用了许多应用程序服务时，或当启用了高度依赖内存的服务（例如 Excel Calculation Service 和 SharePoint Server Search Service）时，16 GB、32 GB 和 64 GB 应用程序服务器很常见。

数据库服务器的内存要求高度依赖数据库大小。有关为基于 SQL Server 的计算机选择内存的详细信息，请参阅存储和 SQL Server 容量规划和配置 (SharePoint Server 2010)。

选择网络

如果客户端可以通过网络快速访问数据，除了能够给用户带来好处外，分布式服务器场也必定能够快速访问以实现服务器间通信。当您将服务分布在多个服务器上或将一些服务联合到其他服务器场时，更是如此。跨 Web 服务器层、应用程序服务器层和数据库服务器层的服务器场中有大量流量，并且网络在某些情况下（例如处理大型文件或非常高的负载）很容易成为瓶颈。

Web 服务器和应用程序服务器应至少配置两个网络接口卡 (NIC)：一个 NIC 处理最终用户流量，另一个处理服务器间通信。服务器之间的网络延迟会严重影响性能，因此将 Web 服务器和基于 SQL Server 的承载内容数据库的计算机之间的网络延迟保持在小于 1 毫秒很重要。基于 SQL Server 的承载每个服务应用程序数据库的计算机也应尽可能接近使用应用程序服务器。场服务器之间的网络应至少具有 1 Gbps 的带宽。

选择磁盘和存储

磁盘管理并不只是为数据提供足够空间的功能。您必须评估日常需求和增长，并确保存储体系结构不会降低系统性能。应始终确保每个磁盘上至少有高于最高数据要求估计值 30% 的额外容量，以便留出空间以供将来增长。此外，在大多数生产环境中，磁盘速度 (IOps) 对提供足够吞吐量以满足服务器的存储需求至关重要。您必须估计部署中主要数据库将需要的流量 (IOps)，并分配足够的磁盘来满足该流量。

有关如何为数据库服务器选择磁盘的详细信息，请参阅存储和 SQL Server 容量规划和配置 (SharePoint Server 2010)。

Web 和应用程序服务器也有存储要求。在大多数生产环境中，建议至少为操作系统和临时文件分配 200 GB 磁盘空间，并为日志至少分配 150 GB 磁盘空间。

步骤 3：试验、测试和优化

测试和优化阶段是有效容量管理的关键组成部分。应在将新体系结构部署到生产中之前对其进行测试，并应执行验收测试和以下监视最佳实践，以确保您设计的体系结构达到性能和容量目标。这允许您在潜在瓶颈在实时部署中影响用户之前识别并优化它们。如果要从 Office SharePoint Server 2007 环境升级并计划进行体系结构更改，或估计新 SharePoint Server 功能的用户负载，则测试对确保新的基于 SharePoint Server 的环境将满足性能和容量目标尤其重要。

在测试了您的环境后，可以分析测试结果来确定需要进行的更改，以实现在步骤 1：建模中设定的性能和容量目标。

以下是您应遵循的预生产的推荐子步骤：

创建模仿您在步骤 2：设计中设计的初始体系结构的测试环境。
使用您在步骤 1：建模中确定的数据集或部分数据集填充存储。
使用代表您在步骤 1：建模中确定的工作量的综合负载为系统施加压力。
运行测试，分析结果，并优化您的体系结构。
在数据中心中部署您优化的体系结构并通过一小组用户展开试验。
分析试验结果，识别潜在瓶颈并优化体系结构。如果需要，重新进行测试。
部署到生产环境。

测试

测试是确定您的系统设计支持您的工作量和使用特征的能力的关键因素。有关测试 SharePoint Server 2010 部署的详细信息，请参阅SharePoint Server 2010 的性能测试。

创建一个测试计划
创建测试环境
创建测试和工具

部署试验环境

在将 SharePoint Server 2010 部署到生产环境中之前，一定要首先部署试验环境并全面测试服务器场，以确保它可以满足预期高峰负载的容量和性能目标。我们建议首先使用综合负载对试验环境进行测试（尤其对于大型部署），然后通过一小组实时用户和实时内容施加压力。通过一小组实时用户分析试验环境的好处是有机会在完全投入生产之前验证您做出的一些有关使用特征和内容增长的假定。

优化

如果您无法通过扩展服务器场硬件或更改拓扑来满足容量和性能目标，则可能需要考虑修改解决方案。例如，如果初始要求是针对用于协作、搜索和社交的单个服务器场，则可能需要将一些服务（例如搜索）联合到专用服务服务器场，或将工作量拆分到更多服务器场中。一种备选方法是部署一个专用于社交的服务器场和另一个专用于工作组协作的服务器场。

步骤 4：部署

在执行了最后一轮测试并确认所选体系结构可以实现您在步骤 1：建模中设定的性能和容量目标后，可以将基于 SharePoint Server 2010 的环境部署到生产中。

相应的推出策略将因环境和情况而异。虽然 SharePoint Server 部署一般不在本文档的讨论范围内，但本文还是提供了一些可能来自容量规划练习的建议活动。下面是一些示例：

**部署新的 SharePoint Server 场：**容量规划练习应已指导并确认 SharePoint Server 2010 的设计和部署计划。在本例中，推出将是 SharePoint Server 2010 的第一次广泛部署。它将需要将容量规划练习过程中使用的服务器和服务移动到生产中或在生产中重新构建它们。这是最简单的方案，因为无需对现有服务器场进行任何升级或修改。
**将 Office SharePoint Server 2007 场升级到 SharePoint Server 2010：**容量规划练习应验证了可满足现有需求且通过向上扩展可满足 SharePoint Server 2010 场的增加的需求和使用的服务器场设计。容量规划练习的一部分应该包括测试迁移，以验证升级过程将需要多长时间、是否需要修改或替换任何自定义代码、是否有任何第三方工具需要更新等等。容量规划完成后，您应具有一个经验证的设计并了解升级它将需要多长时间，还具有如何通过升级过程（例如就地升级或将内容数据库迁移到新服务器场中）最好地工作的计划。如果执行的是就地升级，则在容量规划期间，您可能会发现将需要额外的或升级的硬件以及停机注意事项。规划练习结果的一部分应该是所需的硬件更改列表和首次将硬件更改部署到服务器场的详细计划。在容量规划期间验证的硬件平台准备好后，您可以继续执行升级到 SharePoint Server 2010 的过程。
**改进现有 SharePoint Server 2010 场的性能：**容量规划练习应已帮助您识别当前实现中的瓶颈、设计可减少或消除这些瓶颈的方法并验证可满足 SharePoint Server 服务的业务要求的改进实现。可通过不同的方法解决性能问题，例如在现有硬件上重新分配服务、升级现有硬件或添加其他硬件然后向其中添加其他服务之类的简单方法。应在容量规划练习期间测试和验证不同的方法，然后根据该测试的结果制定部署计划。

步骤 5：监视和维护

若要维护系统性能，您必须监视服务器来识别潜在瓶颈。您必须了解将告诉您服务器场的特定部分是否需要注意的关键指标，并知道如何解释这些指标，才能有效地监视。如果您发现服务器场的运行偏离了您定义的目标，则可以通过添加或移除硬件资源、修改拓扑或更改数据存储方式来调整服务器场。

有关您可以修改以便在早期阶段监视环境（这有助于您确定是否需要任何更改）的设置列表，请参阅监控和维护 SharePoint Server 2010。请记住，增加监视功能将影响使用率数据库将需要的磁盘空间量。在环境稳定且不再需要此详细监视后，可能需要将以下设置恢复为其默认值。

有关运行状况监视和使用 SharePoint Server 管理中心界面中内置的运行状况监视工具进行疑难解答的详细信息，请阅读以下文章：

运行状况监控 (SharePoint Server 2010)

解决问题和疑难解答 (https://technet.microsoft.com/zh-cn/library/ee748639.aspx)

通过