华为云用户手册

原因分析 可以从以下角度排查： 请检查CUDA_VISIBLE_DEVI CES 设置的值是否与作业规格匹配。例如您选择4卡规格的作业，实际可用的卡ID为0、1、2、3，但是您在进行cuda相关的运算时，例如"tensor.to(device="cuda:7")"，将张量搬到了7号GPU卡上，超过了实际可用的ID号。 如果cuda相关运算设置的卡ID号在所选规格范围内，但是依旧出现了上述报错。可能是该资源节点中存在GPU卡损坏的情况，导致实际能检测到的卡少于所选规格。

问题现象 在现有镜像基础上，重新装了引擎版本，或者编译了新的CUDA包，出现如下错误： 1.“RuntimeError: cuda runtime error (11) : invalid argument at /pytorch/aten/src/THC/THCCachingHostAllocator.cpp:278” 2.“libcudart.so.9.0 cannot open shared object file no such file or directory” 3.“Make sure the device specification refers to a valid device, The requested device appeares to be a GPU,but CUDA is not enabled”

原因分析 出现该问题的可能原因如下： [Errno 13]Permission denied: '/xxx/xxxx' 上传数据时文件所属与文件权限未修改，导致训练作业以work用户组访问时没有权限了。 在代码目录中的.sh复制到容器之后，需要添加“x”可执行权限。 bash: /bin/ln: Permission denied 因安全问题，不支持用户开通使用In命令。 bash:/home/ma-user/.pip/pip.conf：Permission Denied 因从V1切换到V2时，ma-user的uid仍是1102未改变导致。 tee: /xxx/xxxx: Permission denied cp: cannot stat '': No such file or directory 可能原因是用户使用的启动脚本为旧版本的run_train.sh，脚本里面有某些环境变量在新版本下发的作业中并不存在这些环境变量导致。 可能原因是使用Python file接口并发读写同一文件。

处理方法 对挂载盘的数据加权限，可以改为与训练容器内相同的用户组（1000），假如/nas盘是挂载路径，执行如下代码。 chown -R 1000：1000 /nas 或者 chmod 777 -R /nas 如果是 自定义镜像 中拉取的.sh脚本没有执行权限，可以在自定义脚本启动前执行"chmod +x xxx.sh"添加可执行权限。 ModelArts控制台上创建训练作业自定义镜像入口，默认以1000 uid用户来启动v2容器镜像，将ma-user的uid从1102改为1000，改变方式如下（假若需要sudo权限，可取消sudoers行的注释）： v1训练作业环境变量迁移v2说明： v1的DLS_TASK_NUMBER环境变量，可以使用v2的MA_NUM_HOSTS环境变量替换，即选择的训练节点数。 v1的DLS_TASK_INDEX环境变量，当前可以使用v2的VC_TASK_INDEX环境变量替换，下一步使用MA_TASK_INDEX替换，建议使用demo script中的方式获取，以保证兼容性。 v1的BATCH_CUSTOM0_HOSTS环境变量，可以使用v2的${MA_VJ_NAME}-${MA_TASK_NAME}-0.${MA_VJ_NAME}:6666替换。 一般而言，v1的BATCH_CUSTOM{N}_HOSTS环境变量，可以使用v2的${MA_VJ_NAME}-${MA_TASK_NAME}-{N}.${MA_VJ_NAME}:6666替换。 分析代码中是否存在并发读写同一文件的逻辑，如有则进行修改。 如用户使用多卡的作业，那么可能每张卡都会有同样的读写数据的代码，可参考如下代码修改。 import moxing as mox from mindspore.communication import init, get_rank, get_group_size init() rank_id = get_rank() # 仅让0号卡进行数据下载 if rank_id % 8 == 0: mox.file.copy_parallel('obs://bucket-name/dir1/dir2/', '/cache')

问题现象 训练作业访问挂载的EFS，或者是执行.sh启动脚本时，出现如下错误： OSError: [Errno 13]Permission denied: '/xxx/xxxx' bash: /bin/ln: Permission denied 自定义镜像中，bash:/home/ma-user/.pip/pip.conf：Permission Denied 自定义镜像中，tee: /xxx/xxxx: Permission denied cp: cannot stat '': No such file or directory

