Optuna 试验被意外杀死后卡在 RUNNING 状态怎么用 heartbeat 机制自动标记失败

Optuna 试验被意外杀死后卡在 RUNNING 状态怎么用 heartbeat 机制自动标记失败【免费下载链接】optunaA hyperparameter optimization framework项目地址: https://gitcode.com/GitHub_Trending/op/optuna在集群环境里跑 Optuna 优化时一个常见问题是正在执行某个 trial 的进程被任务调度器或外部条件意外杀死而 storage 里这个 trial 的状态会一直停留在RUNNING直到你手动删除或更新它的状态。Optuna 针对这种情况提供了 heartbeat心跳机制只要用支持心跳的RDBStorage并开启heartbeat_interval当一个进程死亡后该进程上正在运行的 trial 会在心跳超时后自动从RUNNING变为FAIL。本文说明如何配置这一机制、如何验证它生效以及在ask/tell工作流下该怎么处理。前置条件哪些存储和工作流支持 heartbeat必须使用支持 heartbeat 的存储后端。文档中明确给出的是 RDBStorageoptuna/storages/_rdb/storage.pyInMemoryStorage、JournalStorage等没有该能力。heartbeat 机制标注为 experimentalAPI 未来可能变化FAQ 与RDBStorage文档字符串中都有此说明。心跳机制设计上配合Study.optimize使用。FAQ 明确警告如果你用的是Study.ask和Study.tell心跳自动标记失效需要自己显式调用study.tell更新状态见下文ask/tell 工作流下的替代做法。FAQ 另有一条相关提示文档不推荐用 SQLite3 做并行优化可参考 docs/source/faq.rst 中sqlite_concurrency一节如果确实要在多进程间共享存储FAQ 建议考虑JournalFileBackend等替代方案但这与 heartbeat 机制不兼容heartbeat 只在 RDB 后端上工作。配置方法开启 heartbeat 的 RDBStorageheartbeat 有三个相关参数都在RDBStorage的构造参数里参数含义来自 optuna/storages/_rdb/storage.py 的文档字符串heartbeat_interval心跳记录间隔秒必须是正整数None表示不启用grace_period最后一次心跳之后经过多少秒才把仍在运行的 trial 判为失败stale。必须是正整数或None为None时取2 * heartbeat_intervalheartbeat_stale_trial_callback可选回调在每个stale trial 被标记失败之后被调用签名是(study: optuna.study.Study, trial: FrozenTrial) - None。文档说明该检查流程发生在一个新 trial 被 ask 出来之前也就是下一轮 trial 启动时才处理上一轮的僵尸 trial。FAQ 给出的最小可用示例sqlite:///:memory:仅用于演示实际使用时替换为你自己的数据库 URLimport optuna def objective(trial): (Very time-consuming computation) # 这里放你真实的目标函数计算 # Recording heartbeats every 60 seconds. # Other processes trials where more than 120 seconds have passed # since the last heartbeat was recorded will be automatically failed. storage optuna.storages.RDBStorage(urlsqlite:///:memory:, heartbeat_interval60, grace_period120) study optuna.create_study(storagestorage) study.optimize(objective, n_trials100)也就是说心跳每 60 秒记录一次如果某个其他进程上的 trial 超过 120 秒没有新心跳就会被自动失败化。执行后如何验证判断依据是文档描述的状态迁移被杀死进程的 trial 会从TrialState.RUNNING变为TrialState.FAIL。你可以用study.get_trials(states[optuna.trial.TrialState.RUNNING])查看仍标记为运行的 trial——进程被杀且超过grace_period之后再次进入优化循环新 trial 启动时触发 stale 检查再查僵尸 trial 不应再出现在RUNNING列表中而应在FAIL状态里。内部实现上study.optimize在每轮 trial 前会调用optuna.storages.fail_stale_trials(study)见 optuna/study/_optimize.py 与 optuna/storages/_heartbeat.py 中fail_stale_trials的实现它把所有心跳超时的运行中 trial 置为FAIL然后触发你注册的失败回调。因此新 trial 启动是触发时机如果你杀掉了唯一在跑的进程但优化循环不再继续stale 检查也不会再执行。可选增强自动重试被标记失败的 trial如果僵尸 trial 被失败化后你希望自动重跑而不是仅仅留下一个FAIL记录可以在RDBStorage上挂 RetryHeartbeatStaleTrialCallback。FAQ 给出的示例import optuna from optuna.storages import RetryHeartbeatStaleTrialCallback storage optuna.storages.RDBStorage( urlsqlite:///:memory:, heartbeat_interval60, grace_period120, heartbeat_stale_trial_callbackRetryHeartbeatStaleTrialCallback(max_retry3), ) study optuna.create_study(storagestorage)该回调的作用是把 stale trial 重新创建为TrialState.WAITING排入队列再跑一次文档描述其适用于 worker 被抢占、进程意外退出等外部条件导致 trial 变 stale 的环境。几个可用细节max_retry最多重试次数None默认表示无限重试设为整数则只重试该次数inherit_intermediate_values重试的新 trial 是否继承原 trial 通过trial.report上报的intermediate_values默认False原 trial 与重试 trial 的对应关系可通过RetryHeartbeatStaleTrialCallback.retried_trial_number(trial)取到原始 trial 编号retry_history(trial)取到完整的重试链列表含原始 trial 编号。注意文档说明回调是在每个新 trial 开始评估时检查并处理 stale trial所以重试同样依赖优化循环继续运行。ask/tell 工作流下的替代做法如上所述heartbeat 只对optimize生效。FAQ 给出了ask/tell场景下手动处理僵尸 trial 的示例原文说明该示例中的grace_period需要用户按自身场景调整例子里假设运行超过 1 天大概可视为僵尸from datetime import datetime import optuna study optuna.create_study(storage...) # 替换为你的 storage # User needs to tweak here. For example, the case below assumes that if trial is running # for 1 day, this trial is probably a zombie. grace_period 3600*24 for t in study.get_trials(states[optuna.trial.TrialState.RUNNING]): if (datetime.now() - t.datetime_start).total_seconds() grace_period: study.tell(t, stateoptuna.trial.TrialState.FAIL)限制与已知边界heartbeat 机制是 experimental 的FAQ 和RDBStorage参数文档都提示 API 可能变化。RDBStorage还有一个旧参数failed_trial_callback在 v4.9.0 起被弃用、计划在 v6.0.0 移除文档明确要求改用heartbeat_stale_trial_callback两个参数同时传会直接抛ValueError。心跳只解决检测并标记不会恢复被杀 trial 的现场需要恢复中间值时只能依赖RetryHeartbeatStaleTrialCallback的inherit_intermediate_values且前提是原 trial 已经通过trial.report上报过 intermediate values。自动标记的触发点是下一次有新 trial 被 ask 出来时optimize循环内部因此它不是独立的后台巡检进程优化循环停止后不会再有自动状态更新。相关文档入口FAQ heartbeat 监控一节、optuna.storages API 参考、RDBStorage 实现、心跳实现、重试回调实现。【免费下载链接】optunaA hyperparameter optimization framework项目地址: https://gitcode.com/GitHub_Trending/op/optuna创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考