我是公司的一塊磚，哪裏需要往哪搬。如果研發人不足，數據也可做後端。
數據組老大離職，一堆數據接口代碼等待人來接管，我天天祈求這些代碼不要出問題，然後美夢就成真了，今天，其中一個提供關鍵詞的接口慢的一批.
恰逢此時，領導在我背後拍了拍我的肩膀，有爲啊，這個問題就交給你來處理了吧，你可從來沒讓我失望過啊！
當時，在下的心情比吃了七斤二兩新鮮的熱翔還要難受，鼓勵我做事（曬甩事情）的話你都說，鼓勵我做事（加薪）的事你不做，我給你說個錘子。
狠話雖然這樣說，但是還是要恰飯的，爲了這口飯，在下只好忍氣吞聲，臥薪藏膽，悄悄咪咪的劇情情況。
cat 8000_supervisor_runtime.log | grep keyword
看supervisor的日誌，響應時間搞到100多萬ms的都有，看完之後我慌得一批.
cat /var/log/nginx/access.log | grep keyword
然後去看nginx日誌，幾乎全是清一色的499。
百度了下nginx 499的說明，client has closed connection，客戶端關閉了連接，順帶了還看了下解決方法，修改nginx配置**proxy_ignore_client_abort on;**表示代理服務端不要主要主動關閉客戶端連接。
照着修改之後，依然沒有任何改觀，讓後在下就裂開了，真的是能力有限啊，是在搞不定啊。
比對了測試環境和生產環境，測試環境響應都在1s一下，而且接口代碼邏輯也相當簡單，就是查詢數據庫，然後調用下相關模型，返回最匹配的關鍵詞。
同樣的代碼，同樣的邏輯，就連查詢的數據庫都是一樣的，爲什麼差別會這麼大，我當場就蒙了，。
&emspl;思前想後，在線感覺無非就是兩個問題。
1、nginx的問題
會不會是請求數過多，nginx吃不消了，但是在下馬上就否定了自己的想法，如果nginx的問題，其他的接口肯定也會出問題，但是當時的情況是各別接口慢，其他接口快的飛起，所以nginx問題排除。
2、代碼的問題
最開始，我是不想承認代碼的問題的，因爲代碼自從組長離職一個月期間，一直沒有出過類似的問題，但是當時處於特殊情況，只要是其中給一個影響因素，我就不得不懷疑。既然是接口響應慢，我乾脆就把接口的代碼邏輯全部斃掉，如果接口響應時間變短了，那麼就是代碼的問題。
註釋掉所有業務邏輯代碼，直接返回值，接口響應時長立馬從100萬ms降到0.2ms，我特麼當時就驚了，代碼是不會騙人的，但是爲什麼這麼簡單的代碼，會出這麼大的問題，我就有點難懂了。
代碼最核心的邏輯，是從數據庫查詢數據，莫非是這裏除了問題，突然間在下恍然大悟，代碼沒問題，nginx沒問題，真正有問題的其實是數據庫的問題。數據庫連接池被佔滿了
查詢一下PG的連接情況，一共有180多個連接（tornado異步連接池最大的連接數是120），這180多個連接一直沒有被釋放，而且還有增加的趨勢，所以導致了我那個接口查詢數據的時候，一直被堵塞在哪裏。
SELECT
query
FROM
pg_stat_activity
WHERE
STATE = 'active'
查詢具體的查詢語句，發現這些語句都特麼慢的一批，而且語句都來源於同一個接口，經過排查，發現這些SQL是老版本的關鍵詞推薦的代碼，完全可以用新版本替代（fuck老版本兼容）修改一下代碼函數調用，重啓supervisor，監控一下PG的連接數，瞬間降到10以下，所有的接口全部快的飛起，這個世界一下就變得美好了。