处理方法 如果是正常的OOM，就需要修改一些超参，释放一些不需要的tensor。 修改网络参数，比如batch_size、hide_layer、cell_nums等。 释放一些不需要的tensor，使用过的，如下： del tmp_tensor torch.cuda.empty_cache() 必现的问题，使用本地Pycharm远程连接Notebook调试超参。 如果还存在问题，可能需要提工单进行定位，甚至需要隔离节点修复。

问题现象 因为OOM导致的训练作业失败，会有如下几种现象。 错误码返回137，如下图所示。 Modelarts Service Log Trainina end with return code: 137 Modelarts Service Log]handle outputs of training job 日志中有报错，含有“killed”相关字段，例如： RuntimeError: DataLoader worker (pid 38077) is killed by signal: Killed. 日志中有报错“RuntimeError: CUDA out of memory. ”，如下图所示： 图1 错误日志信息 Tensorflow引擎日志中出现“Dst tensor is not initialized”。

处理方法 如果是多个节点复制不同步，并且没有barrier的话导致的超时，可以在复制数据之前，先进行torch.distributed.init_process_group()，然后再根据local_rank()==0去复制数据，之后再调用torch.distributed.barrier()等待所有rank完成复制。具体可参考如下代码： import moxing as mox import torch torch.distributed.init_process_group() if local_rank == 0: mox.file.copy_parallel(src,dst) torch.distributed.barrier()

处理方法 如果是限流问题，日志中还会出现如下报错，OBS相关的错误码解释请参见OBS官方文档，这种情况建议提工单。 [ModelArts Service Log]2021-01-21 11:35:42,178 - file_io.py[line:658] - ERROR: stat:503 errorCode:None errorMessage:None reason:Service Unavailable 如果是client数太多，尤其对于5G以上文件，OBS接口不支持直接调用，需要分多个线程分段复制，目前OBS侧服务端超时时间是30S，可以通过如下设置减少进程数。 # 设置进程数 os.environ['MOX_FILE_LARGE_FILE_TASK_NUM']=1 import moxing as mox # 复制文件 mox.file.copy_parallel(src_url=your_src_dir, dst_url=your_target_dir, threads=0, is_processing=False) 创建训练作业时，可通过环境变量“MOX_FILE_PARTIAL_MAXIMUM_SIZE”设置用户需要分段下载的大文件阈值（单位为Bytes），超过该阈值的文件将使用并发下载模式进行分段下载。

原因分析 出现该问题的可能原因如下。 磁盘空间不足。 分布式作业时，有些节点的docker base size配置未生效，容器内“/”根目录空间未达到50G，只有默认的10GB，导致作业训练失败。 实际存储空间足够，却依旧报错“No Space left on device”。 同一目录下创建较多文件，为了加快文件检索速度，内核会创建一个索引表，短时间内创建较多文件时，会导致索引表达到上限，进而报错。 触发条件和下面的因素有关： 文件名越长，文件数量的上限越小。 blocksize越小，文件数量的上限越小。（ blocksize，系统默认 4096B。总共有三种大小：1024B、2048B、4096B） 创建文件越快，越容易触发。

处理方法 可以参照日志提示"write line error"文档进行修复。 如果是分布式作业有的节点有错误，有的节点正常，建议提工单请求隔离有问题的节点。 如果是触发了欧拉操作系统的限制，有如下建议措施。 分目录处理，减少单个目录文件量。 减慢创建文件的速度。 关闭ext4文件系统的dir_index属性，具体可参考：https://access.redhat.com/solutions/29894，（可能会影响文件检索性能）。

处理方法 针对原因1，需要在代码中补充如下环境变量。 import os os.environ["NCCL_IB_TC"] = "128" os.environ["NCCL_IB_GID_INDEX"] = "3" os.environ["NCCL_IB_TIMEOUT"] = "22" 针对原因2，需要在代码中设置环境变量NCCL_SOCKET_IFNAME。 import os os.environ["NCCL_SOCKET_IFNAME"] = "eth0" 只有当用户的NCCL版本低于2.14时，才需要进行以上设置。

