重要说明:

IBM Cloud Pak® for Data 4.8 版本将于 2025 年 7 月 31 日结束支持(EOS)。 欲了解更多信息,请参阅 IBM Cloud Pak for Data 版本 4.X 的停止服务公告
在 版本支持结束之前,升级到 版本。 IBM Cloud Pak for Data 4.8 IBM Software Hub 5.1 有关更多信息,请参阅从 IBM Cloud Pak for Data 版本 4.8 升级到 IBM Software Hub 版本 5.1

Watson Machine Learning 的已知问题和限制

以下已知问题和限制适用于 Watson Machine Learning。

已知问题

限制

Federated Learning 的已知问题

在远程培训系统中指定允许的 IP 时, Federated Learning 培训作业的认证失败

适用于: 4.8.0 和更高版本

当前, Red Hat OpenShift Ingress 控制器未使用客户机的 IP 地址设置 X-Forwarded-For 头,而不考虑 forwardedHeaderPolicy 设置。 如果在远程培训系统中指定了 allowed_ips ,那么这将导致 Federated Learning 培训作业的认证失败,即使客户机 IP 地址正确也是如此。

要使用 Cloud Pak for Data 4.0.3中的 Federated Learning 远程训练系统 IP 限制功能,请配置外部代理以注入 X-Forwarded-For 头。 更多信息,请参阅配置入口的文章

AutoAI 的已知问题

Flight service 在读取大型数据集时返回 "接收到带有错误代码 3 的 RST_STREAM"

适用于: 4.8.0
修订于: 4.8.1

如果使用 Flight service 和 pyarrow 库在 Notebook 中读取 AutoAI 试验中的大型数据集,那么 Flight service 可能会返回以下消息:

Received RST_STREAM with error code 3

发生此错误时, AutoAI 试验会接收不完整的数据,这可能会影响模型候选管道的训练。

如果发生此错误,请将以下代码添加到 Notebook 中:

os.environ['GRPC_EXPERIMENTAL_AUTOFLOWCONTROL'] = 'false'

然后,重新运行试验。

从目录导入 AutoAI Notebook 可能会导致运行时错误

适用于: 4.8.0 和更高版本

如果将 AutoAI 笔记本保存为 IBM Knowledge Catalog ,然后将其导入项目并运行,可能会出现以下错误: Library not compatible or missing

发生此错误的原因是目录中保存的运行时环境与项目中运行 Notebook 所需的运行时环境不匹配。 要解决此问题,请将运行时环境更新为最新的受支持版本。 例如,如果导入的 Notebook 在目录版本中使用 Runtime 22.2 ,请更新到 Runtime 23.1 并再次运行 Notebook 作业。

提示: 更新运行时环境时,请检查您是否具有足够的计算资源。 对于试验笔记本,建议的配置至少为 2 vCPU 和 8GB RAM ,对于管道笔记本,建议的配置至少为 4 vCPU 和 16GB RAM。

运行 AutoAI 管道笔记本生成 TypeError

适用于: 4.8.8 及更高版本

运行 AutoAI 管道笔记本会导致 TypeError ,因为初始化的 CatImputer:

cat_imputer = CatImputer(missing_values=float("nan"), sklearn_version_family="1") 

要解决这个问题,请在初始化程序中添加 strategy="most_frequent” ,然后重新运行单元格:

cat_imputer = CatImputer(strategy="most_frequent", missing_values=float("nan"), sklearn_version_family="1")

Watson Machine Learning 的已知问题

升级或从备份复原后的不可用部署

适用于: 4.8.0 和更高版本

对于在 Cloud Pak for Data 4.6.x上创建的部署,在升级到 Cloud Pak for Data 4.8.x之后,使用部署生成预测可能会失败。 此问题的错误消息为:

Deployment: <deployment-ID> has been suspended due to the deployment owner either not being a member of the deployment space: <space-ID> any more or removed from the system.

从备份复原后也可能发生这些错误。

解决方法是使用以下步骤来更新部署。 必须使用特定于 R Shiny 部署的备用步骤。

