Configuration Manager网站大小和性能指南
适用于: Configuration Manager(current branch)
Configuration Manager在规模和性能方面处于行业领先地位。 其他文档介绍了在最大环境大小下运行站点时 支持的最大规模限制 和 硬件准则 。 本文针对各种大小的环境提供了补充性能指南。 本指南可帮助你更准确地估计部署Configuration Manager所需的硬件。
本文重点介绍Configuration Manager性能瓶颈的最大影响因素：磁盘输入/输出子系统或 IOPS。
- 显示侧重于 IOPS 的详细信息和测试结果
- 介绍如何使用自己的环境和硬件重现测试
- 建议各种大小环境的磁盘 IOPS 要求
性能测试方法
可以通过多种独特的方式部署Configuration Manager，但请务必在任何大小调整讨论中了解一些变量。 一个变量是 功能间隔，例如清单周期。 另一个变量是系统引用或部署的用户、软件部署或其他 对象 的数量。 性能测试将这些变量作为 负载的一部分应用。 负载以典型速率为在不同大小环境中使用生产部署的企业客户生成对象。
注意
客户使用情况数据允许使用大多数客户的最常见方案、配置和设置来测试当前分支版本。 本文中的建议基于这些平均值。 你的体验可能因环境大小和配置而异。 通常，Configuration Manager在对象和间隔方面需要常识。 仅仅因为可以收集系统上的每个文件，或者将一个周期的间隔设置为一分钟，并不意味着你应该。
以下部分重点介绍在测试和建模大型企业的处理需求时要使用的一些关键设置和配置。 这些准则有助于为建议的硬件大小设置基本系统性能预期。
功能间隔设置
大多数测试应对系统中的关键周期使用默认间隔。 例如，硬件清单测试每周进行一次，其文件大于默认 .mof 文件。 某些重复的功能间隔（尤其是硬件和软件清单周期）可能会对环境的性能特征产生重大影响。 为数据收集启用主动默认间隔的环境需要与活动增加成正比的超大硬件。 例如，假设有 25，000 个桌面客户端，并希望收集硬件清单的速度比默认间隔快两倍。 首先，调整站点的硬件大小，就像拥有 50，000 个客户端一样。
对象
测试应使用大型企业倾向于用于系统的对象的 平均值上限 。 典型值为数千个集合和应用程序，这些集合和应用程序部署到数十万个用户或系统。 测试应以这些限制同时对系统 中的所有 对象运行。 许多客户使用多个功能，但通常不会在这些上限下使用产品的所有功能。 使用所有产品功能进行测试有助于确保尽可能最佳的系统范围性能，并允许为某些客户可能使用高于平均水平的功能提供缓冲区。
负荷
测试还应在大于标准 平均日 负载的情况下运行，方法是对系统执行产生峰值使用需求的模拟。 一个示例是模拟 Patch Tuesday 推出，以确保系统可以在这些高峰活动期间及时返回更新符合性数据。 另一个示例是在广泛爆发恶意软件期间模拟站点活动，以确保可以及时通知和响应。 尽管任何给定日期可能未使用建议大小的已部署计算机，但更极端的情况需要一些处理缓冲区。
配置
在一系列物理、Hyper-V 和 Azure 硬件上运行测试，混合了受支持的操作系统和SQL Server版本。 始终验证受支持配置的最坏情况。 通常，Hyper-V 和 Azure 在配置类似时，会返回与等效物理硬件相当的性能结果。 当前服务器操作系统的性能往往等于或优于早期 OS 版本。 虽然所有受支持的平台都满足最低要求，但通常最新版本的支持产品（如 Windows 和 SQL Server）会产生更好的性能。
最大的变化来自正在使用的 SQL Server 版本。 有关SQL Server版本的详细信息，请参阅应运行哪个版本的SQL Server？。
关键性能决定因素
可以通过不同的设置、不同的方式和不同的网站大小来测试和衡量Configuration Manager性能。 以下设置和对象可能会显著影响性能。 在环境中测试和建模性能时，请务必考虑它们。
警告
虽然Configuration Manager的几个方面有防止过度使用的官方最大值或用户界面限制，但超出准则可能会对网站性能产生重大不利影响。 超过建议的级别或忽略大小调整指南通常需要更大的硬件，并且可能会使你的环境无法维护，直到你减少各种对象的频率或数量。
硬件清单
若要测试基线性能，请将硬件清单收集设置为每周一次，默认的 .mof 文件大小加上大约 20% 的其他属性。 不要启用所有属性，只收集实际需要的属性。 收集属性（例如可用虚拟内存）时，请特别注意这些属性，这些属性将始终随每个库存周期而变化。 收集这些属性可能会导致每个客户端的每个库存周期出现过多改动。
软件清单
若要测试基线性能，请将软件清单收集设置为每周一次， 仅包含产品 详细信息。 收集许多文件可能会给库存子系统带来很大的压力。 避免指定筛选器，这些筛选器最终可能会跨多个客户端收集数千个文件，例如 *.exe 或 *.dll。
集合
基线性能测试可以包括数千个集合，这些集合具有不同类型的范围、大小、复杂性和更新设置。 网站性能不是网站上集合数量的直接函数。 性能也是集合查询复杂性、完整更新和增量更新以及更改频率、集合之间的依赖关系以及集合中客户端数的交叉积。
如果可能，请尽量减少具有昂贵或复杂动态规则查询的集合。 对于需要这些类型的规则的集合，请设置适当的更新间隔和更新时间，以尽量减少集合重新评估对系统的影响。 例如，在午夜而不是上午 8：00 更新。
对集合启用增量更新可确保快速及时更新集合成员身份。 但是，即使增量更新是有效的，它们仍然给系统增加负载。 平衡预期的更改频率和对成员身份的准实时更新的需求。 例如，假设你预期集合成员出现大量变动，但不需要近乎实时的成员身份更新。 与启用增量更新相比，它使用计划的完整更新在某个时间间隔更新集合的效率更高，并且产生的负载更少。
启用增量更新时，请减少同一集合上计划的完整更新。 它们只是评估的备份方法，因为增量更新应使集合成员身份几乎实时更新。 集合的最佳做法 建议增量更新的最大集合总数，但正如本文所指出的，你的体验可能因许多因素而异。
仅具有直接成员身份规则且具有不执行增量更新的限制集合的集合不需要计划的完整更新。 禁用这些类型的集合的更新计划，以防止系统上出现不必要的负载。 如果限制集合使用增量更新，则仅具有直接成员身份规则的集合在长达 24 小时内或计划刷新之前可能不会反映成员身份更新。
虽然不是最佳做法，但某些组织会创建数百甚至数千个集合作为各种业务流程的一部分。 如果使用自动化来创建集合，请务必正确启用任何所需的增量更新。 最小化并分散任何完整更新计划，以避免在单个时间段内收集评估的热点。 建立定期整理过程以删除未使用的集合，尤其是在一段时间后自动创建不再需要的集合时。
请记住，Configuration Manager在将任务（例如部署到这些对象）为目标时，会为集合中的所有对象创建策略。 通过计划的刷新或增量更新进行成员身份更改，可以为整个系统创造更多的工作。 最新的 Current Branch 版本针对“所有系统”和“所有用户”集合具有特殊的策略优化。 面向整个企业时，请使用内置集合，而不是这些内置集合的克隆。
若要更深入地调查集合性能，请在控制台中查看集合评估。 有关详细信息，请参阅 如何查看集合评估。
发现方法
对于基线性能测试，请每周运行一次基于服务器的发现方法，根据需要启用增量发现，使数据在一周内保持最新。 测试应发现与模拟企业大小成正比的对象数量。 检测信号发现的性能基线测试也应每周运行一次。
发现数据是全局数据。 一个常见的性能相关问题是在层次结构中错误配置基于服务器的发现方法，导致从多个主站点重复发现相同资源。 仔细配置发现方法以优化与目标服务（例如 Active Directory 域控制器）的通信，同时避免在多个主站点上重复相同的发现范围。
常规大小调整指南
根据前面的 性能测试方法，下表提供了特定数量的托管客户端的一般 最低 硬件要求准则。 这些值应允许具有指定数目的客户端的大多数客户以足够快的速度处理对象，以管理指定的站点。 计算能力的价格每年都在下降，对于新式服务器硬件配置，以下一些要求很小。 超过以下准则的硬件可按比例提高需要更多处理能力或具有特殊产品使用模式的站点的性能。
| 桌面客户端 | 站点类型/角色 | 核心 说明 1 | 内存 (GB) | SQL Server内存分配说明 2 | IOPS：收件箱 说明 3 | IOPS：SQL Server注释 3 | 需要 (GB) 注释 4 的存储空间 |
|---|---|---|---|---|---|---|---|
| 25k | 在同一服务器上具有数据库站点角色的主数据库或 CAS | 6 | 24 | 65% | 600 | 1700 | 350 |
| 25k | 主要或 CAS | 4 | 8 | 600 | 100 | ||
| 远程SQL Server | 4 | 16 | 70% | 1700 | 250 | ||
| 50k | 在同一服务器上具有数据库站点角色的主数据库或 CAS | 8 | 32 | 70% | 1200 | 2800 | 600 |
| 50k | 主要或 CAS | 4 | 8 | 1200 | 200 | ||
| 远程SQL Server | 8 | 24 | 70% | 2800 | 400 | ||
| 100k | 在同一服务器上具有数据库站点角色的主数据库或 CAS | 12 | 64 | 70% | 1200 | 5000 | 1100 |
| 100k | 主要或 CAS | 6 | 12 | 1200 | 300 | ||
| 远程SQL Server | 12 | 48 | 80% | 5000 | 800 | ||
| 150k | 在同一服务器上具有数据库站点角色的主数据库或 CAS | 16 | 96 | 70% | 1800 | 7400 | 1600 |
| 150k | 主要或 CAS | 8 | 16 | 1800 | 400 | ||
| 远程SQL Server | 16 | 72 | 90% | 7400 | 1200 | ||
| 700k | 在同一服务器上具有数据库站点角色的 CAS | 20+ | 128+ | 80% | 1800+ | 9000+ | 5000+ |
| 700k | Cas | 8+ | 16+ | 1800+ | 500+ | ||
| 远程SQL Server | 16+ | 96+ | 90% | 9000+ | 4500+ | ||
| 5k | 辅助站点 | 4 | 8 | 500 | - | 200 | |
| 15k | 辅助站点 | 8 | 16 | 500 | - | 300 |
有关一般大小调整指南的说明
注释 1：核心
Configuration Manager同时运行多个进程，因此需要为各种站点大小提供一定的最小 CPU 核心数。 虽然内核每年的速度越来越快，但请务必确保一定数量的内核并行工作。 通常，2015 年之后生成的任何服务器级 CPU 都满足表中指定的核心的基本性能需求。 Configuration Manager利用建议以外的其他核心。 获得建议的最小核心数后，请确定 CPU 资源投资的优先级，以提高现有核心的速度。 不要添加更多较慢的核心。 例如，Configuration Manager具有 16 个快速核心的密钥处理任务的性能比具有 24 个较慢的核心具有更好的性能。 此性能假定有足够的其他系统资源，例如磁盘 IOPS。
核心和内存之间的关系也很重要。 通常，每个核心的 RAM 小于 3-4 GB 会降低 SQL Server 上的总处理能力。 当SQL Server与站点服务器组件并置时，每个核心需要更多的 RAM。
注意
所有测试都设置计算机电源计划，以允许最大的 CPU 功耗和性能。
注释 2：SQL Server内存分配
使用此值可配置最大服务器内存 (（以 MB 为单位），) SQL Server的属性中。 它是服务器上可用内存总量的百分比。
不要将最小值和最大值配置为相同。 本指南专门针对应允许SQL Server分配的最大内存。
注意 3：IOPS：收件箱和 IOPS：SQL
这些值是指Configuration Manager和SQL Server逻辑驱动器的 IOPS 需求。 “IOPS： 收件箱”列显示具有Configuration Manager收件箱目录的逻辑驱动器的 IOPS 要求。 “IOPS： SQL”列显示各种SQL Server文件使用的逻辑驱动器 () 的总 IOPS 需求。 这些列不同，因为两个驱动器的格式应不同。 有关建议SQL Server磁盘配置和文件最佳做法的详细信息和示例，包括有关跨多个卷拆分文件的详细信息，请参阅站点大小和性能常见问题解答。
这两个 IOPS 列都使用行业标准工具 Diskspd 中的数据。 有关复制这些度量的说明，请参阅 如何测量磁盘性能 。 通常，满足基本的 CPU 和内存要求后，存储子系统对站点性能的影响最大，此处的改进将带来最大的投资回报。
注释 4：需要存储空间
这些实际值可能不同于其他记录的建议。 我们仅将这些数字作为一般准则提供：各个要求可能差别很大。 在安装站点之前，请仔细规划磁盘空间需求。 假设此存储的一些量在大部分时间都保持为可用磁盘空间。 可以在恢复方案中使用此缓冲区空间，或者用于需要可用磁盘空间进行安装包扩展的升级方案。 您的网站可能需要更多存储空间来收集大量的数据、更长的数据保留期和大量的软件分发内容。 还可以将这些项存储在单独的较低吞吐量卷上。
如何测量磁盘性能
可以使用行业标准工具 Diskpd 为各种大小的Configuration Manager环境所需的 IOPS 提供标准化建议。 以下测试步骤和命令行虽然并不详尽，但提供了一种简单且可重现的方式来估计服务器的磁盘子系统吞吐量。 可以在 常规大小调整指南 表中将结果与建议的最小 IOPS 进行比较。
有关实验室环境中不同类型的硬件配置的测试结果，请参阅 示例磁盘配置。 从头开始为新环境设计存储子系统时，可以使用数据作为大致起点。
如何测试磁盘 IOPS
下载 Diskspd 实用工具。
请确保至少有 100 GB 的可用磁盘空间。 禁用任何可能会干扰或导致磁盘上额外负载的应用，例如目录、SQL 或 SMSExec 的活动防病毒扫描。
从提升的命令提示符运行 Diskspd 。
针对要测试的卷按顺序运行该工具两次。 第一个测试大小为 64k，随机写入操作一分钟。 此测试验证控制器缓存加载和磁盘空间分配，以防卷动态扩展。 放弃第一次测试的结果。 第二个测试应在第一个测试之后 立即 执行，并在五分钟内执行相同的负载。
例如，使用以下特定命令行测试
G:卷。DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d60 -h -L G:\\test\testfile.dat del G:\\test\testfile.dat DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d300 -h -L G:\\test\testfile.dat查看第二个测试的输出，查找 每 s 列 I/O 的总 IOPS。 在以下示例中，总 IOPS 为 3929.18。
Total IO | thread | bytes | I/Os | MB/s | I/O per s | AvgLat | LatStdDev | |--------|-------------|---------|--------|-----------|--------|-----------| | 1 | 9651814400 | 147275 | 30.68 | 490.92 | 16.294 | 10.210 | | 2 | 9676652544 | 147654 | 30.76 | 492.18 | 16.252 | 9.998 | | 3 | 9638248448 | 147068 | 30.64 | 490.23 | 16.317 | 10.295 | | 4 | 9686089728 | 147798 | 30.79 | 492.66 | 16.236 | 10.072 | | 5 | 9590931456 | 146346 | 30.49 | 487.82 | 16.398 | 10.384 | | 6 | 9677242368 | 147663 | 30.76 | 492.21 | 16.251 | 10.067 | | 7 | 9637330944 | 147054 | 30.64 | 490.18 | 16.319 | 10.249 | | 8 | 9692577792 | 147897 | 30.81 | 492.99 | 16.225 | 10.125 | | Total: | 77250887680 | 1178755 | 245.57 | 3929.18 | 16.286 | 10.176 |
磁盘配置示例
下表显示了如何使用各种测试实验室配置 测量磁盘性能 中的测试步骤的结果。 从头开始为新环境设计存储子系统时，请从 粗略 的起点使用此数据。
物理计算机和 Hyper-V
硬件不断改进。 预期新一代硬件和不同的硬件组合（如 SSD 和 SAN）将超过下面所述的性能。 这些结果是设计服务器或与硬件供应商讨论时要考虑的基本起点。
下表显示了各种磁盘子系统（包括基于 ssd 的硬盘驱动器）在各种测试实验室配置中的测试结果。 所有配置都格式化具有 64k 群集的磁盘，并将其附加到企业级磁盘控制器。 除了 RAID 阵列磁盘计数外，每个磁盘都有至少一个备用磁盘。
| 磁盘类型 | 磁盘计数，不包括 +1 个备用磁盘 | RAID | 测量的 IOPS |
|---|---|---|---|
| 15k SAS | 2 | 1 | 620 |
| 15k SAS | 4 | 10 | 1206 |
| 15k SAS | 6 | 10 | 1751 |
| 15k SAS | 8 | 10 | 2322 |
| 15k SAS | 10 | 10 | 2882 |
| 15k SAS | 12 | 10 | 3476 |
| 15k SAS | 16 | 10 | 4236 |
| 15k SAS | 20 | 10 | 5148 |
| 15k SAS | 30 | 10 | 7398 |
| 15k SAS | 40 | 10 | 9913 |
| SSD SATA | 2 | 1 | 3300 |
| SSD SATA | 4 | 10 | 5542 |
| SSD SATA | 6 | 10 | 7201 |
| SSD SAS | 2 | 1 | 7539 |
| SSD SAS | 4 | 10 | 14346 |
| SSD SAS | 6 | 10 | 15607 |
下表列出了此示例中使用的特定设备。 对于任何特定硬件型号或制造商，不建议使用此信息。
| 磁盘类型 | 模型 | RAID 控制器 | 缓存内存和配置 |
|---|---|---|---|
| 15k RPM SAS HD | HP EH0300JDYTH | 智能阵列 P822 | 2 GB，20% 读取/80% 写入 |
| SSD SATA | ATA MK0200GCTYV | 智能阵列 P420i | 1 GB，20% 读取/80% 写入 |
| SSD SAS | HP MO0800 JEFPB | 智能阵列 P420i | 1 GB，20% 读取/80% 写入 |
Azure 计算机和磁盘性能
Azure 磁盘性能取决于多个因素，例如 Azure VM 的大小，以及它使用的磁盘的数量和类型。 Azure 还会不断添加新的计算机类型和磁盘速度，这与下图不同。 有关在 Azure 上运行Configuration Manager的详细信息，以及有关了解 Azure 上的磁盘 I/O 的其他信息，请参阅有关 Azure 常见问题Configuration Manager。
所有磁盘都格式化为 NTFS 64k 群集大小，具有多个磁盘的行通过 Windows 磁盘管理实用工具配置为条带卷。
| Azure VM | Azure 磁盘 | 磁盘计数 | 可用空间 | 测量的 IOPS | 限制因素 |
|---|---|---|---|---|---|
| DS2/DS11 | P20 | 1 | 512 GB | 965 | Azure VM 大小 |
| DS2/DS11 | P20 | 2 | 1024 GB | 996 | Azure VM 大小 |
| DS2/DS11 | P30 | 1 | 1024 GB | 996 | Azure VM 大小 |
| DS2/DS11 | P30 | 2 | 2048 GB | 996 | Azure VM 大小 |
| DS3/DS12/F4S | P20 | 1 | 512 GB | 1994 | Azure VM 大小 |
| DS3/DS12/F4S | P20 | 2 | 1024 GB | 1992 | Azure VM 大小 |
| DS3/DS12/F4S | P30 | 1 | 1024 GB | 1993 | Azure VM 大小 |
| DS3/DS12/F4S | P30 | 2 | 2048 GB | 1992 | Azure VM 大小 |
| DS4/DS13/F8S | P20 | 1 | 512 GB | 2334 | P20 磁盘 |
| DS4/DS13/F8S | P20 | 2 | 1024 GB | 3984 | Azure VM 大小 |
| DS4/DS13/F8S | P20 | 3 | 1536 GB | 3984 | Azure VM 大小 |
| DS4/DS13/F8S | P30 | 1 | 1024 GB | 3112 | P30 磁盘 |
| DS4/DS13/F8S | P30 | 2 | 2048 GB | 3984 | Azure VM 大小 |
| DS4/DS13/F8S | P30 | 3 | 3072 GB | 3996 | Azure VM 大小 |
| DS5/DS14/F16S | P20 | 1 | 512 GB | 2335 | P20 磁盘 |
| DS5/DS14/F16S | P20 | 2 | 1024 GB | 4639 | P20 磁盘 |
| DS5/DS14/F16S | P20 | 3 | 1536 GB | 6913 | P20 磁盘 |
| DS5/DS14/F16S | P20 | 4 | 2048 GB | 7966 | Azure VM 大小 |
| DS5/DS14/F16S | P30 | 1 | 1024 GB | 3112 | P30 磁盘 |
| DS5/DS14/F16S | P30 | 2 | 2048 GB | 6182 | P30 磁盘 |
| DS5/DS14/F16S | P30 | 3 | 3072 GB | 7963 | Azure VM 大小 |
| DS5/DS14/F16S | P30 | 4 | 4096 GB | 7968 | Azure VM 大小 |
| DS15 | P30 | 1 | 1024 GB | 3113 | P30 磁盘 |
| DS15 | P30 | 2 | 2048 GB | 6184 | P30 磁盘 |
| DS15 | P30 | 3 | 3072 GB | 9225 | P30 磁盘 |
| DS15 | P30 | 4 | 4096 GB | 10200 | Azure VM 大小 |
有关当前可用磁盘的详细信息，请参阅 为 Azure IaaS VM 选择磁盘类型。