内容


减少 Linux 耗电,第 3 部分

调优结果

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 减少 Linux 耗电,第 3 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:减少 Linux 耗电,第 3 部分

敬请期待该系列的后续内容。

工作负载和调控器效果

电源效率是任何关心业务成本和环境问题的人应该考虑的重要因素。在本系列的最后一篇文章中,让我们检查您通过调优 Linux CPUfreq 子系统和内核调控器以更改处理器的运行频率,在电源效率上所造成的差异(用实际数字和图表表示),这种更改不会 对性能造成重大影响。

减少 Linux 耗电,第 2 部分:一般设置和与调控器相关的设置 中,您看到了如何使用和调优调控器,现在您将看到一些调控器效果。我将使用以下两个流行的工作负载来比较性能和电量消耗,展示一个调优后的调控器如何节约电能而不会牺牲性能。

  • 一个工作负载来自 SPECpower_ssj2008 基准测试,该测试评估电能和性能。
  • 一个工作负载来自一个电子商务购物应用程序,该程序在一个模拟在线购物会话期间收集许多统计数据,其中包括延迟时间和每秒的请求数量。

这些对比在一台运行 Red Hat Enterprise Linux 5.2 的 IBM System x® 3650 上完成。

SPECpower_ ssj2008 工作负载

以下结果来自评估电能和性能的 SPECpower_ssj2008 基准测试。要查看关于这个基准测试的更多信息或查看最新官方基准测试结果,请参见 SPEC Web 站点(参考资料 提供了一个链接)。注意,这些结果没有针对最优性能进行调优,不应被视为针对系统的正式基准测试结果,它们只是用于研究目的的结果。

SPECpower_ssj2008 使用一个 Java™ 基准测试以获取单位为 ssj_ops(ssj 操作)的性能得分,并在从 100% 负载到完全闲置的负载范围内运行这个基准测试。得分越高,系统可以完成的计算量就越大。

SPECpower_ssj2008 还测量电能(以瓦特为单位)并在每个负载水平计算一个性能/电能比(performance-to-power)。这个比率越高,系统的 “性能/电能” 效率也就越好。

默认调控器比较

图 1 比较了 5 个内核调控器的效果,它们都使用默认设置运行。可调优的 sched_mc_power_savingssched_smt_power_savings 被关闭,CPU 频率守护进程 cpuspeed 与 userspace 调控器一起运行。

图 1. 默认设置的得分和电能消耗
默认设置的得分和电能消耗
默认设置的得分和电能消耗

虚线显示单位为 ssj_ops 的得分,ssj_ops 是一个 SPECpower_ssj2008 性能度量指标。您可以看到,导致性能下降的主要因素是 powersave 调控器,这显然是因为 powersave 调控器静态处理器将频率设置为尽可能低的水平,以便尽量节约电能。

实线显示电能消耗。同样,powersave 调控器消耗的电能比其他调控器少,但这是以牺牲性能为代价的。另外,您还可以看到系统闲置时不同调控器之间的能耗差异。performance 调控器总是以最高频率运行,因此它在闲置时消耗的电能要比其他调控器高 10 瓦特左右。userspace 调控器以及 cpuspeed 守护进程在节约电能而不损害性能方面似乎是最好的默认调控器。我们可以通过在图 2 中比较每次运行的 “性能/电能” 比率来确认这一点。

图 2. 默认设置下的 “性能/电能” 比率
默认设置下的 “性能/电能” 比率
默认设置下的 “性能/电能” 比率

“性能/电能” 比率是 SPECpower_ssj2008 计算的一个度量指标,通过比较获得的得分和获得该得分所耗费的电能来度量一个系统的节电程度,因此比率越高越好。

如您所见,当所有调控器以默认设置运行时,userspace 调控器以及 cpuspeed 守护进程在多数负载水平下比其他调控器拥有更好的 “性能/电能” 比率,因此,userspace 调控器的能效最高。

调优

减少 Linux 耗电,第 2 部分:一般设置和与调控器相关的设置 所述,有一些针对 ondemand 和 conservative 调控器的可选调优参数。下面将介绍如何更改利用率阈值以影响调控器的能效。

Ondemand
ondemand up_threshold 默认设置为 80,表示一旦 CUP 利用率达到 80% 以上,ondemand 调控器将提高频率。下面我将向您展示,只需将 up_threshold 更改为 98,您就可以使 ondemand 调控器变得更有能效。

