从 Windows Server 2008 开始，Windows Server 提供三种电源计划： 平衡、 高性能和 节能程序。 Balanced power plan 是默认选项，旨在为一组典型的服务器工作负载提供最佳能效。 本主题介绍用于确定过去几个 Windows 版本的 Balanced 方案的默认设置的工作负载。
如果您运行的服务器系统具有与这些工作负载截然不同的工作负载特征或性能和电源要求，则可能需要考虑调整默认电源设置（即创建自定义电源计划）。 有用的优化信息来源之一是 服务器硬件电源注意事项。 或者，您可以 决定高性能电源 计划是您环境的正确选择，并认识到您可能会遭受重大的能源损失，以换取一定程度的响应能力提高。
重要
您应该利用 Windows Server 附带的电源策略，除非您有创建自定义策略的特定需求，并且非常了解结果将根据工作负载的特征而变化。
Windows 处理器电源调整方法
经过测试的工作负载
选择工作负载以涵盖一组尽力而为的“典型”Windows Server 工作负载。 显然，这组并不打算代表整个真实世界的服务器环境。
每个电源策略中的优化是由以下五个工作负载驱动的数据，这些工作负载从 Windows Server 2008 开始
IIS Web 服务器工作负载
名为 Web Fundamentals 的 Microsoft 内部基准测试用于优化运行 IIS Web Server 的平台的能效。 该设置包含一个 Web 服务器和多个模拟 Web 访问流量的客户端。 动态、静态热 （内存中） 和静态冷 （需要磁盘访问） 网页的分布基于对生产服务器的统计研究。 为了将服务器的 CPU 内核推向完全利用率（测试范围的一端），设置需要足够快的网络和磁盘资源。
SQL Server 数据库工作负载
TPC-E 基准测试是数据库性能分析的常用基准测试。 它用于为 PPM 优化优化生成 OLTP 工作负载。 此工作负载具有大量的磁盘 I/O，因此对存储系统和内存大小具有很高的性能要求。
文件服务器工作负载
使用 Microsoft 开发的名为 FSCT 的基准测试来生成 SMB 文件服务器工作负载。 它在服务器上创建一个大型文件集，并使用许多客户端系统（实际或虚拟化）来生成文件打开、关闭、读取和写入作。 作组合基于对生产服务器的统计研究。 它对 CPU、磁盘和网络资源造成压力。
SPECpower – JAVA 工作负载
SPECpower_ssj2008 是第一个联合评估功耗和性能特征的行业标准 SPEC 基准测试。 它是一个服务器端 Java 工作负载，具有不同的 CPU 负载级别。 它不需要很多磁盘或网络资源，但它对内存带宽有一定的要求。 几乎所有的 CPU 活动都是在用户模式下执行的;除了电源管理决策之外，内核模式活动对基准测试的功耗和性能特征没有太大影响。
Application Server 工作负载
SAP-SD 基准测试用于生成应用程序服务器工作负载。 使用两层设置，数据库和应用程序服务器位于同一服务器主机上。 此工作负载还使用响应时间作为性能指标，这与其他经过测试的工作负载不同。 因此，它用于验证 PPM 参数对响应能力的影响。 但是，它并不代表所有对延迟敏感的生产工作负载。
除 SPECpower 之外的所有基准测试最初都是为性能分析而设计的，因此被创建为在峰值负载水平下运行。 但是，中到轻负载级别对于实际生产服务器更常见，并且对于 Balanced plan 优化更有趣。 我们特意使用各种限制方法（例如，通过减少活跃用户/客户端的数量），在 100% 到 10% 的不同负载级别（分 10% 个步骤）下运行基准测试。
上述工作负载使用吞吐量作为优化的性能指标。 在稳定状态下，吞吐量不会随着利用率的变化而变化，直到系统过载（~100% 利用率）。 因此，Balanced Power 计划非常有利于功率，同时将处理器频率降至最低，并最大限度地提高利用率。 从 Windows Server 2016 开始，对快速响应时间的要求急剧增加。 尽管 Microsoft 建议用户在需要快速响应时间时切换到高性能电源计划，但一些用户不想在轻负载到中等负载级别期间失去电源优势。 因此，Windows Server PPM 优化还包括用于优化的响应时间敏感工作负载。
极客工作台
GeekBench 是一种跨平台的处理器基准测试，用于区分单核和多核性能的分数。 它模拟一组工作负载，包括整数工作负载（加密、压缩、图像处理等）、浮点工作负载（建模、分形、图像锐化、图像模糊等）和内存工作负载（流式处理）。
响应时间 是其分数计算中的一个主要指标。 在我们测试的系统中，与 高性能 电源计划相比，Windows Server 2008 默认平衡电源计划在单核测试中具有 ~18% 回归，在多核测试中具有 ~40% 回归。 Windows Server 2016 删除了这些回归。
DiskSpd 磁盘
Diskspd 是由 Microsoft 开发的用于存储基准测试的命令行工具。 它广泛用于对存储系统生成各种请求，以进行存储性能分析。
我们搭建了一个 [Failover Cluster]，并使用 Diskspd 生成随机和顺序的 IO，并对不同 IO 大小的本地和远程存储系统进行读写 IO。 我们的测试表明，在不同电源计划下，IO 响应时间对处理器频率很敏感。 在某些工作负载下，默认的 Windows Server 2008 平衡电源计划的响应时间可能会使 高性能电源计划的 响应时间增加一倍。 Windows Server 2016 平衡电源计划删除了大部分回归。
重要
从运行 Windows Server 2016 的 Intel [Broadwell] 处理器开始，大多数处理器电源管理决策都是在处理器而不是作系统级别做出的，以便更快地适应工作负载变化。 OS 使用的传统 PPM 参数对实际频率决策的影响最小，除了告诉处理器它应该偏向功率或性能，或者限制最小和最大频率。 因此，这里提到的 PPM 调整结果仅在 Broadwell 之前的系统上观察到。
硬件配置
对于每个版本的 Windows，在电源计划分析和优化过程中使用最新的生产服务器。 在某些情况下，测试是在发布计划与下一个 Windows 版本的发布计划相匹配的预生产系统上执行的。
鉴于大多数服务器都带有 1 到 4 个处理器插槽，并且由于纵向扩展服务器不太可能将能源效率作为主要考虑因素，因此电源计划优化测试主要在 2 插槽和 4 插槽系统上运行。 选择每个测试的 RAM、磁盘和网络资源量，以允许每个系统一直运行到其最大容量，同时考虑实际服务器环境通常存在的成本限制，例如保持配置合理。
重要
即使系统可以在其峰值负载下运行，我们通常会针对较低的负载级别进行优化，因为除非能源效率是高优先级，否则建议始终以峰值负载级别运行的服务器使用 高性能 电源计划。
指标
所有经过测试的基准测试都使用吞吐量作为性能指标。 响应时间被视为这些工作负载的 SLA 要求（SAP 除外，它是主要指标）。 例如，如果平均响应时间或最大响应时间小于特定值，则认为基准测试运行是“有效的”。
因此，PPM 优化分析也使用吞吐量作为其性能指标。 在最高负载级别（100% CPU 利用率）下，我们的目标是由于电源管理优化，吞吐量的降低不应超过几个百分点。 但主要考虑因素是在中低负载水平下最大限度地提高功率效率（定义如下）。
以较低频率运行 CPU 内核可降低能耗。 但是，较低的频率通常会降低吞吐量并增加响应时间。 对于 Balanced 电源计划，有意在响应能力和电源效率之间进行权衡。 SAP 工作负载测试以及其他工作负载的响应时间 SLA 确保这些特定工作负载的响应时间增加不超过特定阈值（例如 5%）。
注释
如果工作负载对响应时间非常敏感，则系统应切换到 High Performance 电源计划或更改 Balanced 电源计划，以便在运行时非常积极地增加频率。
Windows Server 平衡电源计划默认参数
从运行 Windows Server 2016 的 Intel Broadwell 处理器开始，Windows Server 电源管理使用 Intel 的硬件控制 P 状态 （HWP） 作为 Intel 系统上的默认值。 HWP 是协作硬件和软件性能控制的新功能。 启用 HWP 后，CPU 会监视活动和可伸缩性，并在硬件时间范围内选择频率。 不再需要 OS 来监视活动，并定期选择频率。 切换到 HWP 有几个好处，例如响应速度快、更好地了解 TDP 下处理器和其他组件的硬件电源效率。
对于 HWP 系统，Windows 仍然可以选择设置最小和最大处理器状态以提供约束。 它还可以使用 Energy performance preference （EPP） 参数来设置功率和性能之间的平衡。 较低的值有利于性能，而较高的值有利于权力。 默认值 50，用于平衡电源和性能。
| 参数 | Windows Server 2012R2 及更早版本 | Windows Server 2016 及更高版本 |
|---|---|---|
| 已启用 HWP | 无 | 英特尔 Broadwell+ |
| 能源绩效首选项 | 无 | 50 |
对于 Intel Broadwell 之前的系统或任何不支持 HWP 的系统（例如 AMD 服务器），Windows 仍处于完全控制状态，并根据 PPM 参数确定处理器频率。 Windows Server 2012R2 中的默认 PPM 参数过于偏爱功率，这可能会显著影响工作负载性能，尤其是对于突发工作负载。 在 Windows Server 2016 RS2 中更改了四个 PPM 参数，以使频率在中等负载水平附近更快地增加。
| 参数 | Windows Server 2016 （RS1） 及更早版本 | Windows Server 2016 （RS2） 及更高版本 |
|---|---|---|
| 处理器性能提升阈值 | 90 | 六十 |
| 处理器性能下降阈值 | 80 | 40 |
| 处理器性能增加时间 | 3 | 1 |
| 处理器性能提升策略 | 单身 | 理想 |
基于 CPU 利用率的电源管理算法可能会损害 IO 或网络密集型工作负载的延迟。 逻辑处理器在等待 IO 完成或网络数据包时可能处于空闲状态，这使得整体 CPU 利用率较低。 为了解决此问题，Windows Server 2019 会自动检测 IO 响应周期，并将频率下限提高到更高的级别。 无论系统是否使用 HWP，都可以通过以下参数调整行为。
| 参数 | Windows Server 2019 之前 | Windows Server 2019 及更高版本 |
|---|---|---|
| 处理器响应能力覆盖启用阈值 | 无 | 10 |
| 处理器响应能力覆盖禁用阈值 | 无 | 5 |
| 处理器响应能力覆盖启用时间 | 无 | 1 |
| 处理器响应能力覆盖禁用时间 | 无 | 3 |
| 处理器响应能力覆盖能源性能首选项上限 | 无 | 100 |
| 处理器响应能力高于性能下限 | 无 | 100 |
自定义优化建议
如果您的主要工作负载特征与用于默认 平衡 电源计划 PPM 优化的五个工作负载明显不同，您可以通过更改一个或多个 PPM 参数来进行试验，以找到最适合您的环境的参数。
由于参数的数量和复杂性，这可能是一项具有挑战性的任务，但如果您正在为您的特定环境寻找能耗和工作负载效率之间的最佳权衡，那么可能值得付出努力。
完整的可调 PPM 参数集可在 处理器电源管理调整 中找到。 一些最简单的功率参数可能是：
对于启用 HWP 的系统：
- 能源性能首选项 – 较大的值更有利于功率而不是性能
对于非 HWP 系统：
Processor Performance Increase Threshold 和 Processor Performance Increase Time – 值越大，对增加的活动的性能响应就越慢
Processor Performance Decrease Threshold – 较大的值会加快对空闲时段的电源响应
Processor Performance Decrease Time – 值越大，空闲期间性能越逐渐降低
处理器性能提升策略 – “Single” 策略减慢对增加和持续活动的性能响应;“Rocket” 策略对增加的活跃度做出快速反应
处理器性能降低策略 – “Single” 策略在较长的空闲时间内更逐渐地降低性能;“Rocket” 策略在进入空闲期时非常迅速地下降功率
重要
在开始任何实验之前，您应该首先了解您的工作负载，这将帮助您做出正确的 PPM 参数选择并减少优化工作。
了解高级性能和功耗要求
如果您的工作负载是“实时”的（例如，容易受到故障或其他可见的最终用户影响）或具有非常严格的响应能力要求（例如，股票经纪），并且如果能耗不是您环境的主要标准，则您可能应该切换到 高性能 电源计划。 否则，您应该了解工作负载的响应时间要求，然后调整 PPM 参数以获得仍满足这些要求的最佳能效。
了解底层工作负载特征
您应该了解您的工作负载并设计用于优化的实验参数集。 例如，如果需要快速提高 CPU 内核的频率（也许您有一个具有大量空闲期的突发工作负载，但是当新事务出现时，您需要非常快速的响应能力），那么可能需要将处理器性能提升策略设置为“火箭”（顾名思义，将 CPU 内核频率提高到最大值，而不是在一段时间内提高它）。
如果您的工作负载非常突发，则可以缩短 PPM 检查间隔，以使 CPU 频率在突发到来后更快地开始增加。 如果您的工作负载没有高线程并发性，则可以启用核心停放以强制工作负载在较少数量的内核上执行，这也可能会提高处理器缓存命中率。
如果您只想在中等利用率级别（即，不是轻量级工作负载级别）增加 CPU 频率，则可以调整处理器性能增加/减少阈值，使其在观察到某些活动级别之前不会做出反应。
了解周期性行为
白天和夜间或周末可能有不同的性能要求，或者在不同时间运行不同的工作负载。 在这种情况下，一组 PPM 参数可能并非对所有时间段都是最佳的。 由于可以设计多个自定义电源计划，因此甚至可以针对不同的时间段进行调整，并通过脚本或其他动态系统配置方式在电源计划之间切换。
同样，这增加了优化过程的复杂性，因此这是一个问题，即从这种类型的调整中获得多少价值，当有重大的硬件升级或工作负载变化时，可能需要重复这样做。
这就是 Windows 首先提供 Balanced 电源计划的原因，因为在许多情况下，可能不值得为特定服务器上的特定工作负载进行手动优化。