Ray Tune 的可扩展性和开销基准测试#
我们进行了一系列微基准测试，在此我们评估了 Ray Tune 的可扩展性并分析了我们观察到的性能开销。这些基准测试的结果反映在文档中，例如当我们提出关于如何消除性能瓶颈的建议时。
本页面概述了我们进行的实验。对于这些实验中的每一个，目标都是检查实验的总运行时间，并在观察到的开销与最小理论时间相比过高时（例如，超过 20% 的开销）解决问题。
在一些实验中，我们调整了最大吞吐量的默认设置，例如通过禁用 trial 同步或结果日志记录。如果适用，这将在相应的基准测试描述中说明。
变量 |
Trial 数量 |
每秒结果数/trial |
节点数 |
每节点 CPU 数 |
Trial 长度 (秒) |
观察到的运行时间 |
|---|---|---|---|---|---|---|
10,000 |
1 |
1 |
16 |
1 |
715.27
(最少 625)
|
|
1,000 |
0.1 |
16 |
64 |
100 |
168.18 |
|
96 |
10 |
1 |
96 |
100 |
168.94 |
|
200 |
1 |
200 |
2 |
300 |
2280.82 |
|
16 |
结果: 1/60
检查点: 1/900
|
1 |
16 |
86,400 |
88687.41 |
|
16 |
10/60
带 10MB CP
|
16 |
2 |
300 |
392.42 |
下面我们讨论一些关于我们观察到大量开销的测试结果。
结果吞吐量#
结果吞吐量描述了 Ray Tune 在给定时间范围内可以处理的结果数量（例如，“每秒结果数”）。吞吐量越高，可以处理的并发结果就越多，而不会出现重大延迟。
结果吞吐量受处理结果所需时间限制。当一个 trial 报告结果时，只有当 trial executor 重新触发远程训练函数后，它才会继续训练。如果许多 trial 同时报告结果，每个后续的远程训练调用都将在处理该 trial 的结果后才会触发。
为了加快处理速度，Ray Tune 会自适应地缓冲结果，以便在许多 trial 并行运行并同时报告大量结果时，更早地继续 trial 训练。尽管如此，为几十个或几百个 trial 处理数百个结果仍然可能成为瓶颈。
主要见解：当 trial 处理成为瓶颈时，Ray Tune 会发出警告。如果您注意到这成为一个问题，请遵循我们在FAQ中概述的指南。通常，建议不要同时报告太多结果。考虑将报告间隔增加 5-10 倍。
下面我们展示关于结果吞吐量性能的更详细结果。
基准测试大量并发 Tune trial#
在此设置中，记录器（CSV、JSON 和 TensorBoardX）和 trial 同步被禁用，除非另有明确说明。
在此实验中，我们在一个集群上运行大量并发 trial（最多 1000 个）。然后，我们调整 trial 的报告频率（每秒结果数）来测量吞吐量限制。
看起来，当禁用日志记录和同步时，每秒约 500 个总结果似乎是可接受性能的阈值。启用日志记录后，每秒仍可处理约 50-100 个结果而不会产生过多开销，但之后应考虑采取措施减少传入结果。
Trial 数量 |
每秒结果数/trial |
节点数 |
每节点 CPU 数 |
Trial 长度。 |
当前 |
|---|---|---|---|---|---|
1,000 |
10 |
16 |
64 |
100 秒 |
248.39 |
1,000 |
1 |
16 |
64 |
100 秒 |
175.00 |
1,000 |
0.1 含日志记录 |
16 |
64 |
100 秒 |
168.18 |
384 |
10 |
16 |
64 |
100 秒 |
125.17 |
256 |
50 |
16 |
64 |
100 秒 |
307.02 |
256 |
20 |
16 |
64 |
100 秒 |
146.20 |
256 |
10 |
16 |
64 |
100 秒 |
113.40 |
256 |
10 含日志记录 |
16 |
64 |
100 秒 |
436.12 |
256 |
0.1 含日志记录 |
16 |
64 |
100 秒 |
106.75 |
基准测试单节点上的大量 Tune 结果#
在此设置中，记录器（CSV、JSON 和 TensorBoardX）被禁用，除非另有明确说明。
在此实验中，我们在单节点上运行 96 个并发 trial。然后，我们调整 trial 的报告频率（每秒结果数）来找到吞吐量限制。与集群实验设置相比，我们报告的频率要高得多，因为我们并行运行的总 trial 数量较少。
在单节点上，吞吐量似乎略高。启用日志记录后，每秒处理 1000 个结果在开销方面似乎是可以接受的，尽管您可能仍应以较低的数字为目标。
Trial 数量 |
每秒结果数/trial |
节点数 |
每节点 CPU 数 |
Trial 长度。 |
当前 |
|---|---|---|---|---|---|
96 |
500 |
1 |
96 |
100 秒 |
959.32 |
96 |
100 |
1 |
96 |
100 秒 |
219.48 |
96 |
80 |
1 |
96 |
100 秒 |
197.15 |
96 |
50 |
1 |
96 |
100 秒 |
110.55 |
96 |
50 含日志记录 |
1 |
96 |
100 秒 |
702.64 |
96 |
10 |
1 |
96 |
100 秒 |
103.51 |
96 |
10 含日志记录 |
1 |
96 |
100 秒 |
168.94 |
Ray Tune 中的网络开销#
在分布式设置中运行 Ray Tune 会产生网络通信开销。这主要是由于 trial 同步，其中结果和检查点会定期同步并通过网络发送。默认情况下，这通过 SSH 进行，连接初始化每次可能需要 1 到 2 秒。由于这是一个阻塞操作，并且是按 trial 进行的，因此运行大量并发 trial 会很快因这种同步而成为瓶颈。
在此实验中，我们在集群上运行了多个 trial。每个 trial 都在一个单独的节点上运行。我们改变了并发 trial（和节点）的数量，以查看网络通信对总运行时间的影响有多大。
主要见解：在分布式设置中运行大量并发 trial 时，请考虑使用云检查点进行检查点同步。另一种选择是使用共享存储并禁用同步到驱动程序。最佳实践在此处针对 Kubernetes 设置进行了描述，但适用于任何类型的设置。
下表展示了关于网络通信开销的更详细结果。
Trial 数量 |
每秒结果数/trial |
节点数 |
每节点 CPU 数 |
Trial 长度 |
当前 |
|---|---|---|---|---|---|
200 |
1 |
200 |
2 |
300 秒 |
2280.82 |
100 |
1 |
100 |
2 |
300 秒 |
1470 |
100 |
0.01 |
100 |
2 |
300 秒 |
473.41 |
50 |
1 |
50 |
2 |
300 秒 |
474.30 |
50 |
0.1 |
50 |
2 |
300 秒 |
441.54 |
10 |
1 |
10 |
2 |
300 秒 |
334.37 |