SharePoint Server 2013 的容量规划

 

**上一次修改主题:**2017-08-25

**摘要:**了解如何为 SharePoint Server 2013 规划和管理容量与性能。

本文介绍如何计划SharePoint Server 2013场的产能。有很好的欣赏和了解的容量规划和管理,可以将您的知识于为系统的规模。调整大小是术语用来描述的选择和相应的数据体系结构、 逻辑和物理拓扑和解决方案平台的硬件配置。还有一系列的容量管理和影响如何,您应该确定最合适的硬件和配置选项的使用注意事项。

在阅读本文之前,您应先阅读 SharePoint Server 2013 的容量管理和调整大小概述

重要

一些信息和本文中的值根据测试结果,并与SharePoint 2010 产品相关的其他信息,并可能无法代表SharePoint Server 2013的最终值。

在本文中,我们将介绍为您的环境执行有效的容量管理而应采取的步骤。每个步骤都需要特定的信息进行成功执行,具有您将在后续步骤中使用的可交付结果集。对于每个步骤,表中概述了这些要求和可交付物。

本文内容:

  • 步骤 1:模型

  • 步骤 2:设计

  • 步骤 3:试验、测试和优化

  • 步骤 4:部署

  • 步骤 5:监视和维护

步骤 1:模型

建模您的SharePoint Server 2013-基于的环境开始分析您现有的解决方案,并估计预期的要求和部署的目标计划设置。通过收集有关用户群、 数据要求、 延迟和吞吐量目标信息来启动和SharePoint Server 2013功能要部署文档。使用此节可理解应收集哪些数据、 如何收集,和如何可以在后续步骤中使用。

了解预期的工作负载和数据集

正确调整大小的SharePoint Server 2013实现的要求,研究并理解您的解决方案的特征预期的处理的需求。了解请求要求您能够描述这两种的工作负载特征,例如用户数和最常用的操作和数据集特征等内容的大小和内容分发。

本节可以帮助您了解您应收集的某些特定度量和参数以及收集时使用的机制。

工作负载

工作负载描述系统将需要维持的需求,即用户群和使用特征。下表提供了用于确定工作负载的某些关键度量。您可以使用此表在收集时记录这些度量。

工作负载特性

每日平均 RPS

 

平均峰值 RPS

 

每天的唯一用户总数

 

每日平均并发用户数

 

高峰时的峰值并发用户数

 

每日的请求总数

 

预期的工作负载分布

每天的请求数

Web 浏览器 - 搜索爬网

 

Web 浏览器 - 常规协作交互

 

Web 浏览器 - 社交交互

 

Web 浏览器 - 常规交互

 

Web 浏览器 - Office Web Apps

 

Office 客户端

 

OneNote 客户端

 

SharePoint Workspace

 

Outlook RSS 同步

 

Outlook Social Connector

 

其他交互(自定义应用程序/Web 服务)

 
  • 并发用户 – 将在服务器场上执行的并发操作数计为在指定时限内生成请求的不同用户数,是最常见的做法。关键指标是每日平均和峰值负载时的并发用户数。

  • 每秒请求数 (RPS) – RPS 是用于描述服务器场上需求的常用指标,表示为服务器场每秒处理的请求数,但请求类型或大小并无区别。每个组织的用户群生成系统负载的速率取决于组织的唯一使用特征。有关此服务器场的详细信息,请参阅 SharePoint Server 2013 的容量管理和调整大小概述中的术语部分。

  • 每日请求总数 – 每日请求总数是系统将需要处理的整体负载的良好指标。计量 24 小时内除身份验证握手请求外的所有请求 (HTTP 状态 401)是最常见的做法。

  • 每日用户总数 - 用户总数是系统将需要处理的整体负载的另一个关键指标。此度量是 24 小时内唯一用户的实际数量,而不是组织内的员工总数。

    备注

    每日用户总数可能表示服务器场上的负载潜在增长。例如,如果潜在用户数为 10 万名员工,每日 1.5 万名用户指示随着用户采用率增加负载可能随时间大大增加。

  • 工作负荷分配– 了解基于与场交互的客户端应用程序的请求分发可以帮助预测预期的趋势并迁移到SharePoint Server 2013后加载的更改。作为用户切换到较新的客户端版本,如办公室 2013,并开始使用新功能新负载模式,RPS 和请求的总数应增长。为每个客户端,我们可以描述使用它一天和服务器上的客户端或功能生成的请求总数数量的时间段内不同用户数。

    例如,下图显示提供典型社交解决方案的在线内部 Microsoft 环境的快照。在此示例中,您可以看到大部分负载由搜索爬网程序和典型最终用户 Web 浏览生成。您还可以看到这是 Outlook Social Connector 功能引入的重大负载(6.2% 的请求)。

    Typical daily load distribution of requests