处理方法 按照issues中的说明，应该是环境中的库冲突了，因此在启动脚本最开始之前，添加如下代码。 import os os.system("rm /home/work/anaconda3/lib/libmkldnn.so") os.system("rm /home/work/anaconda3/lib/libmkldnn.so.0") 必现的问题，使用本地Pycharm远程连接Notebook调试。

处理方法 将pretrained改成false，提前下载好预训练模型，加载下载好的预训练模型位置即可，可参考如下代码。 import torch import torchvision.models as models model1 = models.resnet34(pretrained=False, progress=True) checkpoint = '/xxx/resnet34-333f7ec4.pth' state_dict = torch.load(checkpoint) model1.load_state_dict(state_dict) 必现的问题，使用本地Pycharm远程连接Notebook调试。

处理方法 在适配OBS路径后，读取文件模式从‘r’改成‘rb’，然后将mox.file.File的'_write_check_passed'属性值改为‘True’，参考如下代码。 import pandas as pd import moxing as mox mox.file.shift('os', 'mox') # 将os的open操作替换未mox.file.File适配OBS路径的操作 param = {'encoding': 'utf-8'} path = 'xxx.csv' with open(path, 'rb') as f: f._wirte_check_passed = True df = pd.read_csv(ff, **param) 必现的问题，使用本地Pycharm远程连接Notebook调试。

处理方法 尽量代码里不要去修改CUDA_VISIBLE_DEVICES变量，用系统默认里面自带的。 如果必须指定卡ID，需要注意1/2/4规格下，指定的卡ID与实际分配的卡ID不匹配的情况。 如果上述方法还出现了错误，可以去notebook里面调试打印CUDA_VISIBLE_DEVICES变量，或者用以下代码测试，查看结果是否返回的是True。 import torch torch.cuda.is_available()

原因分析 出现该问题的可能原因如下： 程序运行过程中，产生了core文件，core文件占满了"/"根目录空间。 本地数据、文件保存将"/cache"目录3.5T空间用完了。 云上训练磁盘空间一般指如下两个目录的磁盘空间： “/”根目录，是docker中配置项“base size”，默认是10G，云上统一改为50G。 “/cache”目录满了，一般是3.5T存储空间满了，具体规格的空间大小可参见训练环境中不同规格资源“/cache”目录的大小。

检查依赖包是否存在 如果依赖包不存在，您可以使用以下两种方式完成依赖包的安装。 方式一（推荐使用）：在创建我的算法时，需要在“代码目录”下放置相应的文件或安装包。 请根据依赖包的类型，在代码目录下放置对应文件： 依赖包为开源安装包时 在“代码目录”中创建一个命名为“pip-requirements.txt”的文件，并且在文件中写明依赖包的包名及其版本号，格式为“包名==版本号”。 例如，“代码目录”对应的OBS路径下，包含模型文件，同时还存在“pip-requirements.txt”文件。“代码目录”的结构如下所示： |---模型启动文件所在OBS文件夹 |---model.py #模型启动文件。 |---pip-requirements.txt #定义的配置文件，用于指定依赖包的包名及版本号。 “pip-requirements.txt”文件内容如下所示： alembic==0.8.6 bleach==1.4.3 click==6.6 依赖包为whl包时 如果训练后台不支持下载开源安装包或者使用用户编译的whl包时，由于系统无法自动下载并安装，因此需要在“代码目录”放置此whl包，同时创建一个命名为“pip-requirements.txt”的文件，并且在文件中指定此whl包的包名。依赖包必须为“.whl”格式的文件。 例如，“代码目录”对应的OBS路径下，包含模型文件、whl包，同时还存在“pip-requirements.txt”文件。“代码目录”的结构如下所示： |---模型启动文件所在OBS文件夹 |---model.py #模型启动文件。 |---XXX.whl #依赖包。依赖多个时，此处放置多个。 |---pip-requirements.txt #定义的配置文件，用于指定依赖包的包名。 “pip-requirements.txt”文件内容如下所示： numpy-1.15.4-cp36-cp36m-manylinux1_x86_64.whl tensorflow-1.8.0-cp36-cp36m-manylinux1_x86_64.whl 方式二：可以在启动文件添加如下代码安装依赖包： import os os.system('pip install xxx') 方式一在训练作业启动前即可完成相关依赖包的下载与安装，而方式二是运行启动文件过程中进行依赖包的下载与安装。

