默认不快是因为worker_threads默认仅5个，导致结果轮询堆积、event bus过载，加之timeout（5秒）和gather_job_timeout（10秒）过短，易触发超时丢结果。
能并发，但默认不是“完全并行”，需调参数+选对模块才能压满带宽、避免 master 卡住或 minion 超时。
为什么 salt '*' cmd.run 默认不快
默认情况下，salt 命令会启动 worker_threads 个线程（master 配置里默认是 5），每个线程串行处理一批 minion 的返回。上千台机器如果只靠 5 个线程轮询收结果，实际是“伪并发”——命令发得快，但结果回传慢、堆积在 event bus 上，容易触发 minion 端的 timeout 或 master 端的 gather_job_timeout。
-
timeout参数控制的是“等待单个 minion 返回的最长时间”，默认 5 秒，远低于真实网络延迟波动 -
gather_job_timeout控制的是“等待所有 minion 结果汇总的总时间”，默认 10 秒，不够用 - minion 端若负载高或磁盘慢，
cmd.run执行本身也可能卡住，导致超时丢结果
怎么真正并发执行并可靠汇总
关键不是加线程数，而是让 master 能发得出去、收得回来、不丢不重：
- 启动命令时显式加大超时：
salt '*' cmd.run 'uptime' --timeout=60 --gather-job-timeout=120 - 调整 master 配置中
worker_threads到 15–30（视 CPU 核数而定），避免线程争抢；同时增大pub_hwm和ret_port连接队列（防止 ZeroMQ 消息被丢） - 对长耗时命令，改用
cmd.run_bg后台执行 + 异步查状态，避免阻塞主线程 - 用
--out=json或--out=yaml输出结构化数据，方便后续用jq或 Python 解析汇总，别依赖默认的 human-readable 格式 - 避免在命令里嵌套太多 shell 逻辑（比如管道、循环），尽量拆成原子操作，降低单次执行失败概率
输出汇总时容易漏掉哪些 minion
不是所有没返回的 minion 都是“执行失败”，有些只是慢或暂时断连：
- 执行完后用
salt-run jobs.list_jobs查看任务 ID，再用salt-run jobs.lookup_jid <jid></jid>补全缺失结果（前提是 minion 没重启过且 job cache 开启） - 配置
job_cache: True并启用master_job_cache: local_cache（默认已开），否则超时后结果就彻底丢了 - 注意 minion 端的
acceptance_wait_time_max和random_reauth_delay，若网络抖动频繁，可能造成认证延迟，导致部分 minion 拒绝本次 job - 用
salt '*' test.ping --summary先筛一遍存活节点，比直接跑业务命令更稳
真正压到上千台并发时，瓶颈往往不在 Salt 本身，而在 minion 端的系统资源（如 fork 数量限制）、master 的 ZeroMQ socket 队列长度、以及网络中间设备的连接数限制。别只调 worker_threads，先确认 netstat -an | grep :4505 | wc -l 是否接近系统 ulimit。一旦看到大量 TIME_WAIT 或连接拒绝，就得调内核参数了。
