本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
对亚马逊SageMaker模型部署进行故障排除
如果您在亚马逊部署机器学习模型时遇到问题SageMaker,请参阅以下指南。
活动 CPU 计数中的检测错误
如果您使用 Linux Java 虚拟机 (JVM) 部署SageMaker模型,则可能会遇到阻止使用可用的 CPU 资源的检测错误。此问题会影响支持 Java 8 和 Java 9 的某些 JVM 以及支持 Java 10 和 Java 11 的多数 JVM。这些 JVM 实现了一种机制,用于检测和处理 CPU 计数和在 Docker 容器中运行模型时的最大可用内存,更笼统地说,在 Linux taskset
命令或控制组 (cgroup) 中运行模型时。SageMaker部署利用了 JVM 用于管理这些资源的某些设置。目前,这会导致容器错误地检测可用 CPU 数。
SageMaker 不限制对实例上 CPU 的访问。但是,当有更多 CPU 可供容器使用时,JVM 可能会将 CPU 计数检测为 1
。因此,JVM 会将其所有内部设置调整为像只有 1
个 CPU 内核可用时运行一样。这些设置会影响垃圾回收、锁定、编译器线程及其他 JVM 内部组件,从而对容器的并发性、吞吐量和延迟产生负面影响。
要查看这一误检测的示例,请在为 SageMaker 配置的容器(它是使用基于 Java8_191 的 JVM 进行部署的,在实例上具有四个可用 CPU)中,运行以下命令以启动 JVM:
java -XX:+UnlockDiagnosticVMOptions -XX:+PrintActiveCpus -version
这会生成以下输出:
active_processor_count: sched_getaffinity processor count: 4 active_processor_count: determined by OSContainer: 1 active_processor_count: sched_getaffinity processor count: 4 active_processor_count: determined by OSContainer: 1 active_processor_count: sched_getaffinity processor count: 4 active_processor_count: determined by OSContainer: 1 active_processor_count: sched_getaffinity processor count: 4 active_processor_count: determined by OSContainer: 1 openjdk version "1.8.0_191" OpenJDK Runtime Environment (build 1.8.0_191-8u191-b12-2ubuntu0.16.04.1-b12) OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
受此问题影响的许多 JVM 选择禁用此行为,并重新建立对实例上所有 CPU 的完全访问权限。通过在启动 Java 应用程序时包含 -XX:-UseContainerSupport
参数,禁用这一不需要的行为并建立对所有实例 CPU 的完全访问权限。例如,按如下所示运行 java
命令以启动 JVM:
java -XX:-UseContainerSupport -XX:+UnlockDiagnosticVMOptions -XX:+PrintActiveCpus -version
这会生成以下输出:
active_processor_count: sched_getaffinity processor count: 4 active_processor_count: sched_getaffinity processor count: 4 active_processor_count: sched_getaffinity processor count: 4 active_processor_count: sched_getaffinity processor count: 4 openjdk version "1.8.0_191" OpenJDK Runtime Environment (build 1.8.0_191-8u191-b12-2ubuntu0.16.04.1-b12) OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
检查容器中使用的 JVM 是否支持 -XX:-UseContainerSupport
参数。如果支持,则在您启动 JVM 时,始终会传递该参数。这会提供对实例中所有 CPU 的访问权限。
当在 SageMaker 容器中间接使用 JVM 时,您也可能会遇到此问题。例如,使用 JVM 支持 SparkML Scala 时。-XX:-UseContainerSupport
参数也会影响 Java Runtime.getRuntime().availableProcessors()
API 返回的输出。
部署 model.tar.gz 文件时出现问题
当你使用model.tar.gz
文件部署模型时,模型压缩包不应包含任何符号链接。符号链接会导致模型创建失败。此外,我们建议您不要在压缩包中包含任何不必要的文件。
主容器未通过 ping 运行状况检查
如果您的主容器未通过 ping 运行状况检查并显示以下错误消息,则表明您的容器或脚本存在问题:
The primary container for production variant beta did not pass the ping health check. Please check CloudWatch Logs logs for this endpoint.
要解决此问题,您应检查相关端点的日志日CloudWatch志,以查看是否存在任何阻止容器响应或的错误/ping
或问题/invocations
。日志可能会提供可能指向问题的错误消息。一旦确定了错误和失败原因,就应该解决错误。
在创建端点之前在本地测试模型部署也是一种很好的做法。
-
在 SageMaker SDK 中使用本地模式,通过将模型部署到本地端点来模仿托管环境。有关更多信息,请参阅本地模式
。 -
使用原版 docker 命令测试容器对 /ping 和 /invocations 的响应。有关更多信息,请参阅 local_test
。