要更新部署 (R Shiny 部署除外) ,请执行以下操作:

  1. 对于 HOST="CP4D_HOSTNAME",请将 "CPD_HOSTNAME" 替换为 Cloud Pak for Data 主机名。

  2. 对于 SPACE_ID="WML_SPACE_ID",将 "WML_SPACE_ID" 替换为失败的部署的空间标识。

  3. 对于 DEPLOYMENT_ID="WML_DEPLOYMENT_ID" ,请将 "WML_DEPLOYMENT_ID" 替换为中断部署的部署标识。

  4. 使用 "Authorization: ZenApiKey <token>" 并提供有效令牌。 如果导出环境变量,请使用 ${TOKEN} 而不是 <token>

  5. 使用此 CURL 命令将 "OWNER_ID" 替换为 PATCH 有效内容中此集群上的实际所有者标识。

    curl  -k -X PATCH "$HOST/ml/v4/deployments/$DEPLOYMENT_ID?version=2020-04-20&space_id=$SPACE_ID" -H "content-type: application/json" -H "Authorization: ZenApiKey <token>" --data '[{ "op": "replace", "path": "/metadata/owner", "value": "OWNER_ID" }]'
    
注:

要运行此脚本,必须生成令牌并将其导出为 ${MY_TOKEN} 环境变量。 有关详细信息,请参阅 生成 API 授权令牌

要更新 R-Shiny 部署:

  1. 使用 oc get pods -n NAMESPACE | grep "wml-deployment-manager" 并将 NAMESPACE 替换为 WML Namespace

  2. 对于 oc exec -it WML_DEPLOYMENT_MANAGER_POD_NAME bash -n NAMESPACE,请将 WML_DEPLOYMENT_MANAGER_POD_NAME 替换为上一步中显示的 Deployment Manager pod 名称,并将 NAMESPACE 替换为 Watson Machine Learning 名称空间 `。

  3. 对于 deployment_id="DEPLOYMENT_ID",将 DEPLOYMENT_ID 替换为部署标识。

  4. 对于 space_id="SPACE_ID",请将 SPACE_ID 替换为部署的空间标识。

  5. 对于 HOST="https://wml-deployment-manager-svc.NAMESPACE.svc:16500",将 NAMESPACE 替换为 Watson Machine Learning 名称空间 `。

  6. 使用 "Authorization: ZenApiKey <token>" 并提供有效令牌。 如果导出环境变量,请使用 ${TOKEN} 而不是 <token>

  7. 使用以下 CURL 命令重新创建 R Shiny 部署:

    url -k -X PUT "$HOST/ml/v4_private/recreate_deployment/$deployment_id?version=2020-06-12&space_id=$space_id" -H "Authorization: ZenApiKey <token>"
    
  8. 请验证 R Shiny 部署的状态,并等待该部署变为 "就绪" 状态,然后继续执行下一步。

    curl -k -X GET "$HOST/ml/v4/deployments/$deployment_id?version=2020-06-12&space_id=$space_id" -H "Authorization: ZenApiKey ${MY_TOKEN}"
    
  9. 如果要升级到 Cloud Pak for Data 4.8.0 或从备份复原,请通过 1 从部署空间 UI 扩展副本数。

    缩放部署副本

部署状态将从 "不可用" 更改为 "已部署" 状态。

复原 R Shiny 部署

注:
  1. 您可以选择在部署按预期工作时将副本数缩减回 1 或原始设置。
    2.To 运行此脚本,必须生成令牌并将其导出为 ${MY_TOKEN} 环境变量。 有关详细信息,请参阅 生成 API 授权令牌

Watson Machine Learning 服务中的预测 API 可能过早超时

适用于: 4.8.0 和更高版本