检查依赖包路径是否能被识别 代码如果在本地运行，需要将“project_dir”加入到PYTHONPATH或者将整个“project_dir”安装到“site-package”中才能运行。但是在ModelArts可以将“project_dir”加入到“sys.path”中解决该问题。 使用from module_dir import module_file来导包，代码结构如下： project_dir |- main.py |- module_dir | |- __init__.py | |- module_file.py

使用自定义镜像创建训练作业时，检查启动文件路径 以OBS路径“obs://obs-bucket/training-test/demo-code”为例，训练代码会被自动下载至训练容器的“${MA_JOB_DIR}/demo-code”目录中，demo-code为OBS存放代码路径的最后一级目录，可以根据实际修改。 使用自定义镜像创建训练作业时，在代码目录下载完成后，镜像的启动命令会被自动执行。启动命令的填写规范如下： 如果训练启动脚本用的是py文件，例如train.py，运行命令可以写为python ${MA_JOB_DIR}/demo-code/train.py。 如果训练启动脚本用的是sh文件，例如main.sh，运行命令可以写为bash ${MA_JOB_DIR}/demo-code/main.sh。 其中demo-code为OBS存放代码路径的最后一级目录，可以根据实际修改。

检查报错的路径是否为OBS路径 使用ModelArts时，用户数据需要存放在自己OBS桶中，但是训练代码运行过程中不能使用OBS路径读取数据。 原因： 训练作业创建成功后，由于在运行容器直连OBS服务进行训练性能很差，系统会自动下载训练数据至运行容器的本地路径。所以，在训练代码中直接使用OBS路径会报错。例如训练代码的OBS路径为obs://bucket-A/training/，训练代码会被自动下载至${MA_JOB_DIR}/training/。 假设训练代码的OBS目录为obs://bucket-A/XXX/{training-project}/，“{training-project}”是存放训练代码的文件夹名称。训练时会自动下载OBS中{training-project}目录下的数据到训练容器的本地路径$MA_JOB_DIR/{training-project}/。 如果报错路径为训练数据路径，需要在以下两个地方完成适配，具体适配方法请参考自定义算法适配章节的输入输出配置部分：

检查报错的路径是否存在 由于用户本地开发的代码需要上传至ModelArts后台，训练代码中涉及到依赖文件的路径时，用户设置有误的场景较多。 推荐通用的解决方案：使用os接口得到依赖文件的绝对路径，避免报错。 示例： |---project_root #代码根目录 |---BootfileDirectory #启动文件所在的目录 |---bootfile.py #启动文件 |---otherfileDirectory #其他依赖文件所在的目录 |---otherfile.py #其他依赖文件 在启动文件中，建议用户参考以下方式获取依赖文件所在路径，即示例中的otherfile_path。 import os current_path = os.path.dirname(os.path.realpath(__file__)) # BootfileDirectory, 启动文件所在的目录 project_root = os.path.dirname(current_path) # 工程的根目录，对应ModelArts训练控制台上设置的代码目录 otherfile_path = os.path.join(project_root, "otherfileDirectory", "otherfile.py")

原因分析 找不到训练输入数据路径，可能是报错的路径填写不正确。用户请按照以下思路进行逐步排查： 检查报错的路径是否为OBS路径 检查报错的路径是否存在 找不到启动文件，可能是训练作业启动命令的路径填写不正确，参考使用自定义镜像创建训练作业时，检查启动文件路径排查解决。 可能为多个进程或者worker读写同一个文件。如果使用了SFS，则考虑是否多个节点同时写同一个文件。分析代码中是否存在多进程写同一文件的情况。建议避免作业中存在多进程，多节点并发读写同一文件的情况。