估计您的生产工作负载

估计服务器场需要能够承受的所需吞吐量时,首先估计服务器场中将使用的事务组合。重点专注于分析系统将服务的最常用事务、了解事务的使用频率以及由多少用户使用。这将有助您稍后验证服务器场在预生产测试中能否承受此负载。

下图描述了系统上的工作负载和负载的关系:

Capacity - Workload Diagram

要估计您预期的工作负载,请收集以下信息:

  • 确定用户交互数,如典型网页浏览数、文件下载和上载次数、浏览器中的 Office Web Application 查看和编辑次数、共同创作交互数、SharePoint 工作区网站同步次数、Outlook Social 连接数、RSS 同步(在 Outlook 或其他查看器)、PowerPoint 广播、OneNote 共享笔记本、Excel Service 共享笔记本、Access Service 共享应用程序,等等。有关详细信息,请参阅 SharePoint Server 2013 的容量管理和调整大小概述一文中的功能和服务部分。重点专注于确定可能对您的部署独一无二的交互,并识别此类负载的预期影响,示例包括 InfoPath 表单的广泛使用、Excel Service 计算和类似的专用解决方案。

  • 确定搜索增量爬网、每日备份、配置文件同步计时器作业、Web 分析处理、日志记录计时器作业等系统操作。

  • 估计总数每天的用户应利用每个功能,派生的估计并发用户和高级别每秒请求数,有一些假设您将发出如存在并发和每个功能不同的并发用户的 RPS 的因子,应该使用您的估计值为本节前面的工作负荷表。在高峰时间,而不是平均吞吐量是重要焦点。规划活动高峰期,您将能够正确调整大小SharePoint Server 2013您的基于解决方案。

如果您具有现有的 Office SharePoint Server 2007 解决方案,您可以挖掘 IIS 日志文件或查找您拥有的其他 Web 监视工具,以更好地了解现有解决方案的某些预期行为,或者查看下文中的说明以获取详细信息。如果您未从现有解决方案迁移,您应使用粗略估计值填写该表。在后续步骤中,您需验证您的假设并调整系统。

分析 SharePoint Server 2013 IIS 日志

发现有关现有SharePoint Server 2013部署,例如多少用户是处于活动状态,如何很大程度的关键指标它们使用的系统,什么类型的请求来自中,并从客户端产生何种,有必要从 ULS 和 IIS 日志中提取数据。获取此数据的最简便方法之一就是要从 Microsoft 下载免费使用Log Parser,可用的功能强大的工具。Log Parser 可以读取和写入的文本和二进制格式,包括所有 IIS 格式数。