如果 Watson Machine Learning 部署服务中的预测 API (POST /ml/v4/deployments/{deployment_id}/predictions) 超时过快,请遵循以下步骤来手动更新超时时间间隔。

  1. 更新 Watson Machine Learning CR 中的 API 超时参数:

    REQUIRED_TIMEOUT_IN_SECONDS=<timeout-in-seconds>
    NAMESPACE=<wml-instance-namespace>
    oc patch wmlbase wml-cr -p "{\"spec\":{\"wml_api_timeout\": $REQUIRED_TIMEOUT_IN_SECONDS, \"wml_envoy_pods\": 1}}" --type=merge -n "$NAMESPACE"
    

    以下示例显示如何将服务实例名称空间 zen的超时更新为 600 秒:

    REQUIRED_TIMEOUT_IN_SECONDS=600
    NAMESPACE=zen
    oc patch wmlbase wml-cr -p "{\"spec\":{\"wml_api_timeout\": $REQUIRED_TIMEOUT_IN_SECONDS, \"wml_envoy_pods\": 1}}" --type=merge -n "$NAMESPACE"
    
    注:

    如果在 Cloud Pak for Data 集群上禁用了 HPA ,并且您想要增加 Watson Machine Learning 预测 API 请求的吞吐量,那么可以通过在命令中使用 wml_envoy_pods 参数来增加 Watson Machine Learning 特使 pod 的数量。 一个特使 pod 每秒最多可支持 1500 个请求。

  2. 重新启动 NGINX pod:

    oc rollout restart deployment ibm-nginx -n "$NAMESPACE"
    
  3. 检查 NGINX pod 是否出现:

    oc get pods -n "$NAMESPACE" | grep "ibm-nginx"
    

Decision Optimization 部署作业失败,发生错误: "添加部署失败,部署未在时间内完成"

适用于: 4.8.0 和更高版本

如果决策优化部署作业由于以下错误而失败,请完成扩展超时窗口的步骤。

"status": {
     "completed_at": "2022-09-02T02:35:31.711Z",
     "failure": {
         "trace": "0c4c4308935a3c4f2d9987b22139c61c",
         "errors": [{
              "code": "add_deployment_failed_in_runtime",
              "message": "Add deployment failed with deployment not finished within time"
         }]
     },
     "state": "failed"
   }

