Lib.rs

› 操作系统 › Unix API › resctl-demo
#资源 #基准测试 #控制 #工作负载 #resctl-demo #场景 #测试

app resctl-bench

具有实际场景的全系统资源控制基准测试

由 Tejun Heo、santoshmahto7 和 5位贡献者 开发

10个稳定版本

2.2.5 2024年3月14日
2.2.4 2024年2月14日
2.2.3 2022年6月28日
2.2.2 2022年5月26日
2.0.0 2021年6月24日

#223 在 Unix API 中

Download history 111/week @ 2024-04-21 156/week @ 2024-04-28 79/week @ 2024-05-05 84/week @ 2024-05-12 198/week @ 2024-05-19 47/week @ 2024-05-26 108/week @ 2024-06-02 49/week @ 2024-06-09 28/week @ 2024-06-16 86/week @ 2024-06-23 34/week @ 2024-06-30 51/week @ 2024-07-07 141/week @ 2024-07-14 100/week @ 2024-07-21 106/week @ 2024-07-28 77/week @ 2024-08-04

每月426次下载

Apache-2.0

655KB
17K SLoC

资源控制基准测试

资源控制旨在控制计算资源分配，以提高系统的可靠性和利用率。resctl-bench 是一个包含全系统基准测试的集合，用于评估资源控制和硬件行为，使用实际的模拟工作负载。

综合资源控制涉及整个系统 - 如cgroup2、内存管理、文件系统和块层等内核子系统，以及用户空间系统组件，甚至SSD。此外，测试资源控制端到端需要涉及实际工作负载的场景，并监控其交互。这种组合使得资源控制基准测试具有挑战性和易出错。配置容易出错，并且使用真实工作负载进行测试既繁琐又不可靠。

resctl-bench 封装了整个过程，以便可以轻松且可靠地执行资源控制基准测试。它验证并更新系统配置，使用具有实际延迟敏感的工作负载模拟器和其他次要工作负载重现资源竞争场景，分析结果系统和工作负载行为，并生成易于理解的报告。

resctl-bench 是 resctl-demo 套件的一部分，它通过基于相同组件构建的实时场景引导用户了解各种资源控制策略。在 resctl-bench 中实现的基准测试涉及在 resctl-demo 中深入记录的概念和组件。有关 resctl-demo 的更多信息，请访问

https://github.com/facebookexperimental/resctl-demo

预制的系统镜像

综合资源控制有许多要求，其中一些在现有系统上可能难以配置。resctl-demo提供预制的镜像，以帮助您开始。访问以下页面获取详细信息

https://facebookmicrosites.github.io/resctl-demo-website

有关其他安装选项，请访问

https://github.com/facebookexperimental/resctl-demo

示例会话

假设我们想知道iocost如何保护rd-hashd，并设计了以下基准测试序列

  1. 运行hashd-params以确定hashd参数。
  2. 运行protection并禁用iocost以建立基线。
  3. 运行iocost-params以确定iocost参数。
  4. 启用iocost后运行protection并比较结果。

假设根设备是nvme0n1，设备号为259:0，这映射到

   $ echo '259:0 enable=0' > /sys/fs/cgroup/io.cost.qos
   $ echo 0 > /sys/block/nvme0n1/queue/wbt_lat_usec
   $ resctl-bench -r result.json run \
     hashd-params:passive=io \
     protection:id=iocost-off,passive=io \
     iocost-params \
     protection:id=iocost-on
  • 我们想在不启用iocost的情况下运行前两个基准测试。手动将其关闭，并告诉前两个不要更改与IO相关的配置。wbt也被关闭，以保持与启用iocost配置的一致性。
  • 为了减少混淆，我们用不同的ID标记了两次protection运行。

以下是示例输出

让我们看一下第一个基准测试的结果 - hashd-params。

   [hashd-params result] 2021-06-22 17:23:03 - 17:43:47

   System info: kernel="5.6.13-0_fbk16_5756_gdcbe47195163"
                nr_cpus=36 memory=63.9G swap=32.0G swappiness=60 zswap
                mem_profile=16 (avail=57.4G share=12.0G target=11.0G)
                passive=io

   IO info: dev=nvme0n1(259:0) model="WDC CL SN720 SDAQNTW-512G-1020" firmware="10105120" size=477G
            iosched=none wbt=off iocost=off other=off

   Params: log_bps=1.0M

   Result: hash_size=1.2M rps_max=1029 mem_actual=16.1G chunk_pages=25

