之前線上的服務，最近訪問量大了之后，nginx的error日志中大量出現upstream timed out (110: Connection timed out) while reading response header from upstream這種錯誤。
雖然目前為止，問題的根本還是沒有太清楚，但是先記一下自己的排查方法，明天可以繼續排查：
1.這個錯誤是說upstream時候讀取對應的接口服務time out。我第一個想到的就是排查我的接口服務。
接口服務是用tornado實現的，其中還會去訪問其他的接口，訪問接口使用了asynchttpclient，異步訪問。
查資料顯示同步方法requests底層也有連接池，同事使用requests並沒有出現我這種現象。是否是因為程序本身訪問其他接口導致的時間太長的time out呢？
1）我設置了asyncHttpclient的connect_timeout=2s，request_timeout=1s。按照道理來說，最遲3s就一定會返回結果或者返回錯誤。
2）請求超時，我會返回一個空的結果集，因為即使超過了3s，我也會捕捉到異常，返回空結果
以上我覺得不是這塊的問題。
那會不會是其他地方，比如調用mongodb或者aerospike時連接超時呢？
於是，我在prepare方法中加上了開始時間，在finish中計算整個過程所用時間。如果大於2s就打出這條uri的log信息以及耗時。為了檢驗是否可行，我在測試環境中在程序里寫死time.sleep(3)，這樣驗證了這個log記錄方法的可行性。
但是，發現並沒有log日志。那又是為什么呢？？
2.搜索了很多網上方法，都說設置nginx的proxy_read_timeout,proxy_send_timeout和proxy_buffer幾個相關設置的值，設置為60啊150都有。但是這種方法只是延長了響應時間，並不是特別推薦。
3.今天又重新分析了一下問題，發現報錯信息上基本都是一台服務器的問題。因此考慮可能是那台服務器的配置有問題。因為是connection timeout，考慮是否是因為連接數設置問題。
1）ps -aux | grep supervisor，查到supervisor的pid
2）cat /proc/{pid}/limits，發現max open file為1024，這顯然不是我們想要的
3）grep -i file /etc/systemd/system.conf 修改DefaultLimitNOFILE=819200和grep -i file /etc/systemd/user.conf 的DefaultLimitNOFILE=819200
4）重啟supervisor。/etc/init.d/supervisor stop /etc/init.d/supervisor start
5）查看當前啟動的supervisor的limits中max open file數。