要在 Deployment Manager 中更新部署超时,请执行以下操作:

  1. 编辑 wmlbase wml-cr 并添加以下行: ignoreForMaintenance: true。 这将 WML 操作员设置为维护模式,停止自动调节。 自动协调将撤销否则应用的任何配置映射更改。

    oc patch wmlbase wml-cr --type merge --patch '{"spec": {"ignoreForMaintenance": true}}' -n <namespace>
    

    例如:

    oc patch wmlbase wml-cr --type merge --patch '{"spec": {"ignoreForMaintenance": true}}' -n zen
    
  2. 捕获 YAML 文件中 wmlruntimemanager configmap 的内容。

    oc get cm wmlruntimemanager -n <namespace> -o yaml > wmlruntimemanager.yaml
    

    例如:

    oc get cm wmlruntimemanager -n zen -o yaml > wmlruntimemanager.yaml
    
  3. 创建 wmlruntimemanager YAML 文件的备份。

    cp wmlruntimemanager.yaml wmlruntimemanager.yaml.bkp
    
  4. 打开 wmlruntimemanager.yaml

    vi wmlruntimemanager.yaml
    
  5. 浏览至文件 runtimeManager.conf 并搜索属性 service

  6. retry_count 字段中增加重试次数以扩展超时窗口:

    service {
    
         jobs {
    
             do {
                 check_deployment_status {
                     retry_count = 420   // Increase the number of retries to extend the timeout window }
                     retry_delay = 1000
                 }
             }
         }
    

    其中:

    • Field retry_count = 重试次数
    • Field retry_delay = 每次重试之间的延迟 (以毫秒计)

    在此示例中,超时配置为 7 分钟 (retry_count * retry_delay = 420 * 1000 = 7 分钟)。 如果要进一步增加超时,可以在 retry_count 字段中增加重试次数。

  7. 应用 Deployment Manager 配置映射更改:

    oc delete -f wmlruntimemanager.yaml
    oc create -f wmlruntimemanager.yaml
    
  8. 重新启动 Deployment Manager pod:

    oc get pods -n <namespace> | grep wml-deployment-manager
    
    oc delete pod <podname> -n <namespace>
    
  9. 等待 Deployment Manager pod 启动:

    oc get pods -n <namespace> | grep wml-deployment-manager
    
注:

如果计划升级 Cloud Pak for Data 群集,则必须在 wml-cr 中将字段 ignoreForMaintenance 设置为 false ,从而使 WML 操作员退出维护模式。

在部署空间中阻止预览掩码数据资产

适用于: 4.8.0 和更高版本

数据资产预览可能失败,并显示以下消息: This asset contains masked data and is not supported for preview in the Deployment Space

部署空间当前不支持屏蔽数据,因此屏蔽资产的预览已被阻止,以防止数据泄露。

具有定制 conda_yml 软件包扩展和 nodefaults 的部署失败

适用于: 4.8.1 和更高版本

固定位置: 4.8.3

如果使用定制 conda_yml 包扩展部署资产或使用 conda env update 子流程调用更新包,那么当 conda channels 限制为 nodedefaults时,部署可能会失败。 变通方法如下:

  • 对于 Cloud Pak for Data V 4.8.3,请使用 conda_yml 包扩展。
  • 对于 4.8.3之前的 Cloud Pak for Data 版本,请使用 conda_yml 包扩展并除去 channelnodefaults 限制。

以下示例显示了限制为 nodefaults的 conda channels :

channels:
  - empty
  - nodefaults

dependencies:
  - pip:
    - langdetect==1.0.9

作为变通方法,除去 channelnodefaults 限制:

channels:
  - empty

dependencies:
  - pip:
    - langdetect==1.0.9

升级后部署运行时 pod 失败

适用于: 4.8.4

如果以 FIPS 方式部署具有压缩软件规范的机器学习模型,那么在升级到 Cloud Pak for Data V 4.8.4之后,运行时 pod 可能会失败。 要了解有关压缩软件规范的更多信息,请参阅 软件规范生命周期

以下代码片段显示在从 Cloud Pak for Data V 4.6.5 升级到 V 4.8.4之后进入 crashloopbackoff 状态的 py39 运行时 pod。

wml-dep-py39-00d7b8ba-e942-4b9e-bf89-3096fb143481-5449b56b9lnrx   1/2     CrashLoopBackOff    4 (22s ago)   2m2s
wml-dep-py39-00d7b8ba-e942-4b9e-bf89-3096fb143481-5d55449f2f8mm   1/2     CrashLoopBackOff    4 (16s ago)   2m2s
wml-dep-py39-2dfb43d1-32ea-46b4-9318-1270a9869e7c-5bd5bb5cmm5jv   1/2     CrashLoopBackOff    4 (34s ago)   2m2s
wml-dep-py39-2dfb43d1-32ea-46b4-9318-1270a9869e7c-ff74c46dztl7r   1/2     CrashLoopBackOff    4 (23s ago)   2m2s
wml-dep-py39-38f88d99-78d2-4c2d-8fb4-e1039d465c5a-75c98ffd5nb4b   1/2     CrashLoopBackOff    4 (31s ago)   2m2s
wml-dep-py39-38f88d99-78d2-4c2d-8fb4-e1039d465c5a-86c8767bmx42v   1/2     CrashLoopBackOff    4 (20s ago)   2m2s
wml-dep-py39-5ac302d4-819a-4c48-8a42-d63d2437e9af-547dc9876jzkn   1/2     CrashLoopBackOff    4 (11s ago)   2m2s
wml-dep-py39-76d51889-cb37-460c-b86f-078b234163e4-7454fd76sgkrm   1/2     CrashLoopBackOff    4 (23s ago)   2m2s
wml-dep-py39-76d51889-cb37-460c-b86f-078b234163e4-775564f7tmntg   1/2     CrashLoopBackOff    4 (21s ago)   2m2s
wml-dep-py39-9409a1c5-02f4-4183-ae87-8025815d01bb-6b89bdc9fkk6g   1/2     CrashLoopBackOff    4 (26s ago)   2m2s
wml-dep-py39-9409a1c5-02f4-4183-ae87-8025815d01bb-6b9559f57b2tm   1/2     CrashLoopBackOff    4 (17s ago)   2m2s
wml-dep-py39-ecd96b96-27d6-4abf-9fe3-9a1f1eff16de-65c66b4cn7gz5   1/2     CrashLoopBackOff    4 (32s ago)   2m2s
wml-dep-py39-ecd96b96-27d6-4abf-9fe3-9a1f1eff16de-795f955f2xtgp   1/2     CrashLoopBackOff    4 (33s ago)   2m1s
wml-dep-py39-f60e182c-627d-468d-a7ca-bfb9387e3ad8-57cbdcb6fhvs2   1/2     CrashLoopBackOff    4 (31s ago)   2m1s
wml-dep-py39-f60e182c-627d-468d-a7ca-bfb9387e3ad8-6d44cfbdqmh8n   1/2     CrashLoopBackOff    4 (22s ago)   2m1s

作为变通方法,必须先升级到 Cloud Pak for Data V 4.6.5 或更高版本,并联系 IBM 支持人员以应用热修订,然后再升级到 Cloud Pak for Data V 4.8.4。

在备份和复原 Cloud Pak for Data之后,从空间导出资产文件失败

适用于: 4.8.4

在 Power (ppc64le) 硬件上运行的集群上发生此问题。

在备份和复原使用 Spectrum Scale 存储器的 Cloud Pak for Data 实例之后,无法从空间导出资产文件。 导出失败,并显示一条消息,指示资产文件 API 无法连接到 RabbitMQ。

要解决此问题,请重新启动 asset-files-api pod:

  1. 设置 API_POD_NAME 环境变量:

    export API_POD_NAME=$(oc get pods -n=${PROJECT_CPD_INST_OPERANDS} | grep "asset-files-api" | awk '{print $1}')
    
    
  2. 重新启动 asset-files-api pod:

    oc delete pod ${API_POD_NAME} -n=${PROJECT_CPC_INST_OPERANDS}
    

Watson Machine Learning 的限制

AutoAI 文件将推送到缺省 Git 项目中的 Git 存储库

在缺省 Git 项目中创建 AutoAI 试验后,创建落实并在可落实的文件列表中查看包含您的试验名称的文件。 在落实中包含此文件不会产生任何后果。 对于使用 Git将文件拉入其本地克隆的任何其他用户, AutoAI 试验将不会显示在资产列表中。 此外,不会阻止其他用户创建同名的 AutoAI 试验。

IBM Z 和 IBM LinuxONE 用户的限制

适用于: 4.8.0 和更高版本

有关功能限制的列表,请参阅 Linux on IBM Z 和 IBM LinuxONE 上的功能

在 S90X 集群上部署模型可能需要重新训练

适用于: 4.8.0 和更高版本

在不同的平台 (例如, x86/ppc ) 上训练 AI 模型,并使用 Watson Machine Learning 在 s390x 上部署 AI 模型,可能会由于发生无序问题而失败。 在这种情况下,请在 s390x 平台上重新训练和部署现有 AI 模型以解决问题。

限制模型部署的大小

适用于: 4.8.0 和更高版本

使用 Watson Machine Learning 部署的模型大小的限制取决于模型框架和类型等因素。 在某些情况下,当您超过阈值时,当您尝试在 Watson Machine Learning 存储库中存储模型时,将收到错误通知,例如: OverflowError: string longer than 2147483647 bytes。 在其他情况下,故障可能由更一般的错误消息 (例如 The service is experiencing some downstream errors, please re-try the requestThere's no available attachment for the targeted asset) 指示。 其中任何结果都指示您已超出该类型部署的允许大小限制。

文件上载的安全性

适用于: 4.8.0 和更高版本

不会验证或扫描通过 Watson Studio 或 Watson Machine Learning UI 上载的文件以查找潜在的恶意内容。 建议您在上载之前对所有文件运行安全软件 (例如防病毒应用程序) ,以确保内容的安全性。

当定制软件规范具有 YML 包扩展时,在 Linux on Power (ppc64le) 平台上执行的带有定制软件规范的 Python 评分函数将失败

适用于: 4.8.0 到 4.8.2
固定于: 4.8.3

使用具有 YML 包扩展的定制软件规范执行 Python 评分函数时,评分调用会返回以下错误: certificate verify failed: unable to get local issuer certificate。`

要解决此问题,请在运行时中显式安装 certifi==2023.5.7 版本。 例如:

%%writefile tmp_custom_env.yml

dependencies:
  - certifi==2023.5.7
  - pip:
    - langdetect==1.0.9

返回: Overwriting tmp_custom_env.yml

AutoAI 试验中的最大特征列数

适用于: 4.8.0 和更高版本

分类或回归试验的最大特征列数为 5000。

不支持使用存储卷连接进行 Cloud Pak for Data 认证

适用于: 4.8.0 和更高版本

不能将存储卷连接与启用为 AutoAI 试验中的数据源的 "Cloud Pak for Data 认证" 选项配合使用。 AutoAI 当前不支持用户认证令牌。 请改为在存储卷连接中禁用 "Cloud Pak for Data 认证" 选项,以将该连接用作 AutoAI 试验中的数据源。

从先前发行版升级后处于 CrashLoopBackoff 状态的部署运行时容器

适用于: 4.8.0 和更高版本

升级 Watson Machine Learning后,某些运行时容器处于 CrashLoopBackoff 状态。

要解决此问题,请修补部署的 RTA。 首先,使用以下命令访存处于 CrashLoopBackoff 状态的部署的 rta-id :

oc get rta -l WML_DEPLOYMENT_ID=<deployment-id>

然后,使用以下命令获取 RTA 的路径:

curl -k -X PUT "https:///v2/runtime_services?uid=&location=urn:ibm:type:cpd" -H "Authorization: ZenApiKey ${MY_TOKEN}" -H "Service-Authorization: Basic $TOKEN" --data-raw '{"id":"<rta-id>","location":{"type":"cpd"},"environment":{"env":["productVersion=4.7.0 "]}}'

联机和批处理部署不支持自动安装存储卷

适用于: 4.8.0 和更高版本

不能将自动安装用于具有 Watson Machine Learning 联机和批处理部署的存储卷。 Watson Machine Learning 不支持此功能用于基于 Python的运行时,包括 R-script , SPSS Modeler, Spark 和 Decision Optimization。 对于具有 Watson Machine Learning 闪亮应用程序部署和 Notebook 运行时的存储卷,只能使用自动安装。

作为一种变通方法,您可以使用数据资产库中的 download 方法 ,该方法是 ibm-watson-machine-learning python 客户端的一部分。

使用大型数据卷作为输入的批处理部署可能会失败

适用于: 4.8.0 和更高版本

如果要对使用大量数据作为输入源的批处理作业进行评分,那么该作业可能会因内部超时设置而失败。 此问题的症状可能是类似于以下示例的错误消息:

Incorrect input data: Flight returned internal error, with message: CDICO9999E: Internal error occurred: Snowflake sQL logged error: JDBC driver internal error: Timeout waiting for the download of #chunk49(Total chunks: 186) retry=0.

如果对批处理部署进行评分时发生超时,那么必须配置数据源查询级别超时限制以处理长时间运行的作业。

数据源的查询级别超时信息如下所示:

有关数据源的查询级别时间限制的信息
数据源 查询级别时间限制 缺省时间限制 修改缺省时间限制
Apache Cassandra 10 秒 在 Apache Cassandra 配置文件或 Apache Cassandra 连接 URL 中设置 read_timeout_in_mswrite_timeout_in_ms 参数,以更改默认时限。
Cloud Object Storage 不适用 不适用
Db2 不适用 设置 QueryTimeout 参数以指定客户机在尝试取消执行并将控制权返回给应用程序之前等待查询执行完成的时间量 (以秒计)。
Hive via Execution Engine for Hadoop 60 分钟 (3600 秒) 在连接 URL 中设置 hive.session.query.timeout 属性,更改默认时限。
Microsoft SQL Server 30 秒 设置 QUERY_TIMEOUT 服务器配置选项以更改缺省时间限制。
MongoDB 30 秒 在查询选项中设置 maxTimeMS 参数以更改缺省时间限制。
MySQL 0 秒 (无缺省时间限制) 在连接 URL 或 JDBC 驱动程序属性中设置 timeout 属性,为查询指定时限。
Oracle 30 秒 在 Oracle JDBC 驱动程序中设置 QUERY_TIMEOUT 参数,以指定查询在自动取消之前可以运行的最大时间量。
PostgreSQL 不适用 设置 queryTimeout 属性以指定查询可以运行的最大时间量。 queryTimeout 属性的缺省值为 0
Snowflake 6 小时 设置 queryTimeout 参数以更改缺省时间限制。

要避免批处理部署失败,请对数据集进行分区或减小其大小。

使用大型内联有效内容的批处理部署作业可能会陷入 startingrunning 状态

适用于: 4.8.0 和更高版本

如果为内联批处理部署提供大型异步有效内容,那么可能会导致运行时管理器进程耗尽堆内存。

在以下示例中, 92 MB 有效内容内联传递到批处理部署,导致堆耗尽内存。

Uncaught error from thread [scoring-runtime-manager-akka.scoring-jobs-dispatcher-35] shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for ActorSystem[scoring-runtime-manager]
java.lang.OutOfMemoryError: Java heap space
	at java.base/java.util.Arrays.copyOf(Arrays.java:3745)
	at java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:172)
	at java.base/java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:538)
	at java.base/java.lang.StringBuilder.append(StringBuilder.java:174)
   ...

这可能导致并发作业陷入 startingrunning 状态。 只有在删除部署并创建新的部署后,才能清除 starting 状态。 可以在不删除部署的情况下清除 running 状态。

作为变通方法,对于提供给批处理部署的巨大有效内容,请使用数据引用而不是内联。

更新 pod 超时限制以管理长时间运行的作业的资源

控制应该回收长时间运行的 pod 以释放资源的频率。

请遵循 Watson Machine Learning 服务中的预测 API 可能过早超时 中描述的步骤,以获取有关停止和启动 pod 的详细信息。 更新 jobs_per_deployment_limitjob_pod_cleanup_check_intervaljob_pod_cleanup_idle_time的参数。

在此示例中,长时间运行的 Decision Optimization 解决方案正在使用 pod 资源。 管理员可以进行干预以回收 Pod。

oc patch wmlbase wml-cr --type=merge  -p '{"spec":[{"jobs_per_deployment_limit": <REQUIRED_TIMEOUT_IN_SECONDS>, "job_pod_cleanup_check_interval": <REQUIRED_TIMEOUT_IN_SECONDS>, "job_pod_cleanup_idle_time": <REQUIRED_TIMEOUT_IN_SECONDS>}]}'  -n <NAMESPACE>

其中:

  • jobs_per_deployment_limit 控制每个部署可以并行运行的最大作业数。 它采用整数作为输入。 缺省值为 2。
  • job_pod_cleanup_check_interval 控制内部调度程序唤醒以检查 Decision Optimization 运行时的空闲 pod 的频率。 它采用整数作为输入。 缺省值为 900 (秒)。
  • job_pod_cleanup_idle_time 控制选择用于回收 pod 的 Decision Optimization 运行时 pod 的最短空闲时间。 这将采用整数作为输入。 缺省值为 120 (分钟)。

在 conda yaml 文件中设置环境变量对于部署不起作用

在 conda yaml 文件中设置环境变量对于部署不起作用。 这意味着在 Watson Machine Learning中部署资产时,无法覆盖现有环境变量,例如 LD_LIBRARY_PATH

作为变通方法,如果您正在使用 Python 函数,请考虑设置缺省参数。 有关详细信息,请参阅 部署 Python 函数

Power 平台上的功能部件工程所需的更多资源

适用于: 4.8.0 到 4.8.2
固定于: 4.8.3

在 Power 平台上使用 16x64 环境训练 AutoAI 试验时,如果您正在使用文本功能部件工程,那么必须禁用文本功能部件工程功能或使用 8x32 AutoAI 环境。

使用 shiny-r3.6 软件规范部署的 R Shiny 应用程序在升级后失败

适用于: 4.8.4 和更高版本

从 Cloud Pak for Data V 4.7.0 升级到 V 4.8.4之后,使用 FIPS 方式针对 x86 体系结构部署的 shiny-r3.6 软件规范部署的 R Shiny 应用程序将失败。 您可能会收到错误消息 Error 502 - Bad Gateway

错误消息示例

作为变通方法,您必须确保 R Shiny 应用程序未使用 shiny-r3.6 软件规范进行部署。 对于使用 shiny-r3.6 软件规范部署的应用程序,必须更新部署以使用最新的软件规范。 有关更多信息,请参阅 管理过时的软件规范或框架。 如果不再需要应用程序部署来释放资源,那么还可以将其删除。

故障诊断

遵循以下提示来解决使用 Watson Machine Learning时可能迂到的常见问题。

AutoAI 试验的训练数据中的类成员不足

AutoAI 试验的训练数据必须至少具有每个类的 4 个成员。 如果训练数据在一个类中的成员数不足,那么您将迂到以下错误:

ERROR: ingesting data Message id: AC10011E. Message: Each class must have at least 4 members. The following classes have too few members: ['T'].

要解决此问题,请更新训练数据以除去类或添加更多成员。

父主题: 中的限制和已知问题 IBM Cloud Pak for Data