在标题之后，以下三个部分显示了系统和基准配置，然后是结果。

  • passive=io，因此IO配置保持不变。我们可以看到iocost和其他IO控制器都是关闭的。
  • zswap被报告。我忘记将其关闭了。随后的基准测试将自动关闭zswap，因为它们是存储密集型基准测试。如果在这里也关闭了zswap会更好，但由于所有数据都是不可压缩的，而且这个基准的主要目标是建立共同测量标准，所以这不会造成太大差异。
  • 确定的内存占用为16.1G，考虑到基准测试可用的内存量 - mem_target - 只有11G，这是一个相当不错的成绩。

现在让我们看一下第一个结果。部分标题

   [protection result] "iocost-off" 2021-06-22 19:13:37 - 19:30:25
   ...
   IO info: dev=nvme0n1(259:0) model="WDC CL SN720 SDAQNTW-512G-1020" firmware="10105120" size=477G
            iosched=none wbt=off iocost=off other=off

显示这是ID为iocost-off的protection结果。跳过到结果部分

   Memory Hog Summary
   ==================

   IO Latency: R p50=885u:3.7m/49.5m p90=4.7m:12.7m/150m p99=13.1m:25.1m/350m max=30.4m:65.4m/750m
               W p50=5.0m:16.3m/99.5m p90=17.6m:28.3m/250m p99=29.0m:38.8m/450m max=48.9m:87.0m/850m

   Isolation and Request Latency Impact Distributions:

                 min   p01   p05   p10   p25   p50   p75   p90   p95   p99   max  mean stdev
   isol%           0  0.49  1.65  2.24 13.12 50.90 72.52 82.12 88.56 100.0 100.0 45.50 30.72
   lat-imp%        0     0     0     0  4.69 17.00 40.54 75.06 121.9 380.3 882.5 39.42 81.53

   Result: isol=45.50:30.72% lat_imp=39.42%:81.53 work_csv=100.0% missing=0.26%

为了简洁起见，让我们只关注最后一行的isol=45.50:30.72%，这表明隔离因子 - 即rd-hashd的RPS能够抵抗内存消耗者的干扰的程度 - 平均为45.5%，标准差为30.72%。粗略地说，当系统出现内存短缺时，我们的主要工作负载的RPS减半。有关输出格式的更多信息

因此，我们现在知道没有iocost，保护效果并不好。下一个iocost-params基准测试确定参数，以便我们可以启用它。结果

   iocost model: rbps=1348822120 rseqiops=235687 rrandiops=218614
                 wbps=601694170 wseqiops=133453 wrandiops=69308
   iocost QoS: rpct=95.00 rlat=19562 wpct=95.00 wlat=65667 min=60.00 max=100.00

iocost-params 会自动应用后续基准测试中确定的参数。此处确定的QoS参数非常简单，但应该能满足我们的需求。为了确定更准确的QoS参数和全面评估存储设备，请参阅 iocost-tune 基准测试。

让我们看看在开启 iocost 后，protection 的结果是否有所改善。

   [protection result] "iocost-on" 2021-06-22 19:38:53 - 20:02:27
   ...
   IO info: dev=nvme0n1(259:0) model="WDC CL SN720 SDAQNTW-512G-1020" firmware="10105120" size=477G
            iosched=none wbt=off iocost=on other=off
            iocost model: rbps=1348822120 rseqiops=235687 rrandiops=218614
                          wbps=601694170 wseqiops=133453 wrandiops=69308
            iocost QoS: rpct=95.00 rlat=19562 wpct=95.00 wlat=65667 min=60.00 max=100.00

标题确认我们正在测试正确的配置。结果

   Memory Hog Summary
   ==================

   IO Latency: R p50=164u:42.2u/415u p90=915u:827u/17.5m p99=3.4m:4.5m/97.5m max=8.8m:10.3m/250m
               W p50=158u:1.7m/41.5m p90=2.3m:9.1m/95.5m p99=5.1m:14.3m/97.5m max=8.8m:21.7m/350m

   Isolation and Request Latency Impact Distributions:

                 min   p01   p05   p10   p25   p50   p75   p90   p95   p99   max  mean stdev
   isol%           0     0 88.34 90.57 93.78 97.30 100.0 100.0 100.0 100.0 100.0 95.18 11.06
   lat-imp%        0     0  0.96  2.20  3.79  6.49 10.22 15.63 18.32 29.55 263.0  8.14  9.99

   Result: isol=95.18:11.06% lat_imp=8.14%:9.99 work_csv=42.89% missing=0.21%

隔离因素的平均值现在是95.18%，标准差为11.06%，与未启用 iocost 时的45.5%相比有显著提高。

此示例表明，使用 resctl-bench 在实际测试每个层级的资源控制行为时既简单又可靠。有关更多信息，请探索文档页面

依赖项

~28–69MB
~1M SLoC