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日

性能分析类别中排名50

Download history 105/week @ 2024-04-20 159/week @ 2024-04-27 83/week @ 2024-05-04 83/week @ 2024-05-11 192/week @ 2024-05-18 55/week @ 2024-05-25 109/week @ 2024-06-01 52/week @ 2024-06-08 32/week @ 2024-06-15 79/week @ 2024-06-22 39/week @ 2024-06-29 58/week @ 2024-07-06 131/week @ 2024-07-13 96/week @ 2024-07-20 154/week @ 2024-07-27 77/week @ 2024-08-03

每月下载量470

Apache-2.0

240KB
6K SLoC

资源控制演示哈希守护进程

rd-hashdresctl-demoresctl-bench的工作负载模拟器。其主要目标是模拟一个延迟敏感、可调节的主要工作负载,可以饱和机器的所有本地资源。

想象一个延迟敏感的用户请求处理应用程序,该应用程序负载均衡并配置为在满载下使用机器的所有可用资源。在正常负载下,它将消耗较小的资源量并显示更紧密的延迟曲线。当负载接近满载时,它将消耗机器的大部分资源,延迟会增加,但希望仍然保持在目标范围内。如果由于任何原因(包括资源冲突)应用程序停滞,它将经历延迟峰值,负载均衡器会减少分配给它的请求,直到它能够赶上。

rd-hashd以自包含的方式模拟这种工作负载。它设置测试文件和具有随机内容的内存堆,并使用多个工作线程持续计算SHA1。并发级别被调节,以使RPS收敛到目标值,同时不超过延迟目标。RPS和延迟目标可以动态修改。内存访问模式遵循正态分布,注入小的随机睡眠来模拟网络交互,并且它还会生成日志写入。

rd-hashd的资源消耗行为的许多方面都是可配置的,并且默认情况下被调整,以在内存和IO竞争的情况下表现得类似于流行的Facebook网络工作负载。

rd-hashdresctl-demoresctl-bench 的主要工作负载。虽然单个工作负载不能完全代表系统使用的多种方式,但它可以成功地捕捉到典型人机交互工作负载的许多方面,重现广泛的资源冲突问题并验证其解决方案,并可作为评估硬件和操作系统行为的近似度量。

虽然 rd-hashd 通常用作 resctl-demoresctl-bench 的一部分,但它也可以作为一个独立伪工作负载使用。有关包含项目的更多信息,请访问

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

配置、报告和日志文件

存在两个配置通道 - 命令行参数和运行时参数。前者可以作为命令行选项或使用 --args 文件指定。后者可以使用 --params 文件指定,并在 rd-hashd 运行时动态更新 - 只需编辑并保存,更改将立即生效。

如果指定的 --args 和/或 --params 文件不存在,它们将被创建为默认值。可以在命令行中覆盖 --args 文件中的任何配置,并且文件将相应更新。请注意,只有帮助信息中列出的 --args 上的参数才会保存。如果没有指定 --params,则使用默认值,并且无法在 rd-hashd 运行时更新参数。

rd-hashd 将当前状态报告到可选的 --report 文件中,并将散列结果保存到 --log-dir 目录的可选日志文件中。

以下命令将创建 --args--params 文件并退出。

$ rd-hashd --testfiles ~/rd-hashd/testfiles --args ~/rd-hashd/args.json \
  --params ~/rd-hashd/params.json --report ~/rd-hashd/report.json \
  --log-dir ~/rd-hashd/logs --interval 1 --prepare-config

之后,可以使用以下配置运行 rd-hashd

  $ rd-hashd --args ~/rd-hashd/args.json

基准测试

找到最大化资源利用的最佳参数是具有挑战性的。为了帮助确定参数,--bench 执行一系列测试,并将确定的参数记录到指定的 --args--params 文件中。

使用生成的参数,rd-hashd 应该在满载时饱和 CPU 和内存,并使用一定量的 I/O。RPS 将对内存敏感,因此资源冲突会导致请求处理延迟增加和 RPS 降低。

--bench 可能需要超过十分钟,系统应保持空闲。尽管它尽力而为,但由于长时间尾内存访问和硬件 I/O 性能特性的波动,配置可能无法在长时间运行中持续。如果 rd-hashd 无法保持 CPU 饱和并显著偏离目标 RPS,请尝试降低运行时参数 mem_frac。如果生成的 I/O 不足,请尝试增加。

--bench 尽可能保留配置文件中的现有参数。如果基准测试行为异常,请尝试删除配置文件以从头开始。

使用示例

以下是一个示例工作流程。它清除现有的配置,执行基准测试以确定参数,然后启动正常运行。

  $ mkdir -p ~/rd-hashd
  $ rm -f ~/rd-hashd/*.json
  $ rd-hashd --args ~/rd-hashd/args.json --testfiles ~/rd-hashd/testfiles \
             --params ~/rd-hashd/params.json --report ~/rd-hashd/report.json \
             --log-dir ~/rd-hashd/logs --interval 1 --bench
  $ rd-hashd --args ~/rd-hashd/args.json

依赖关系

~11–39MB
~606K SLoC