ansible执行慢的核心原因是默认配置保守，优化关键在于连接复用、任务精简和调度合理：启用ssh controlpersist、pipelining，调高forks，禁用host_key_checking，缓存或禁用facts收集。
Ansible 执行慢、并发卡顿，核心问题不在“机器不够快”，而在默认配置过于保守，大量时间耗在重复建连、反复认证、冗余收集和串行等待上。优化关键不是堆硬件，而是让连接复用、任务精简、调度合理。
启用 SSH 连接复用（ControlPersist）
每次任务都新建 SSH 连接是最大瓶颈。OpenSSH 5.6+ 支持连接池，可让多任务共享同一 TCP 通道。
- 编辑 /etc/ansible/ansible.cfg，在 [ssh_connection] 段添加：
ssh_args = -C -o ControlMaster=auto -o ControlPersist=600s
control_path = /tmp/ansible-ssh-%%r@%%h:%%p
- ControlPersist=600s 表示空闲连接保持 10 分钟，可根据任务间隔设为 300–3600 秒
- /tmp/ansible-ssh 目录需存在且当前用户可读写：mkdir -p /tmp/ansible-ssh && chmod 700 /tmp/ansible-ssh
- 验证是否生效：执行一次 ansible all -m ping 后，运行 ss -nta | grep :22，应看到多个 ESTABLISHED 连接复用同一 socket
开启 pipelining 并禁用 requiretty
默认模式下，Ansible 把 Python 模块打包上传、解压、执行，I/O 和进程开销极大。pipelining 跳过上传，直接通过 SSH 会话执行字节码。
- 在 /etc/ansible/ansible.cfg 的 [defaults] 段启用：
pipelining = True
- 同时必须在所有被控节点的 /etc/sudoers 中注释掉：# Defaults requiretty
- 若用 root 直连或已配好无密码 sudo，这一步可跳过
合理调高 forks 并关闭首次密钥校验
默认仅 5 路并发，20 台主机要分 4 批跑；首次连接还要等 known_hosts 确认，拖慢整体节奏。
- 在 [defaults] 段设置：
forks = 40
host_key_checking = False
- forks 建议从 30 起测，上限不建议超过控制机 CPU 核数 × 4（如 8 核机器设到 32 即可）
- host_key_checking = False 等效于 -o StrictHostKeyChecking=no，仅跳过交互确认，不影响加密安全
- 生产环境若需合规，可用内网 CA 或 ansible_ssh_common_args 配合可信 HostKeyAlgorithms
缓存 Facts 避免重复收集
每台主机执行 playbook 前默认运行 Gathering Facts，耗时占总执行 20%–40%，尤其在大规模场景下完全是浪费。
- 方案一：全局禁用（适合无需系统信息的简单任务）
在 playbook 顶层加：gather_facts: no - 方案二：启用 JSON 文件缓存（轻量、免依赖）
在 [defaults] 段加：
gathering = smart
fact_caching = jsonfile
fact_caching_connection = /tmp/ansible-facts
并确保目录可写：mkdir -p /tmp/ansible-facts - 方案三：Redis 缓存（适合超大规模、多控制机协同）
需部署 Redis + python-redis 包，配置 fact_caching = redis 及连接参数
