Ray Tune 的可伸缩性和开销基准测试#
我们进行了一系列微基准测试，评估了 Ray Tune 的可伸缩性，并分析了观察到的性能开销。这些基准测试的结果已反映在文档中，例如，我们在 如何消除性能瓶颈 中提供了建议。
本页概述了我们进行的实验。对于每个实验，目标是检查实验的总运行时长，并在观察到的开销相对于最小理论时间过高（例如，超过 20% 的开销）时解决问题。
在一些实验中，我们调整了默认设置以实现最大吞吐量，例如通过禁用试验同步或结果日志记录。如果出现这种情况，将在相应的基准测试描述中说明。
变量 |
试验数量 |
结果数/秒/试验 |
节点数量 |
CPU 数量/节点 |
试验时长 (秒) |
观察到的运行时长 |
|---|---|---|---|---|---|---|
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 检查点
|
16 |
2 |
300 |
392.42 |
下面我们将讨论一些我们在观察到较大开销的结果上的见解。
结果吞吐量#
结果吞吐量描述了 Ray Tune 在给定时间范围内可以处理的结果数量（例如，“每秒结果数”）。吞吐量越高，可以在没有显著延迟的情况下处理的并发结果越多。
结果吞吐量受到处理结果所需时间的限制。当一个试验报告结果时，只有在试验执行器重新触发远程训练函数后，它才会继续训练。如果许多试验同时报告结果，则每个后续的远程训练调用仅在该试验的结果处理完毕后才会触发。
为了加快处理速度，Ray Tune 会自适应地缓冲结果，以便在许多试验并行运行并同时报告大量结果时，试验训练可以更早地继续。尽管如此，对于数十或数百个试验，每个试验处理数百个结果仍然可能成为瓶颈。
主要见解：当试验处理成为瓶颈时，Ray Tune 会抛出警告。如果您注意到这成为了问题，请遵循我们在 常见问题 中概述的指南。一般来说，建议不要同时报告过多结果。考虑将报告间隔增加 5-10 倍。
下面我们将介绍结果吞吐量性能的更详细结果。
基准测试多个并发 Tune 试验#
在此设置中，日志记录器（CSV、JSON 和 TensorBoardX）和试验同步都被禁用，除非明确说明。
在此实验中，我们在集群上运行多个并发试验（最多 1,000 个）。然后我们调整试验的报告频率（每秒结果数）来测量吞吐量限制。
当日志记录和同步被禁用时，大约 500 个总结果/秒似乎是可接受性能的阈值。启用日志记录后，仍可以在没有太多开销的情况下管理大约 50-100 个结果/秒，但在此之后应考虑减少传入结果的措施。
试验数量 |
结果数 / 秒 / 试验 |
节点数量 |
CPU 数量 / 节点 |
试验时长。 |
当前 |
|---|---|---|---|---|---|
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 个并发试验。然后我们调整试验的报告频率（每秒结果数）来找到吞吐量限制。与集群实验设置相比，我们报告的频率更高，因为我们并行运行的总试验数较少。
在单个节点上，吞吐量似乎更高一些。启用日志记录后，处理 1000 个结果/秒在开销方面似乎是可接受的，尽管您可能仍然应该将目标定在较低的数字。
试验数量 |
结果数 / 秒 / 试验 |
节点数量 |
CPU 数量 / 节点 |
试验时长。 |
当前 |
|---|---|---|---|---|---|
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 会导致网络通信开销。这主要是由于试验同步，结果和检查点会定期通过网络同步和发送。默认情况下，这通过 SSH 进行，每次连接初始化可能需要 1 到 2 秒。由于这是一个阻塞操作，且针对每个试验发生，因此运行许多并发试验很快就会受到此同步的瓶颈影响。
在此实验中，我们在集群上运行了多个试验。每个试验都在一个单独的节点上运行。我们改变了并发试验（和节点）的数量，以查看网络通信对总运行时长的影响有多大。
主要见解：在分布式设置中运行多个并发试验时，考虑改用 云检查点 进行检查点同步。另一种选择是使用共享存储并禁用同步到驱动程序。最佳实践在 此处针对 Kubernetes 设置 进行了描述，但也适用于任何类型的设置。
下表显示了网络通信开销的更详细结果。
试验数量 |
结果数 / 秒 / 试验 |
节点数量 |
CPU 数量 / 节点 |
试验时长 |
当前 |
|---|---|---|---|---|---|
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 |