调试指南#

本指南介绍了 Triton 在行为异常或失败时的初步故障排除步骤。下面，我们将问题分解为以下几类

  • 配置问题：Triton 报告您的配置文件存在错误。

  • 模型问题：您的模型加载或执行推理失败。

  • 服务器：服务器崩溃或不可用。

  • 客户端：客户端在向服务器发送和接收数据时失败。

  • 性能：Triton 未达到最佳性能。

无论您的问题属于哪一类，都值得尽可能尝试在最新的 Triton 容器中运行。虽然我们为旧容器提供支持，但修复程序会合并到下一个版本中。通过检查最新版本，您可以发现此问题是否已得到解决。

您还可以搜索 Triton 的 GitHub 问题，看看是否有人之前问过您的问题。如果您收到错误，可以使用错误中的几个关键字作为搜索词。

Triton 提供了不同类型的错误和状态，这些错误和状态与各种问题相关。以下是它们的概述

错误

定义

示例

已存在

当由于已存在项目而无法执行操作时返回。

已注册的模型无法再次注册。

内部错误

当 Triton 代码内部发生意外故障时返回。

内存分配失败。

无效参数

当为函数提供无效参数时返回

模型配置具有无效参数

未找到

当无法找到请求的资源时返回

无法找到共享库

不可用

当找到请求的资源但不可用时返回

请求的模型未准备好进行推理

未知错误

对于错误原因未知的情况返回

不应使用此错误代码

不支持

当选项不受支持时返回

模型配置包含后端尚不支持的参数

配置问题#

在继续之前，请查看模型配置文档 此处 是否解决了您的问题。除此之外，为您的用例找到示例模型配置的最佳位置是

请注意，如果您遇到 perf_analyzer 或 模型分析器 的问题，请尝试直接将模型加载到 Triton 上。这将检查配置是否不正确，或者是否需要更新 perf_analyzer 或模型分析器选项。

模型问题#

步骤 1. 在 Triton 外部运行模型

如果您在加载或运行模型时遇到问题，第一步是确保您的模型在其框架内在 Triton 外部运行。例如，您可以在 ONNX Runtime 中运行 ONNX 模型，在 trtexec 中运行 TensorRT 模型。如果此检查失败，则问题发生在框架内部，而不是 Triton 内部。

步骤 2. 查找错误消息

如果您收到错误消息，您或许可以通过搜索代码来查找其生成位置。GitHub 提供了有关搜索代码的说明 此处。通过 Triton 组织进行通用搜索可在 此链接 中找到。

如果您的错误消息仅在 Triton 代码中的一个或几个位置出现，您或许可以很快看到问题所在。即使不是，最好也保存此链接，以便在就您的问题寻求帮助时提供给我们。这通常是我们首先寻找的东西。

步骤 3. 使用调试标志构建

下一步是使用调试标志进行构建。遗憾的是，我们不提供调试容器，因此您需要按照 构建指南 构建容器，其中包括一个 关于添加调试符号的部分。完成此操作后，您可以在容器中安装 GDB (apt-get install gdb>) 并在 GDB 中运行 Triton (gdb --args tritonserver…)。如果需要，您可以打开第二个终端以在另一个容器中运行脚本。如果服务器发生段错误，您可以输入 backtrace，这将为您提供一个调用堆栈，让您知道错误生成的位置。然后，您应该能够跟踪错误的来源。如果在调试后错误仍然存在，我们将需要此信息来加快我们的工作。

高级 GDB 用户还可以检查变量值、添加断点等，以查找问题的原因。

特定问题#

未定义的符号

这里有几个选项

  • 这通常意味着 Triton 使用的框架版本与用于创建模型的框架版本之间存在版本不匹配。检查 Triton 容器中使用的框架版本，并与用于生成模型的版本进行比较。

  • 如果您正在加载后端使用的共享库，请不要忘记在运行 Tritonserver 的命令之前包含 LD_PRELOAD。

    • LD_PRELOAD=<name_of_so_file.so> tritonserver --model-repository… 如果您自己构建了后端，则可能是链接错误。如果您确信后端和服务器构建正确，请仔细检查服务器是否正在加载正确的后端。

服务器问题#

通常您不应遇到服务器本身的问题。如果服务器宕机，通常是因为模型加载或推理过程中出现问题，您可以使用以上部分进行调试。特别有用的是完成以上 使用调试标志构建 部分，以解决这些类型的问题。但是，本节将介绍可能发生的一些特定情况。

