MPICH故障容错与检查点ULFM用户级容错如何实现【免费下载链接】mpichOfficial MPICH Repository项目地址: https://gitcode.com/gh_mirrors/mp/mpich在大规模 HPC 计算中节点崩溃是常态而非例外。MPICH 故障容错功能让你可以在单个进程失败后让 MPI 应用继续运行而不是整体重启。本文将带你了解 MPICH 的两种容错机制ULFMUser Level Fault Management用户级容错与基于 BLCR 的检查点Checkpoint技术并给出可直接上手的配置步骤 什么是 ULFM 用户级容错传统 MPI 程序一旦有一个进程失败整个作业就会跟着终止。MPICH 提供的容错方案改变了这一局面机制工作原理适用场景ULFM 进程容错应用检测到失败进程后用缩小编译器等手段继续运行交互式作业、长时运行任务检查点 / 重启周期性保存进程状态故障后从检查点恢复大规模批处理作业ULFM 的核心思想是把进程是否失败的判断权交给应用程序由用户决定是缩小编译器继续跑还是撤銷通信器退出。官方设计文档见 doc/wiki/design/Fault_Tolerance.md 与操作指南 doc/wiki/how_to/Fault_Tolerance.md。快速启用 MPICH 故障容错的 2 个配置步骤想要用上容错功能编译与运行时各需要一个关键开关编译时开启完整错误检查./configure --enable-error-checkingall这会让 MPICH 在调用 MPI 操作时正确检查通信器状态是容错行为的前提。运行时禁用自动清理mpiexec -n 4 -disable-auto-cleanup ./myappHydra 进程管理器默认会在任何进程异常退出时杀掉整个作业-disable-auto-cleanup正是阻止这一行为的开关。此外还需在应用内把通信器的错误处理器设为MPI_ERRORS_RETURN而非默认的MPI_ERRORS_ABORT这样通信失败会返回错误码而不是终止程序。⚠️ 注意目前容错仅实现于ch3:tcp设备其他网络设备需要额外改造才能正确向上层返回错误。故障是如何被检测和广播的ULFM 的底层依赖 Hydra 进程管理器 PMIProcess Manager Interface的协同工作本地检测Hydra 通过 Unix 机制本地 socket 关闭发现某进程异常退出信号通知Hydra 向各 MPI 进程发送SIGUSR1信号告知有进程死了全组广播通知同时发送给 PMI 服务器广播到所有进程清理资源CH3 进度引擎捕获信号后调用MPIDI_CH3U_Check_for_failed_procs从 PMI 服务器拉取最新失败列表随后关闭失败进程的 VC 连接、清空收发队列并向挂起的请求写入错误码。失败进程列表通过 PMI 属性PMI_dead_processes传递形如1,3-5,11的逗号分隔 rank 列表解析逻辑可见 src/mpi/comm/ulfm_impl.c。5 个实用 API故障之后怎么办MPICH 暴露了一组MPIX_Comm_*扩展接口覆盖了容错的完整生命周期MPIX_Comm_get_failed(comm, failedgrp)返回当前通信器中本地已知的失败进程组——容错的第一步就是先查清楚谁挂了MPIX_Comm_failure_ack(comm)确认失败列表之后的ANY_SOURCE通配接收才会重新启用MPIX_Comm_shrink(comm, newcomm)最有用的一个自动排除失败进程创建新的存活进程通信器应用可以直接切到新通信器继续计算MPIX_Comm_agree(comm, flag)所有存活进程就某个整数值达成一致顺便检测是否存在未确认的新故障MPIX_Comm_revoke(comm)彻底废弃一个通信器阻止后续误用。接口定义位于 src/binding/c/comm_api.txtshrink/agree的核心实现在 src/mpi/comm/ulfm_impl.c 中——例如shrink内部会最多重试 5 次确保所有存活进程对新通信器达成一致见 MPIR_Comm_shrink_impl。官方还附带了完整的容错测试套件位于test/mpi/ft/目录包含 shrink.c模拟 rank 2 退出后 shrink 重建通信器、agree.c、revoke_shrink.c 等 20 多个用例是学习正确用法的最佳范例 MPICH 检查点CheckpointBLCR 保存与恢复除了带伤继续跑另一条路线是定期存档、死后复活。MPICH 借助BLCRBerkeley Lab Checkpoint/Restart实现检查点配置阶段BLCR 不在默认路径时需要显式指定./configure --with-blcr/path/to/blcr运行阶段——两种触发方式任选# 方式一每 3600 秒自动检查点一次 mpiexec -ckpointlib blcr -ckpoint-prefix /tmp/app.ckpoint \ -ckpoint-interval 3600 -f hosts -n 4 ./app # 方式二手动发送 SIGUSR1 信号给 mpiexec 立即触发故障后从第 N 个检查点恢复mpiexec -ckpointlib blcr -ckpoint-prefix /tmp/app.ckpoint -ckpoint-num 2 -n 4 ./app检查点也可用环境变量HYDRA_CKPOINTLIB、HYDRA_CKPOINT_PREFIX、HYDRA_CKPOINT_INTERVAL控制。原理上Hydra 的 proxy 进程在每个节点发起 BLCR 检查点MPI 进程在回调中先执行净空协议发送标记、关闭网络模块保存完成后再恢复网络继续运行——细节见 doc/wiki/design/Checkpointing_implementation.md。 提示BLCR 支持在新版 MPICH 中已被移除使用检查点功能前请确认你使用的版本仍带 BLCR 支持可用mpiexec -info查看 Checkpointing libraries available 一栏。局限性这些坑要先知道容错功能是实验性的使用前三思仅ch3:tcp设备支持完整容错行为故障通知SIGUSR1机制不受官方支持未来版本可能改变集合通信在含失败进程的通信器上可能只在部分进程返回错误——MPI_SUCCESS仅表示该进程自己的部分完成了若MPIX_Comm_shrink连续 5 次重试仍无法收敛说明系统状态已不一致此时应放弃作业并返回错误。总结MPICH 的故障容错 Hydra 检测 PMI 广播 MPIX_Comm_*容错 API 可选BLCR 检查点。配置两个开关、把错误处理器改为MPI_ERRORS_RETURN你的 MPI 应用就能从一损俱损进化为损一不亡 【免费下载链接】mpichOfficial MPICH Repository项目地址: https://gitcode.com/gh_mirrors/mp/mpich创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MPICH故障容错与检查点：ULFM用户级容错如何实现
MPICH故障容错与检查点ULFM用户级容错如何实现【免费下载链接】mpichOfficial MPICH Repository项目地址: https://gitcode.com/gh_mirrors/mp/mpich在大规模 HPC 计算中节点崩溃是常态而非例外。MPICH 故障容错功能让你可以在单个进程失败后让 MPI 应用继续运行而不是整体重启。本文将带你了解 MPICH 的两种容错机制ULFMUser Level Fault Management用户级容错与基于 BLCR 的检查点Checkpoint技术并给出可直接上手的配置步骤 什么是 ULFM 用户级容错传统 MPI 程序一旦有一个进程失败整个作业就会跟着终止。MPICH 提供的容错方案改变了这一局面机制工作原理适用场景ULFM 进程容错应用检测到失败进程后用缩小编译器等手段继续运行交互式作业、长时运行任务检查点 / 重启周期性保存进程状态故障后从检查点恢复大规模批处理作业ULFM 的核心思想是把进程是否失败的判断权交给应用程序由用户决定是缩小编译器继续跑还是撤銷通信器退出。官方设计文档见 doc/wiki/design/Fault_Tolerance.md 与操作指南 doc/wiki/how_to/Fault_Tolerance.md。快速启用 MPICH 故障容错的 2 个配置步骤想要用上容错功能编译与运行时各需要一个关键开关编译时开启完整错误检查./configure --enable-error-checkingall这会让 MPICH 在调用 MPI 操作时正确检查通信器状态是容错行为的前提。运行时禁用自动清理mpiexec -n 4 -disable-auto-cleanup ./myappHydra 进程管理器默认会在任何进程异常退出时杀掉整个作业-disable-auto-cleanup正是阻止这一行为的开关。此外还需在应用内把通信器的错误处理器设为MPI_ERRORS_RETURN而非默认的MPI_ERRORS_ABORT这样通信失败会返回错误码而不是终止程序。⚠️ 注意目前容错仅实现于ch3:tcp设备其他网络设备需要额外改造才能正确向上层返回错误。故障是如何被检测和广播的ULFM 的底层依赖 Hydra 进程管理器 PMIProcess Manager Interface的协同工作本地检测Hydra 通过 Unix 机制本地 socket 关闭发现某进程异常退出信号通知Hydra 向各 MPI 进程发送SIGUSR1信号告知有进程死了全组广播通知同时发送给 PMI 服务器广播到所有进程清理资源CH3 进度引擎捕获信号后调用MPIDI_CH3U_Check_for_failed_procs从 PMI 服务器拉取最新失败列表随后关闭失败进程的 VC 连接、清空收发队列并向挂起的请求写入错误码。失败进程列表通过 PMI 属性PMI_dead_processes传递形如1,3-5,11的逗号分隔 rank 列表解析逻辑可见 src/mpi/comm/ulfm_impl.c。5 个实用 API故障之后怎么办MPICH 暴露了一组MPIX_Comm_*扩展接口覆盖了容错的完整生命周期MPIX_Comm_get_failed(comm, failedgrp)返回当前通信器中本地已知的失败进程组——容错的第一步就是先查清楚谁挂了MPIX_Comm_failure_ack(comm)确认失败列表之后的ANY_SOURCE通配接收才会重新启用MPIX_Comm_shrink(comm, newcomm)最有用的一个自动排除失败进程创建新的存活进程通信器应用可以直接切到新通信器继续计算MPIX_Comm_agree(comm, flag)所有存活进程就某个整数值达成一致顺便检测是否存在未确认的新故障MPIX_Comm_revoke(comm)彻底废弃一个通信器阻止后续误用。接口定义位于 src/binding/c/comm_api.txtshrink/agree的核心实现在 src/mpi/comm/ulfm_impl.c 中——例如shrink内部会最多重试 5 次确保所有存活进程对新通信器达成一致见 MPIR_Comm_shrink_impl。官方还附带了完整的容错测试套件位于test/mpi/ft/目录包含 shrink.c模拟 rank 2 退出后 shrink 重建通信器、agree.c、revoke_shrink.c 等 20 多个用例是学习正确用法的最佳范例 MPICH 检查点CheckpointBLCR 保存与恢复除了带伤继续跑另一条路线是定期存档、死后复活。MPICH 借助BLCRBerkeley Lab Checkpoint/Restart实现检查点配置阶段BLCR 不在默认路径时需要显式指定./configure --with-blcr/path/to/blcr运行阶段——两种触发方式任选# 方式一每 3600 秒自动检查点一次 mpiexec -ckpointlib blcr -ckpoint-prefix /tmp/app.ckpoint \ -ckpoint-interval 3600 -f hosts -n 4 ./app # 方式二手动发送 SIGUSR1 信号给 mpiexec 立即触发故障后从第 N 个检查点恢复mpiexec -ckpointlib blcr -ckpoint-prefix /tmp/app.ckpoint -ckpoint-num 2 -n 4 ./app检查点也可用环境变量HYDRA_CKPOINTLIB、HYDRA_CKPOINT_PREFIX、HYDRA_CKPOINT_INTERVAL控制。原理上Hydra 的 proxy 进程在每个节点发起 BLCR 检查点MPI 进程在回调中先执行净空协议发送标记、关闭网络模块保存完成后再恢复网络继续运行——细节见 doc/wiki/design/Checkpointing_implementation.md。 提示BLCR 支持在新版 MPICH 中已被移除使用检查点功能前请确认你使用的版本仍带 BLCR 支持可用mpiexec -info查看 Checkpointing libraries available 一栏。局限性这些坑要先知道容错功能是实验性的使用前三思仅ch3:tcp设备支持完整容错行为故障通知SIGUSR1机制不受官方支持未来版本可能改变集合通信在含失败进程的通信器上可能只在部分进程返回错误——MPI_SUCCESS仅表示该进程自己的部分完成了若MPIX_Comm_shrink连续 5 次重试仍无法收敛说明系统状态已不一致此时应放弃作业并返回错误。总结MPICH 的故障容错 Hydra 检测 PMI 广播 MPIX_Comm_*容错 API 可选BLCR 检查点。配置两个开关、把错误处理器改为MPI_ERRORS_RETURN你的 MPI 应用就能从一损俱损进化为损一不亡 【免费下载链接】mpichOfficial MPICH Repository项目地址: https://gitcode.com/gh_mirrors/mp/mpich创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考