有关如何分析使用 Log Parser SharePoint Server 2013使用的详细信息,请参阅分析 Microsoft SharePoint 产品和技术使用 (https://www.microsoft.com/downloads/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e 和 displaylang = en 和 tm)。

您可以从 https://www.microsoft.com/downloads/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07&displaylang=en 下载日志分析器 2.2。

数据集

数据集描述存储在系统中的内容卷及其在数据存储中的分配方式。下表提供了用于确定数据集的部分关键指标。您可以在收集这些指标时使用该表进行记录。

对象

数据库大小(以 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解决方案应能实现"四个九"(99.99%) 的正常运行时间,子的第二个服务器响应。

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

  • 服务器可用性 – 通常按系统总运行时间百分比描述。您应该跟踪任何非预期的停机时间并将总体可用性与您设定的组织目标相比较。目标通常用数字九描述(即 99%、99.9%、99.99%)

  • 服务器响应能力— 场为请求提供服务所花的时间是一个很好的指标来跟踪服务器场的运行状况。此指标通常称为服务器端延迟,并且通常使用平均值或位数 (第 50%) 所提供的每日请求延迟。目标通常所述子秒。注意,如果您的组织有目标中,以便在不超过两秒,提供从SharePoint Server 2013的页面,然后服务器端目标需要子秒将保留页后,可以到达客户端在网络上的时间和时间要在浏览器中呈现。此外通常服务器响应时间较长是不正常的场中,这通常作为对吞吐量的影响作为指示并很少可以 RPS 跟上如果在服务器上请求最多花费超过一秒

  • 服务器高峰 – 另一个值得跟踪的服务器端延迟指标是所有请求中最慢的 5% 的行为。较慢的请求通常是在较高的负载下到达系统的请求,并且通常是受在用户与系统交互时以较低频率发生的活动影响的请求;运行正常的系统是最慢的情况也受控的系统。此指标的目标与服务器响应速度相似,但在服务器高峰方面要达到亚秒级响应速度,您需要使用大量闲置资源构建系统以处理负载高峰。

  • 系统资源利用率 – 用于跟踪系统运行状况的其他常用指标是指示服务器场拓扑中每个服务器的运行状况的系统计数器集合。跟踪时最常用的指标是 CPU 利用率和可用内存;但是,有几个附加计数器可以帮助您识别运行不正常的系统。有关更多详细信息,请参阅步骤 5:维护。

步骤 2:设计

现在您已经收集了关于您需要交付的解决方案的一些实际值或估计值,现在可以开始执行设计您预计可承载预期需求的建议体系结构的下一步。

此步骤结束时,您应该已经设计好物理拓扑并具有逻辑拓扑的布局,因此您应该能够继续完成任何必要的采购订单。

硬件规范和您布局的计算机数量与处理存在可选择部署的多个解决方案的特定负载密切相关。通常可以使用少数功能强大的计算机(向上扩展)或较多小型的计算机(向外扩展);在容量、冗余度、功率、成本、空间和其他考虑事项等方面,每种解决方案都有自己的优势和劣势。

我们建议您首先确定体系结构和拓扑。定义如何规划不同服务器场的布局以及每个服务器场中的不同服务,然后选择设计中每个服务器的硬件规范。您还可以通过确定应部署的硬件规范来执行此过程(很多组织均受特定公司标准限制),然后定义您的体系结构和拓扑。

使用下表记录您的设计参数。包含的数据是示例数据,且不应用于调整服务器场大小。此处将演示如何将此表用于您自己的数据。

角色 类型(标准或虚拟) 计算机数量 处理器数量 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

15K RPM 时为16 个 150GB 的磁盘

搜索属性存储数据库 + 管理数据库服务器

标准

1 个群集

4 个四核 2.33 (GHz)

48

2k(针对写入进行优化)

100 GB

15K RPM 时为16 个 150GB 的磁盘

确定起点体系结构

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

SharePoint Server 2013部署时,您可以从各种拓扑结构来实现解决方案;您可能使用聚簇索引或镜像数据库服务器和各种服务的谨慎应用服务器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 服务器和应用程序服务器虚拟化层。有关详细信息,请参阅虚拟化规划 (https://technet.microsoft.com/en-us/library/71c203cd-7534-47b0-9122-657d72ff0080 (Office.14).aspx)。

有关硬件要求的详细信息,请参阅 SharePoint Server 2016 的硬件和软件要求

硬件选择指南

选择处理器

SharePoint Server 2013是仅适用于 64 位处理器。一般情况下,更多的处理器,可以提供更高的要求。

在SharePoint Server 2013,将扩大单个 web 服务器,当您添加更多内核。更多内核服务器有更多的负载,它可以维持,所有其他正在相等。在SharePoint Server 2013的大型部署中,我们建议您分配多个 4 核 web 服务器 (它可以虚拟化),或更少更强 (8 / 16-/ 24 内核) web 服务器。

应用程序服务器处理器容量的要求不同,取决于服务器和正在运行的服务的角色。SharePoint Server 2013中的某些功能需要比其他人更高的处理能力。例如,SharePoint 搜索服务是高度依赖于应用程序服务器的处理能力。

SQL Server 的处理器容量要求也取决于基于 SQL Server 的计算机托管的服务数据库。

选择内存

您的服务器将需要不同数量的内存,具体取决于服务器功能和角色。例如,运行搜索爬网组件的服务器将处理数据更快如果他们有大量的内存,因为文档读入内存以进行处理。利用许多SharePoint Server 2013的缓存功能的 web 服务器可能需要更多的内存。

一般情况下,web 服务器的内存要求都高度依赖的数目在服务器场中启用的应用程序池和正在处理的并发请求数。在大多数生产SharePoint Server 2013部署中,我们建议分配至少 8 GB RAM 在每个 web 服务器上,建议为服务器具有更高的通信使用 16 gb 或部署多个应用程序池设置的隔离。

应用程序服务器的内存要求不同也;SharePoint Server 2013中的某些功能在应用程序层上比其他具有更大的内存要求。在大多数部署中生产SharePoint Server 2013建议您分配在每个应用程序服务器; 至少 8 GB 内存在同一个服务器上,或高度依赖于内存中,如 Excel 计算服务和SharePoint Server 2013搜索服务的服务都启用启用多个应用程序服务时,16GB、 32GB 和 64GB 的应用程序服务器是通用的。

数据库服务器的内存要求与数据库大小密切相关。有关为基于 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:模型中识别的工作负荷的综合负荷来为系统增加压力。

  • 运行测试、分析结果并优化您的体系结构。

  • 在数据中心中部署您的优化体系结构,并推出具有少数用户的试验。

  • 分析试验结果,识别潜在瓶颈并优化体系结构。根据需要重新测试。

  • 部署到生产环境。

测试

测试是 critial 因素建立您的系统设计,以支持您的工作负载和使用特征的能力。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的第一个广泛部署。它将需要移动或重新生成的服务器和服务的生产产能计划活动期间使用。这是最简单的方案,因为没有任何升级或修改需要到现有服务器场。

  • **升级到SharePoint Server 2013的Office SharePoint Server 2007场:**的容量规划过程应具有验证可以满足现有需求和规模上满足增加的需求和使用的SharePoint Server 2013场的场的设计。容量规划过程的一部分应包括测试迁移来验证需要多长时间升级过程,是否必须修改或替换,任意自定义代码是否任何第三方工具必须进行更新,等结束后的产能规划应具有经过验证的设计和了解升级将花费多长时间和如何计划最佳要升级的过程中--例如,通过就地升级时,或到新的服务器场的数据库迁移的内容。如果您做在容量规划您可能已经找到,将会需要附加或升级硬件,然后就地升级和停机时的注意事项。规划练习中输出的一部分应该是所需的硬件更改列表和详细的计划来部署硬件变为场第一次。进行容量规划过程已验证硬件平台后,您可以升级到SharePoint Server 2013的该进程的向前移动。

  • **提高现有SharePoint Server 2013场性能:**的容量规划过程应帮助您确定您当前的实现中的瓶颈、 计划方法可以减少或消除这些瓶颈,并验证了改进的实现能满足业务要求的SharePoint Server 2013服务。有不同方式的性能问题可能都已解决,从某些本息,重新分配跨现有的硬件,升级现有的硬件,或添加额外的硬件和将其他服务添加到它的服务对象。不同的方法应该是测试和验证的容量规划过程,期间和部署计划再具体的结果取决于设计的测试。

步骤 5:监视和维护

要维护系统性能,您必须监视服务器以发现潜在的瓶颈。为了有效地进行监视,您必须了解指示服务器场的某个特定部件是否需要关注的关键指标,以及如何解释这些指标。如果您发现您的服务器场未达到您定义的运行目标,您可以通过添加或删除硬件资源、更改拓扑或更改数据存储方式来调整服务器场。

请参阅监视和维护 SharePoint Server 2013 查看您在早期阶段可以更改以监视环境的设置列表,这将帮助您确定是否需要进行任何更改。请记住,提高您的监视功能会影响使用数据库将需要多少磁盘空间。环境稳定且不再需要此详细监视后,您可能需要将以下设置恢复为默认设置。

有关运行状况监视和故障排除使用内置的SharePoint Server 2013中央管理界面,阅读以下的运行状况监视工具的详细信息:

SharePoint Server 2016 中的监视和报告功能

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

See also

SharePoint Server 2013 的性能测试
监视和维护 SharePoint Server 2013
SharePoint Server 2016 的软件边界和限制
SharePoint Server 2016 中的监视和报告功能
性能和容量测试结果和建议 (SharePoint Server 2013)

SharePoint Server 2013 的容量管理和调整大小概述
Performance and capacity technical case studies (SharePoint Server 2010)