无法连接到服务器#

如果您在连接到服务器或通过运行状况端点 (curl -v localhost:8000/v2/health/ready) 获取其运行状况时遇到问题，请确保您可以从运行命令的位置访问服务器正在运行的网络。最常见的情况是，当为客户端和服务器启动单独的 Docker 容器时，它们没有使用 –net=host 共享网络。

间歇性故障#

这将是最难调试的事情之一。如果可能，您需要使用调试标志构建服务器，以获取具体发生情况的回溯。您还需要记笔记，以了解这种情况发生的频率以及是否是常见原因。服务器本身在空闲时应该不会失败，因此请查看特定操作（加载/卸载模型、运行模型推理等）是否触发了它。

由于个别模型导致的服务器故障#

如果您希望服务器即使在模型失败时也能启动，请使用 exit-on-error=false 选项。如果您希望服务器运行状况端点即使在特定模型失败时也显示就绪状态，请使用 --strict-readiness=false 标志。

死锁#

使用 gdb 调试死锁的一些有用步骤

  1. 使用 $info threads 查看哪些线程正在等待。

  2. 转到线程：$thread 4。

  3. 打印回溯：$bt。

  4. 转到带有锁的帧：$f 1。

  5. 打印持有的互斥锁的内存：$p *mutex。

  6. 您现在可以在 owner 下看到互斥锁的所有者。

客户端问题#

对于处理不同的客户端案例，最好的资源是 客户端仓库 的示例。您可以查看用 Python、Java 和 C++ 编写的客户端，其中包含跨越许多常见用例的运行示例。您可以查看这些客户端的主要功能，以了解代码的流程。

我们经常收到关于客户端的性能优化问题。Triton 客户端以原始二进制形式发送输入张量。但是，GRPC 使用 protobuf，后者有一些序列化和反序列化开销。对于那些寻求最低延迟解决方案的人来说，C API 消除了与 GRPC/HTTP 相关的延迟。当客户端和服务器位于同一系统上时，共享内存也是减少数据移动的好选择。

性能问题#

本节介绍如何调试意外的性能问题。如果您正在寻求优化性能，请参阅 优化 和 性能调优 指南。

最简单的入门步骤是运行 perf_analyzer，以获取每个单独模型的请求生命周期、吞吐量和延迟的细分。要获得更详细的视图，您可以在运行服务器时 启用跟踪。这将提供精确的时间戳，以便深入了解正在发生的事情。您还可以通过使用跟踪标志为 GRPC 和 HTTP 客户端启用跟踪。请注意，启用跟踪可能会影响 Triton 的性能，但它有助于检查整个请求生命周期中的时间戳。

性能分析#

下一步是使用性能分析器。我们推荐的一个分析器是 Nsight Systems (nsys)，可以选择包括 NVIDIA Tools Extension (NVTX) 标记来分析 Triton。

Triton 服务器容器已安装 nsys。但是，Triton 默认情况下不使用 NVTX 标记进行构建。如果您想使用 NVTX 标记，则应使用 build.py 和 “–enable-nvtx” 标志构建 Triton。这将提供有关处理请求的某些阶段的详细信息，例如排队、运行推理和处理输出。

您可以通过运行 nsys profile tritonserver --model-repository … 来分析 Triton。nsys 文档 提供了更多选项和详细信息，以全面了解正在发生的事情。

提交问题#

如果您已完成初步调试步骤但没有结果，则下一步是向我们提交问题。在您提交之前，请回答以下问题

  • 这是否可以通过多个模型和/或我们的示例模型重现？还是问题仅限于您的模型？

  • 该错误是否可以通过任何协议（例如：HTTP 与 GRPC）重现？还是仅限一种协议？

以上答案应告知您提交的内容。如果您发现此问题仅在特定情况下发生，请在您的报告中包含此信息。如果问题仍然存在，请提交以下所有内容

  • 用于构建/拉取 Triton 和运行模型的命令或脚本。

    • 如果构建 Triton，请提供您正在构建的版本或分支。

  • 您的模型配置文件。

  • 收到的错误，以及任何日志。

    • 如果您的​​问题涉及服务器崩溃，则转储的回溯将很有帮助。

    • 请启用详细日志记录 (–verbose-log=1) 以获取最详细的日志。

  • 如果此问题是您的模型独有的，请提供您的模型或可重现该问题的玩具模型。

  • 任何其他可以加快我们调查速度的信息。

在本页中