Ray 开发者的调试#

本调试指南适用于 Ray 项目的贡献者。

在调试器中启动进程#

当进程崩溃时，通常在调试器中启动它们会很有用。Ray 目前允许进程在以下环境中启动：

  • valgrind

  • valgrind 分析器

  • 性能工具分析器

  • gdb

  • tmux

要使用这些工具中的任何一个，请确保首先在您的机器上安装了它们（已知 gdb 和 valgrind 在 MacOS 上存在问题）。然后，您可以通过添加环境变量 RAY_{PROCESS_NAME}_{DEBUGGER}=1 来启动 ray 进程的一个子集。例如，如果您想在 valgrind 中启动 raylet，那么您只需设置环境变量 RAY_RAYLET_VALGRIND=1。

要在 gdb 内部启动一个进程，该进程也必须在 tmux 内部启动。因此，如果你想在 gdb 中启动 raylet，你可以使用以下命令启动你的 Python 脚本：

RAY_RAYLET_GDB=1 RAY_RAYLET_TMUX=1 python

然后，您可以使用 tmux ls 列出 tmux 会话并附加到相应的会话。

你也可以获取 raylet 进程的核心转储，这在提交 issues 时特别有用。获取核心转储的过程是操作系统特定的，但通常涉及在启动 Ray 之前运行 ulimit -c unlimited 以允许写入核心转储文件。

后端日志#

raylet 进程记录了关于任务执行和节点间对象传输等事件的详细信息。要在运行时设置日志级别，您可以在启动 Ray 之前设置 RAY_BACKEND_LOG_LEVEL 环境变量。例如，您可以执行以下操作：

export RAY_BACKEND_LOG_LEVEL=debug
ray start

这将把源代码中的任何 RAY_LOG(DEBUG) 行打印到 raylet.err 文件中，你可以在 日志记录和调试 中找到该文件。如果成功，你应该会在 raylet.err 的第一行看到：

logging.cc:270: Set ray log level from environment variable RAY_BACKEND_LOG_LEVEL to -1

(-1 在 logging.h 中定义为 RayLogLevel::DEBUG。)

#include <chrono>

后端事件统计#

如果设置了 RAY_event_stats=1 环境变量，raylet 进程还会定期将事件统计信息转储到 debug_state.txt 日志文件中。要同时启用定期将统计信息打印到日志文件，您可以额外设置 RAY_event_stats_print_interval_ms=1000。

事件统计包括ASIO事件处理程序、周期性计时器和RPC处理程序。以下是事件统计的一个示例：

Event stats:
Global stats: 739128 total (27 active)
Queueing time: mean = 47.402 ms, max = 1372.219 s, min = -0.000 s, total = 35035.892 s
Execution time:  mean = 36.943 us, total = 27.306 s
Handler stats:
  ClientConnection.async_read.ReadBufferAsync - 241173 total (19 active), CPU time: mean = 9.999 us, total = 2.411 s
  ObjectManager.ObjectAdded - 61215 total (0 active), CPU time: mean = 43.953 us, total = 2.691 s
  CoreWorkerService.grpc_client.AddObjectLocationOwner - 61204 total (0 active), CPU time: mean = 3.860 us, total = 236.231 ms
  CoreWorkerService.grpc_client.GetObjectLocationsOwner - 51333 total (0 active), CPU time: mean = 25.166 us, total = 1.292 s
  ObjectManager.ObjectDeleted - 43188 total (0 active), CPU time: mean = 26.017 us, total = 1.124 s
  CoreWorkerService.grpc_client.RemoveObjectLocationOwner - 43177 total (0 active), CPU time: mean = 2.368 us, total = 102.252 ms
  NodeManagerService.grpc_server.PinObjectIDs - 40000 total (0 active), CPU time: mean = 194.860 us, total = 7.794 s

回调延迟注入#

有时，错误是由RPC问题引起的，例如，由于某些请求的延迟，系统进入死锁状态。为了调试和重现此类问题，我们需要有一种方法来为RPC请求注入延迟。为此，引入了 RAY_testing_asio_delay_us。如果你想让某些RPC请求的回调在一段时间后执行，你可以使用这个变量。例如：

RAY_testing_asio_delay_us="NodeManagerService.grpc_client.PrepareBundleResources=2000000:2000000" ray start --head

此语法的格式为 RAY_testing_asio_delay_us="method1=min_us:max_us,method2=min_us:max_us" 。条目以逗号分隔。有一个特殊的方法 * ，表示所有方法。它的优先级低于其他条目。