探测并发化：把「逐台串行」改成「主机间并发」（已完成）¶
主题目录：
parallel_probe_20261007/｜日期：2026-10-07｜类型：C 类（改基类 + 2 个 installer + 主部署器 deploy 阶段） 状态：两轮均已落地并验证。slurm_ins主部署器--dry-run（6 台）：累计单次墙钟 247.7 s → 44.6 s（-82%）；本轮 deploy 阶段 46.4 → 12.3 s（-73%）。
一、背景：为什么"重复归零"之后还有 116 s¶
用日志量化后（2026-10-07，dedupe_v2.txt）：
| 证据 | 数值 | 含义 |
|---|---|---|
| 命令总耗时（6 台之和） | 130.1 s | 若真并行，墙钟应 ≈ 130.1 ÷ 6 ≈ 22 s |
| 实测墙钟 | 115.4 s | 比值 ≈1 → 命令几乎完全串行 |
| 每台首末跨度 | 111.7 – 113.7 s（6 台全部） | 每台被摊开在全程，而非各自跑完 |
| >1 s 空隙 | 0 个 | 不是等待，是排队 |
根因：sync_status_concurrency_20261007/ 只把三个 deployer 的 sync_status 批量化，
而查询大头在 installer 层，它们全是 for host in hosts: self._h._remote_query(host, ...) 的逐台串行形状。
二、第一轮：installer 的 sync()（已落地）¶
- 基类加
_run_per_host(hosts, fn, max_workers=8)（deployer.py）：主机内串行、主机间并发，fn(host)即原来循环体；单台失败即整体失败（抛DeployError，避免探测失败被误判成"无需变更"）。 - 两个 installer 的
sync()并发化（改动极小）：把for host in hosts:换成def _one(host):， 循环体原样不动（缩进都不变），末尾plans[host] = plan→return plan， 方法末尾改为return self._h._run_per_host(hosts, _one)。 node_env_deployer.py（NodeEnvInstaller.sync）module_env_deployer.py（ModuleEnvInstaller.sync）
三、第二轮：deploy 阶段（本轮）¶
关键事实：_remote_query 在 dry-run 下真实执行，而 _remote_exec 在 dry-run 下只记录不执行
（deployer.py 的 _remote_exec 首句即 if self.is_dry_run(): return "DRY_RUN_OK"）。
故 dry-run 里 deploy 阶段的耗时几乎全是只读探测；真跑时同一段代码里探测与写交织，
这正是"含变更动作的 deploy() 不能整体并发"的原因。做法：只把只读探测并发化，写动作保持逐台串行。
改动全部在 slurm_deployer.py，不改变更逻辑：
| 位置 | 原状 | 改后 |
|---|---|---|
_install_packages |
逐包、逐台 rpm -q（N 次连接） |
新增 _probe_missing_packages：一条会话查全部包；_stage_system_prepare 按主机并发探测 |
_ensure_slurm_user |
逐台 id -u |
并发预取（_slurm_user_probe_cmd 单一源），建用户仍串行 |
_stage_manage_hosts |
逐台 sed -n /etc/hosts |
并发预取 |
_ensure_firewall_ports |
逐台 2 次查询 | _probe_firewall 按主机并发 |
_stage_sync_munge_key |
逐台 sha256sum |
并发预取（含收尾 munge 状态） |
_stage_deploy_host |
逐台 _is_install_current（3 次查询） |
deploy() 阶段 7 按主机并发预判 |
_stage_distribute_prolog_scripts / _stage_create_systemd |
逐「文件 × 主机」查 sha256 | _prefetch_file_hashes 批量并发预取（写入与记录顺序不变） |
_stage_stop_old / _stage_symlink_switch |
逐台 systemctl is-active / readlink |
并发预取 |
sha256 命令单一源：新增 _sha256_cmd(path)，_write_remote_file 与批量预取共用同一命令文本——
探测缓存以 host+cmd 为键，两处文本一旦不一致，预取就不命中，等于白做。
四、第三轮：pre_check / sync_status / 其余 installer（本轮）¶
前两轮之后，dry-run 墙钟 44.6 s 的分布是：pre_check 19.5 s、sync_status 13.2 s、deploy 12.0 s。
1. pre_check（19.5 → 5.7 s）：SSH 连通性、HA 存储端口、_check_target_os、_detect_node_specs
四处「逐台串行探测」改 _run_per_host；NodeEnvInstaller.check_targets / ModuleEnvInstaller.check_targets
同样并发化（探测并发、判定仍按原顺序，故首个错误与错误内容都不变）。
2. sync_status（13.2 → 5.2 s；命令数 342 → 206）：node_env / module_env 的 sync() 内，
把 13+ 条只读探测真拼成一段 shell（echo '@@key' 打分隔符、命令照旧、按 KEY 回填），一次往返取回。
⚠️ 关键坑（已留痕）：先试过用
_remote_query_many({host: cmds})合并，实测退化——exec_linux内部是for cmd in commands: conn.run_cmd(cmd)，逐条仍各一次往返， 只省了「建连」（而建连早已被连接池消除）；叠在_run_per_host上还形成双层线程池， 使sync_status命令耗时合计 58.6 → 101.1 s。已回滚。 结论：「合并会话」必须真拼成一条 shell 命令，一次传多条命令不减往返。
3. 其余 installer 的 sync_status() 并发化（各自独立子命令生效）：
scratch_gc（逐文件 _probe_file + _probe_timer）、storage_layout（probe_mount / probe_tier0）、
local_scratch（分三阶段：宿主侧本地 → 节点侧探测并发 → 顺序记录）、
submit_node（_sync_munge / _sync_hosts_entries / _sync_tier1）。
另：health_ensure 与 user_mgmt 的 sync_status 此前已用 _remote_query_many，无需改动。
4. _stage_render_configs：先按同一份判定算出「每台要写哪些文件」，再用 _prefetch_file_hashes
批量并发预取 sha256（判定只在一处，写入与记录顺序不变）。
五、第四轮：deploy 阶段的只读探测拼接（本轮）¶
第三轮之后 dry-run 墙钟 21.0 s 的分布：pre_check 5.7 s、sync_status 5.2 s、deploy 10.2 s。
deploy 段虽已「主机间并发」，但每台仍逐条往返（系统准备 5 组探测 = 5 次往返/台）。
做法：新增 _kv_script / _parse_kv 两个辅助——把 {键: 只读命令} 拼成一段 shell
（逐键先 echo '@@键' 打分隔，再跑该命令），一次往返取回、按键回填。应用点：
| 位置 | 原状 | 改后 |
|---|---|---|
_stage_system_prepare |
缺包 / 建用户 / /etc/hosts / firewalld / munge key 5 组探测、5 次往返/台 |
合并为一次 _run_per_host + 每台一段 shell（6 键）；子方法加 currents / states / hashes 参数接收预取结果 |
_prefetch_file_hashes |
每文件一次往返（_remote_query_many 逐条） |
每台拼一段 shell（N 个 sha256），结果回填 (host, sha256 命令) 缓存键 |
_stage_stop_old |
每个服务一次 is-active |
拼一段（本台要停的服务） |
语义保持：
firewalld未运行时不查端口，改用 shell 条件if [ "$a" = active ]保持同一语义； 判定与记录顺序不变，子方法保留「不传参则自探测」的兼容路径。
效果：墙钟 21.04 → 17.22 s，命令数 206 → 127（-38%）；
deploy 阶段 10.2 → 6.5 s（系统准备 3.15→1.44、分发 Prolog/Epilog 2.47→0.44、生成配置 0.77→0.45）；
变更清单 225/25/200 逐条一致。
⚠️ 首次运行失败并已修正：
_stage_system_prepare误用了node_env/module_envInstaller 类上的_missing_packages_cmd（SlurmDeployer没有该方法）→DeployError: 主机探测失败。 已在SlurmDeployer补同名 staticmethod，并让_probe_missing_packages与它共用同一命令文本（单一源）。
六、第五轮：pre_check 与 sync_status（基类批量接口拼 shell）¶
第四轮后墙钟 17.22 s 的分布：pre_check 5.34 s、sync_status 5.29 s、deploy 6.5 s。
1. _kv_script / _parse_kv 上移到 BaseDeployer：原先只在 SlurmDeployer 上，
installer 与其它 deployer 用不到；上移后成为基类能力（node_env / module_env 的 check_targets 因此可用）。
2. 基类 _remote_query_many 改为「拼一段 shell」：原实现 exec_linux(host, cmds) 逐条 run_cmd
（每条一次往返），改为 exec_linux(host, [整段脚本]) 后一台一次往返。
接口与容错语义不变（返回 {host: [vals]}；失败仍返回 None 且不入缓存），
因此 sync_status 主查询、health_ensure、user_mgmt 等全部调用点同时受益。
3. pre_check：SSH 连通性（echo OK）与 _check_target_os（cat /etc/os-release; uname -m）
每台拼一段 shell 一次往返；_check_target_os 增加 raws 参数接收预取结果。
4. check_targets（node_env / module_env）：本台多条探测拼一段；setsebool 原为
「仅 Enforcing 时才查」，改用 shell 条件 if [ "$(getenforce)" = Enforcing ] 保持同一语义。
效果：墙钟 17.22 → 13.83 s，命令数 127 → 41；
pre_check 5.34 → 3.09 s、sync_status 5.29 → 3.52 s；变更清单 225/25/200 逐条一致。
回归 _remote_query_many 的其它使用者（基类改动的影响面）：
| 子命令 | dry-run 结果 |
|---|---|
--health-ensure |
exit=0，变更 3 / 待执行 0 / 跳过 3 |
--user-mgmt |
exit=0，变更 6 / 待执行 0 / 跳过 6 |
--node-env |
exit=0，变更 60 / 待执行 0 / 跳过 60 |
--module-env |
exit=0，变更 27 / 待执行 0 / 跳过 27 |
七、第六轮：deploy 段再压（阶段 1 / 5 / 7）¶
第五轮后 deploy 阶段 7.2 s 仍为最大头，其子阶段：阶段 7 分发解压 1.64 s、阶段 1 系统准备 1.59 s、
阶段 5 源码编译 1.11 s、阶段 12 systemd 1.05 s。
| 位置 | 原状 | 改后 |
|---|---|---|
_stage_build（阶段 5） |
3 条探测逐条（--version / [ -e ] / cat inputs） |
拼一段 shell 一次往返 |
_is_install_current（阶段 7） |
3~4 条探测逐条 | 同上 |
_installed_packages_cmd（阶段 1，原 _missing_packages_cmd） |
for p in ...; do rpm -q $p; done —— N 次 rpm 进程启动 |
rpm -q --qf '%{NAME}\n' pkg1 pkg2 ... —— 一次查询多包；语义由「输出缺失」改为「输出已装」，调用方求差集 |
效果：墙钟 13.83 → 10.34 s，命令数 41 → 18；
deploy 阶段 7.2 → 4.0 s（系统准备 1.59→0.50、源码编译 1.11→0.29、分发解压 1.64→0.36）；
变更清单 225/25/200 逐条一致。
判据：
rpm -q多包一次查询，未装的包会往 stderr 报错（2>/dev/null吞掉）、已装的照常输出—— 因此可用「输出已装 → 本地求差集」替代 N 次逐包查询。
八、验证结果（六轮）¶
第一轮（installer 并发化）：墙钟 116.1 → 78.9 s（-32%），sync_status 65.5 → 14.6 s。
第二轮（deploy 阶段）：墙钟 80.07 → 44.62 / 44.83 s（两次）。
第三、四轮：逐轮以「变更清单逐条 diff」验收（原始输出见 baseline_stdout.txt / after*_stdout.txt）。
| 指标 | 改前基线 | 第二轮后 | 第三轮后 | 第四轮后 | 第五轮后 | 第六轮后 |
|---|---|---|---|---|---|---|
| 变更记录（总数/待执行/跳过） | 225 / 25 / 200 | 225 / 25 / 200 | 225 / 25 / 200 | 225 / 25 / 200 | 225 / 25 / 200 | 225 / 25 / 200 |
| 变更清单逐条 | — | ✅ 一致 | ✅ 一致 | ✅ 一致 | ✅ 一致 | ✅ 一致 |
远端命令（口径：命令执行完成 行） |
382 | 342 | 206 | 127 | 41 | 18 |
| 可省重复 | 0 | 0 | 0 | 0 | 0 | 0 |
| 建连 | 6 | 6 | 6 | 6 | 6 | 6 |
| 墙钟 | 80.07 s | 44.62 s | 21.04 s | 17.22 s | 13.83 s | 10.34 s |
pre_check |
19.15 s | 19.51 s | 5.65 s | 5.34 s | 3.09 s | 3.15 s |
sync_status |
14.12 s | 13.23 s | 5.20 s | 5.29 s | 3.52 s | 3.38 s |
deploy 阶段 |
46.44 s | 12.33 s | 10.2 s | 6.5 s | 7.2 s | 4.0 s |
命令数的口径在第四轮起变化较大：同一主机的多条命令被拼成一段 shell， 一条
exec_linux只产生一条「命令执行完成」日志——口径仍是"下发的命令条数"，但拼接本身就是在减少这个数。 摊到 6 台，18 条 ≈ 3 次往返/台（pre_check1 +sync_status1 +deploy1 的量级）。
累计（本会话）：247.7 s → 10.3 s（-95.8%），分九次：sync_status 批量化 → 连接复用 →
探测缓存（重复归零）→ installer 并发化 → deploy 阶段探测并发化 → pre_check 并发化 + sync_status 脚本合并 →
deploy 段只读探测拼接 → 基类批量接口拼 shell + pre_check/check_targets 拼接 → deploy 段再压（阶段 1/5/7 拼 shell + rpm -q 多包）。
九、下一步（未做）¶
【2026-10-11 结案：两项均不做】 按 skill
ops-execution-efficiency的停手判据封存：跨阶段合并探测属架构级改动、收益约 2 s 风险高；sub12预取收益约 0.45 s（低于 0.5 s 微调门槛）。结案口径见../efficiency_wrapup_20261011/README.md。
| 靶点 | 现状 | 注意 |
|---|---|---|
deploy（4.0 s）/ sync_status（3.4 s）/ pre_check（3.2 s） |
各段均已到「1 次往返/台」量级（三阶段合计 ≈3 次/台） | 再压需跨阶段合并探测（把三阶段的只读探测一次性预取），属架构级改动，收益约 2 s、风险高 |
单点：sub12（0.92 s，现为 deploy 内最大） |
_stage_create_systemd 预取 + _stage_symlink_switch 的 readlink 各一次/台 |
可给 _stage_symlink_switch 加预取参数，省约 0.45 s |
十、⚠️ 偏差留痕：未做「改前备份」¶
写代码前没有先备份 node_env_deployer.py / module_env_deployer.py（违反「未备份不得执行」）。
第三轮同样未备份 scratch_gc / storage_layout / local_scratch / submit_node 四个 deployer
（详见 backup/README.md 的偏差段）。
事后在 backup/slurm_ins/ 里存的是改后版本。本轮（deploy 阶段）已在改前备份 slurm_deployer.py。
回滚方法（改动小且明确，可手工反向）：
node_env_deployer.py/module_env_deployer.py：把def _one(host: str) -> Dict[str, Any]:改回for host in hosts:，并把return plan+ 空行 +return self._h._run_per_host(hosts, _one)改回plans[host] = plan+return plans。deployer.py：可回滚到dedupe_probe_20261007/backup/slurm_ins/deployer.py.bak.20261007-064700（注意：那会一并丢掉探测缓存）。
教训：改多个文件时应先一次性全部备份，再做编辑。
十一、跨工程推广（共享库能力上移 + lustre_ins）¶
评估（只读，覆盖 ~/Documents 全部部署工程）：共享库同名副本 7 处，但「版本落后」= 0；
k8s_ins/eda_tools_ins/services/* 无同名副本（真走共享库），只有 slurm_ins 与
eda_storage_standardization 是自建副本。按「长期复用 + 有远端多主机只读热点」筛选，
只有 1 个工程值得做：
| 工程 | 判定 |
|---|---|
lustre_ins |
✅ 做：modules/inspector.py 10 个巡检项全是逐台串行只读循环，长期工程 |
k8s_ins/*、eda_tools_ins/* |
❌ 目录带日期戳、无文档 = 一次性归档工程 |
kvm_*、samba_ins |
❌ 单机本地 subprocess，无远端多主机热点 |
services/harbor |
❌ 已自带「一次会话取全 + 并发」 |
1. 共享库上移（~/py_public_modules/base_module.py，纯新增）：
run_per_host(hosts, fn)（主机间并发）、_kv_script({键: 命令}) 与 _parse_kv(输出, 键)
（拼一段 shell 并按键回填）。不改 run_batch——它的返回类型是 List[CommandResult]，
改成拼 shell 会破坏所有调用方；仅在 docstring 注明「它逐条下发，省的是建连不是往返」。
回归：py_compile + 23/23 挂载 venv 导入通过 + 三个新方法自检。
2. lustre_ins 改造（modules/inspector.py，10 个方法）：
| 手法 | 应用处 |
|---|---|
run_per_host（主机间并发） |
1 SSH+时间、2 LNet、3 target 在线、4 容量、5 客户端挂载、6 lctl 参数、8 防火墙、9 fstab、10 系统资源、11 RPM 包 |
_kv_script（同台拼一段 shell） |
1（hostname+date / chrony）、9（同台多路径 fstab）、10（loadavg / nproc / free） |
rpm -q 多包一次 |
11（原逐包 is_rpm_installed） |
效果：inspect 墙钟 59.65 → 8.33 s（-86%）；巡检报告 459 行逐行一致（仅时间戳不同）；
py_compile 通过、巡检状态 success。
保持语义的细节：同一 host 在配置里出现多次时（多角色 / 多条目），探测按 host 去重后并发，
但判定仍按原顺序逐条进行（_check_lnet / _check_client_mount 取首次出现的 nid / 挂载点）；
fstab 的「缺 nofail」判据由「原用 grep 退出码」改为「输出非空」——对同一命令两者等价。
十二、备份¶
见 backup/README.md（台账）：slurm_deployer.py.bak.20261007-071159 为本轮改前快照；
{deployer,node_env_deployer,module_env_deployer}.py.bak.20261007-070814 为上一轮改后快照。
来源：
/home/rain/Documents/slurm/slurm_ins/parallel_probe_20261007/README.md｜ 最后更新：2026-10-11 21:15（由build/sync.py同步，请勿在站点侧修改）