Ansible 性能优化（一）：降低工作进程（Worker Process）列表检查频率

（本文基于Ansible 2.7）
在Ansible 源码解析：forks并发机制的实现一文中，我们分析了Ansible工作进程的启动和并发机制，本文不再赘述。

本文主要探讨StrategyBase._queue_task方法中检查TaskQueueManager._workers是否有空闲槽位来容纳新的工作进程的轮询过程。

			while True:
                worker_prc = self._workers[self._cur_worker]
                if worker_prc is None or not worker_prc.is_alive():
                    self._queued_task_cache[(host.name, task._uuid)] = {
                        'host': host,
                        'task': task,
                        'task_vars': task_vars,
                        'play_context': play_context
                    }

                    worker_prc = WorkerProcess(self._final_q, task_vars, host, task, play_context, self._loader, self._variable_manager, shared_loader_obj)
                    self._workers[self._cur_worker] = worker_prc
                    worker_prc.start()
                    display.debug("worker is %d (out of %d available)" % (self._cur_worker + 1, len(self._workers)))
                    queued = True
                self._cur_worker += 1
                if self._cur_worker >= len(self._workers):
                    self._cur_worker = 0
                if queued:
                    break
                elif self._cur_worker == starting_worker:
                    time.sleep(0.0001)

从以上代码可以看到，当一个新的Task因工作进程的数量限制而无法开始执行的时候，_queue_task会每隔0.1ms检查整个workers列表，直到找到空闲的worker进程槽位。这个时间在最新的2.9.0 stable版本中仍然没有修改。

最近我们观察作业的运行过程中发现，如果forks设置小于总的task数量，且单个task的执行时间较长的时候，服务器的CPU消耗从整个play启动时的极速飙升至100%，持续一段时间后缓慢下降，会在50%左右的水平上稳定相当长的时间。我们的服务器是双核心的虚拟机，50%这个数字很容易让我联想到这是一个核心满载了。

我做了个测试，物理CPU至强E5 5649 2.53G hz的虚拟机，启动一个ping task，万兆网络整个工作进程从启动到结果从远端返回，本地进程结束，耗时在1秒+不到2秒的样子。

这也就是说检查的频率是在一个ping task执行时间区间内执行一万次以上。如果task的执行过程更长（比如5分钟），这个轮询检查的频率如此之高就更没有意义——即使能更快地发现空闲的槽位，相对于一个作业执行的时间来说也是九牛一毛，还不如适当降低检查的频率，让CPU可以调度新的play。

目前我们采用的方案是将这个休眠时间调整到0.1秒，收效还不错。加上调整DEFAULT_INRERNAL_POLL_INTERVAL的值（见Ansible 性能优化（二）：调整DEFAULT_INTERNAL_POLL_INTERVAL参数，降低结果处理轮询的频率），workers占满后CPU占用可以降到5%-10%之间，其中us和sy基本上一半一半。