現在公司使用的airflow排程器很慢，每次clear乙個task之後，這個task要過一段時間才會被排程器排程到，這個時間大約需要15-30s。
使用的airflow版本較老：v1.7.1.3上面這些引數在jobs.py這個檔案裡面都可以看到相關的使用，其中最後乙個refresh_dags_every這個引數在老的版本裡面是寫死在schedulerjob類建構函式裡面的[__init__函式預設傳參]，這裡新加的意思只是把配置寫在airflow.cfg配置檔案裡面，方便之後更改。
在老的版本裡面，schedulerjob類裡面的_excute函式即為排程的主要函式，這個函式做了下面幾件事：
所以，直接去修改max_thread這個引數是可以得到最直接的感受的，把這個引數調整成cpu的個數，可以獲得最大的排程程序的數量，每個程序均分的dags越少，整體時間越快。為什麼是整體時間？
這一段**是把所有可執行的task加入到佇列裡面，外迴圈的條件是只要有乙個程序還存活的話，就進入迴圈，相當於主程序已經在這裡開始join子程序了，在等待所有的程序結束，所以這一段的時間取決於子程序裡面執行時間最長的程序執行的時間。
當我把這個值從預設的2改到8之後，排程的時間已經從15-20s降低到了4-8s，但是沒有直接獲得我想要的4倍的提公升，肯定還有其他的問題。
資料庫問題
這個函式是用來處理pool的併發的，裡面有乙個查詢task state的語句，之前都很快，但是使用過一段時間之後會很慢，檢視資料庫，資料庫包含了很多的歷史資料，並且state這一列也沒有索引，所以導致乙個很簡單的查詢語句使用了1s的時間。這裡的解決辦法是把這一列加上索引，或者說可以讓資料庫裡面只儲存近一年的資料即可。我這裡使用了加索引的辦法，現在的查詢已經下降到了0.003 s左右，提公升了很多。
這個是第一次對開源工具效能調優的嘗試，的確把排程時間優化了很多，現在的每次的排程時間只需要2-3s就可以完成了。
日誌很重要，從日誌裡面可以分析出很多東西。
資料庫的慢查詢需要一定的時間去發現。
官方文件也很重要，從上面可以獲得一些啟示。
stackoverflow上面也有很多的類似的問題，可以先在上面搜尋。
airflow排程安裝
1.安裝gcc yum install gcc y 後續安裝airflow如果不成功，可以再次執行，它會更新包 2.安裝setuptools4.環境配置 安裝依賴的環境 yum y install zlib devel bzip2 devel openssl devel ncurses devel ...
排程工具Airflow
目錄學長之前談過這個排程工具，沒想到還沒過1周，我就被迫使用了。聽同事講了以下，感覺還是不錯的。airflow顧名思義就是工作流的意思 airflow 通過 dag 也即是有向非迴圈圖來定義整個工作流，因而具有非常強大的表達能力。乙個工作流可以用乙個 dag 來表示，在 dag 中將完整得記錄整個工...
排程系統Airflow的第乙個DAG
考慮了很久,要不要記錄airflow相關的東西,應該怎麼記錄.官方文件已經有比較詳細的介紹了,還有各種部落格,我需要有乙份自己的筆記嗎?答案就從本文開始了.本文將從乙個陌生視角開始認知airflow,順帶勾勒出應該如何一步步搭建我們的資料排程系統.現在是9102年9月上旬,airflow最近的乙個版...