图 3 比较 ondemand 调控器以默认配置(up_threshold 为 80)运行的效果和以调优后的设置(up_threshold 为 98)运行的效果。在上述运行期间,可调优的 sched_mc_power_savingssched_smt_power_savings 均关闭。

图 3. ondemand 的得分和电能消耗
ondemand 的得分和电能消耗
ondemand 的得分和电能消耗

从图中的虚线可以看出,默认和调优 ondemand 调控器获得了非常相似的得分,可见,更改 up_threshold 不会影响性能。但是,显示电能消耗的实线的确显示出轻微的差异。如您所见,将 up_threshold 提高到 98 比使用默认阈值略微降低了电能消耗。

下面,我们看看图 4 中的 “性能/电能” 比率。

图 4. ondemand 的 “性能/电能” 比率
ondemand 的 “性能/电能” 比率
ondemand 的 “性能/电能” 比率

从图 4 可以看出,对于几乎每一个负载水平,调优后的 ondemand 调控器(利用率阈值为 98)比默认 ondemand 调控器的能效都略高一些。

Conservative
conservative 调控器有两个阈值可以调优:

  • 首先,up_threshold 默认设置为 80,表示一旦处理器利用率超过 80%,该调控器将提高频率。
  • 还有一个 down_threshold,默认值为 20。这表示一旦调控器发现处理器的利用率低于 20%,它将逐步降低频率以节约电能。

我将向您展示,只需将 up_threshold 更改为 98 并将 down_threshold 更改为 95 就可以调优 conservative 调控器,使其能效更高。这是相当大胆的调控器调优,但我将向您展示这个经过调优的调控器的能效将更高。

图 5 比较了 conservative 调控器以默认设置(up_threshold 为 80 且 down_threshold 为 20)运行的结果和以调优设置(up_threshold 为 98 且 down_threshold 为 95)运行的结果。在上述运行中,可调优的 sched_mc_power_savingssched_smt_power_savings 关闭。

图 5. conservative 的得分和电能消耗
conservative 的得分和电能消耗
conservative 的得分和电能消耗

同样,图 5 中的虚线显示,使用经过调优的调控器没有性能影响。而实线清晰地显示,默认调控器和调优调控器之间存在电能消耗差异:调优调控器在中等水平的负载下消耗更少的电能,在 50% 负载水平上减少了约 40 瓦特。这是一个较大的电能节约。您可以通过比较图 6 中的 “性能/电能” 比率确认这一点。

图 6. conservative 的 “性能/电能” 比率
conservative 的 “性能/电能” 比率
conservative 的 “性能/电能” 比率

这些比率显示调优的 conservative 调控器在从 30% 到 90% 的负载水平上比默认 conservative 调控器提高了能效。

调优的调控器比较

在这个小节中,我将比较调优的 ondemand 和 conservative 调控器与其他 3 个调控器。图 7 比较所有 5 个调控器,其中 ondemand 和 conservative 的阈值进行了调优。可调优的 sched_mc_power_savingssched_smt_power_savings 关闭,CPU 频率守护进程 cpuspeed 与 userspace 调控器同时运行。

图 7. 调优的调控器的得分和电能消耗
调优的调控器的得分和电能消耗
调优的调控器的得分和电能消耗

图 7 再次表明,尽管 powersave 调控器的确比其他调控器消耗更少的电能,但它对性能有较大的负面影响,因为它只在尽可能低的频率运行。(我们将在下一个图形中展示 powersave 与其他调控器相比之下的能效)。其他 4 个调控器获得相似的得分,不管它们是否进行了调优。同样,performance 调控器只在尽可能高的频率运行,您可以通过比较图中的实线看出这在电能消耗上导致多大的差异。与 cpuspeed 守护进程联合运行的 userspace 调控器和调优的 conservative 调控器在电能节约方面仅次于 powersave 调控器。userspace 调控器在 30% 到 50% 的负载水平上比调优的 conservative 调控器消耗的电能略少一些,而调优的 conservative 调控器在 50% 以上的负载水平上则比 userspace 调控器 消耗的电能更少。我们可以通过比较它们的 “性能/电能” 比率(见图 8)来了解哪个调控器的能效更高。

图 8. 调优的调控器的 “性能/电能” 比率
调优的调控器的 “性能/电能” 比率
调优的调控器的 “性能/电能” 比率

