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基本上一半一半。