处理步骤 进入状态“运行失败”的训练作业详情页，单击“日志”页签，查看NCCL报错。 如果出现报错“NCCL timeout”或者“RuntimeError: NCCL communicator was aborted on rank 7”，则表示InfiniBand Verbs超时。单击右侧“重建”，重新创建训练作业，设置环境变量“NCCL_IB_TIMEOUT=22”，提交训练作业后等待作业完成。 如果出现报错“NCCL WARN Bootstrap : no socket interface found”或“NCCL INFO Call to connect returned Connection refused, retrying”，则表示NCCL无法找到通信网卡或者是无法正常访问IP地址。需要排查训练代码中是否有设置NCCL_SOCKET_IFNAME环境变量，该环境变量由系统自动注入，训练代码中无需设置。训练代码去除NCCL_SOCKET_IFNAME环境变量设置逻辑后，单击右侧“重建”，重新创建训练作业，提交训练作业后等待作业完成。 等待训练作业是否变成“已完成”状态。 是，故障处理完成。 否，则联系技术支持排查节点状态。

问题现象 训练作业的状态“运行失败”，查看训练作业的“日志”，存在NCCL的报错，例如“NCCL timeout”、“RuntimeError: NCCL communicator was aborted on rank 7”、“NCCL WARN Bootstrap : no socket interface found”或“NCCL INFO Call to connect returned Connection refused, retrying”。

处理方法 （推荐）解决方案一（按需使用volcano调度器）： CCE页面上修改默认调度器为kube-scheduler。 删除maos-node-agent的pod（重启pod）。 CCE页面上删除节点上的污点A200008。 ModelArts页面上重置节点。 该方案的缺点：用户新建负载时需要手动指定调度器为volcano，参考指导。 解决方案二（默认全部使用volcano调度器）： CCE页面上配置中心修改默认调度器为kube-scheduler。 删除maos-node-agent的pod（重启pod）。 CCE页面上删除节点上的污点A200008。 ModelArts上重置节点。 CCE页面上配置中心修改默认调度器为volcano。 该方案的缺点：后续对ModelArts的节点做相关操作如重置、升级驱动等可能会出现节点异常无法启动的情况。

解决方案 检查用户.ssh配置文件（路径一般在“C:\Users\{User}\.ssh\config”下），检查每组配置文件是否规范：Host必须放在每组配置的第一行，作为每组配置的唯一ID。 如下，第一组配置文件不规范将Host放到最后一行，用户要连的是下面这个Host ModelArts-Note-BmjiN实例，但SSH连到识别的是Host，错误地连到了Host ModelArts-Note-wZc6s这个实例。 按ssh-config的标准写法更新配置，Host这里是每组配置的唯一标识，必填项且必须放在配置文件第一行。 Host ModelArts-notebook-xxx HostName authoring-ssh-modelarts-example.huawei.com Port 31215 User ma-user IdentityFile c:\Users\xxx\KeyPair-xxx.pem StrictHostKeyChecking no UserKnownHostsFile /dev/null ForwardAgent yes

问题现象 VS Code连接开发环境时报错“Connection permission denied (publickey). Please make sure the key file is correctly selected and the file permission is correct. You can view the instance keypair information on ModelArts console.”

解决方案 排查/home/ma-user权限，建议将该目录权限设置为755或750，权限不能过于宽松，以保证用户隔离和安全。修改方法如下。 chomd 755 /home/ma-user chomd 750 /home/ma-user 排查密钥是否是和实例绑定的一致。 停止实例，进入实例详情页。 更新密钥：单击“认证”旁边的编辑按钮，然后单击“立即创建”创建并选择新密钥。 重新使用VS Code连接实例，选择新创建的密钥。

解决方式 先排查cuda和torch版本是否兼容。 # cuda版本 nvcc --version # nvidia-smi版本 nvidia-smi # torch版本（要确定用户用的哪个conda下的python） python -c "import torch;print(torch.__version__)" 通过pytorch官网可查兼容版本：https://pytorch.org/get-started/previous-versions/ 如果环境中装了多版本的cuda，可以排查LD_LIBRARY_PATH中的cuda优先级，需要手动调整下。 举例：如果cuda只兼容cuda-9.1，查询到LD_LIBRARY_PATH=/usr/local/cuda-11.8/lib64:/usr/local/cuda-9.1/lib64 需要手动调整优先级，执行命令export LD_LIBRARY_PATH=/usr/local/cuda-9.1/lib64:$LD_LIBRARY_PATH