图 8 显示,调优的 conservative 调控器和运行 cpuspeed 的 userspace 调控器的能效非常相似。最终的得分(没有在这里显示)表明,调优的 conservative 调控器拥有最好的总体能效,但优势并不明显。

sched_mc_power_savings 比较

如前所述,sched_mc_power_savings 调优方法试图合并进程以占用尽可能低的内核资源,从而节约电能。图 9 和图 10 展示运行默认 conservative 调控器时,sched_mc_power_savings 分别为 on (1) 和 off (0) 时的 CPU 利用率的对比。以下比较展示在 10% 的负载水平上每个处理器的利用率,这样系统的平均利用率为 10%。

图 9. sched_mc_power_savings 关闭
sched_mc_power_savings 关闭
sched_mc_power_savings 关闭
图 10. sched_mc_power_savings 开启
sched_mc_power_savings 开启
sched_mc_power_savings 开启

您可以清楚地看到两个图形中的差异。图 9 显示,在 sched_mc_power_savings 关闭时,4 个处理器的利用率约为 15%,另外 4 个处理器的利用率约为 5%。图 10 显示,在 sched_mc_power_savings 开启时,负载聚合到 4 个处理器上,现在它们的利用率约为 20%,而其他 4 个处理器则闲置。联合使用这种调优方法和一个内核 CPUfreq 调控器能够减少电能消耗,因为负载聚合能够使一些处理器处于闲置状态,从而以较低的频率运行。

sched_smt_power_savings 比较

sched_mc_power_savings 类似,sched_smt_power_savings 调优方法试图将超线程聚合到尽可能少的 CPU 上,从而节约电能。图 11 和 12 展示,当默认 conservative 调控器在一个支持超线程的系统上运行时,sched_smt_power_savings 分别为 on (1) 和 off (0) 时的 CPU 利用率的对比。以下比较展示在 10% 的负载水平上每个处理器的利用率,这样系统的平均利用率为 10%。

图 11. sched_smt_power_savings 关闭
sched_smt_power_savings 关闭
sched_smt_power_savings 关闭
Figure 12. sched_smt_power_savings 开启
sched_smt_power_savings 开启
sched_smt_power_savings 开启

同样,当设置为开启时,负载将聚合。如果闲置或接近闲置的 CPU 能够使用 CPUfreq 调控器来降低频率且/或闲置 C 状态,同时结合使用这种类型的调度,那么电能节约就有可能实现。

一个电子商务工作负载

在这个小节中,我将在另一种类型的工作负载上比较调控器的效果。以下结果来自一个电子商务购物应用程序,该程序在一个模拟在线购物会话期间收集许多统计数据,包括延迟时间和每秒请求数。这个应用程序使用一个 Apache 前端,一个 PHP 实现和一个 MySQL 数据库来创建一个可用的购物站点。注意,这些结果没有针对最优性能进行调优,不应被视为针对系统的正式结果。我们将在不同的利用率负载水平上比较这个工作负载上的效果。

默认调控器比较

以下图形比较 conservative 和 ondemand 这两个可调优内核调控器和作为基准比较的 performance 调控器。所有调控器使用默认设置运行,调优方法 sched_mc_power_savingssched_smt_power_savings 在运行期间关闭。

图 13 系列展示一个总共带有 500 个客户端的在线购物会话的统计数据。测试系统在运行 500 个客户端时的平均利用率为 8-12%。

图 13a. 性能(请求/秒)
性能(请求/秒)
性能(请求/秒)
图 13b. 延迟时间(毫秒)
延迟时间(毫秒)
延迟时间(毫秒)
Figure 13c. 平均电能(瓦特)
平均电能(瓦特)
平均电能(瓦特)
Figure 13d. 性能/瓦特
性能/瓦特
性能/瓦特

图 13a 展示这个购物会话的性能,单位为 “请求/秒”。您可以看到,所有 3 个调控器每秒的请求数几乎完全相同。

图 13b 显示平均延迟时间稍微有一些区别。conservative 调控器比 performance 调控器几乎延迟 7 毫秒,但对于在线购物车这样的应用程序来说,多数用户不会注意到增加的几毫秒,因此这个区别可以忽略。

图 13c 显示平均电能消耗。可以看出,conservative 调控器比 performance 调控器大约节约了 20W;也就是说,没有处理器变频且 ondemand 调控器平均节约 15W。

图 13d 通过用每秒请求数除以平均电能消耗显示 “性能/瓦特”。三个调控器的类似性能和两个动态调控器的电能节约意味着后者具有更高的 “性能/瓦特” 值。conservative 调控器在 8-12% 的利用率负载水平上的能效最高,紧随其后的是 ondemand 调控器。

下面,我们将在更高的负载水平上比较三个默认调控器的 “性能/瓦特” 值,看看默认的 conservative 调控器是否仍然比其他两个默认调控器的能效更高。图 14 展示了一个 1,000 个客户端的负载,这个负载导致 20-25% 的平均利用率。

图 14. 针对 1,000 个客户端的默认调控器比较
针对 1,000 个客户端的默认调控器比较
针对 1,000 个客户端的默认调控器比较

从这个图表可以看出,对于这个负载水平,conservative 调控器也是能效最高的调控器。对于这次运行,conservative 调控器比 performance 调控器节约了约 25W,当它仍然可以服务几乎完全相同的每秒请求数。对于这个负载水平,conservative 调控器的平均请求延迟时间比其他两个调控器慢了约 5 毫秒。

最后,让我们看看图 15 中负载水平为 2,000 个客户端时的 “性能/瓦特" 值,该负载水平将测试系统的平均利用率提高到 45-60%。

图 15. 针对 2,000 个客户端的默认调控器比较
针对 2,000 个客户端的默认调控器比较
针对 2,000 个客户端的默认调控器比较

对于这个负载水平,默认 ondemand 调控器拥有的 “性能/瓦特” 值略好一些。ondemand 和 conservative 调控器都节约了约 15W,但默认 conservative 调控器的性能出现降低,因为它每秒完成的请求数比其他两个调控器少 8 个,它的延迟时间比 performance 调控器慢了 0.15 秒。这一次 ondemand 调控器是赢家,因为它实际上完成了相同数量的每秒请求数而延迟时间只比 performance 调控器多 50 毫秒,当然,这表示系统无需任何处理器变频情况下实现的性能。

调优的调控器比较

现在我们将比较调优的 ondemand 和 conservative 调控器在这个工作负载下的表现。同样,调控器调优通过更改利用率阈值实现。调优的 conservative 调控器的 up_threshold 设置为 98,down_threshold 设置为 95。调优的 ondemand 调控器也使用 up_threshold 为 98 的设置运行。我们将在图 16 系列中查看在更繁重的 2,000 个客户端的负载水平(平均利用率为 45-60%)上这两个调优过的调控器的效果。

较轻的负载水平不会显示明显的差异,因为在 20% 的利用率(默认的 down_threshold 设置)下,调优的调控器在所有负载水平上的表现与默认调控器相同。 调优方法 sched_mc_power_savingssched_smt_power_savings 在运行期间关闭。

图 16a. 性能(请求/秒)
性能(请求/秒)
性能(请求/秒)
图 16b. 延迟时间(毫秒)
延迟时间(毫秒)
延迟时间(毫秒)
图 16c. 平均电能(瓦特)
平均电能(瓦特)
平均电能(瓦特)
图 16d. 性能/瓦特
性能/瓦特
性能/瓦特

图 16a 和 16b 显示,调优的 conservative 调控器的性能略有降低:每秒完成的请求数减少约 13 个,延迟时间比 performance 调控器约多 0.28 秒。但图 16c 显示,调优的 conservative 调控器比没有处理器变频时大约节约 55W。即使性能略有降低,调优的 conservative 调控器也是目前为止能效最高的。

结束语

在这个 3 部分系列 中,我向您展示了在多数情况下,一个调优的 conservative 调控器(up_threshold 为 98、down_threshold 为 95)能够取得最好的 “性能/电能” 效率。在某些情况下,这个调控器可能会对性能有轻微负面影响。

您必须确定,以可能发生的性能降低来换取实现潜在的巨大电能节约是否值得。如前所述,您可以使用许多针对动态内核调控器的调优方法来影响调控器的性能,这可能会反过来影响正在运行的工作负载的性能。

电能节约和性能之间总是存在一种平衡,但我希望我已经向您展示如何将性能影响降低到一个可以忽略的程度,同时使系统获得更好的电能效率。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Linux
ArticleID=444291
ArticleTitle=减少 Linux 耗电,第 3 部分: 调优结果
publish-date=11052009