之前线上的服务，最近访问量大了之后，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数。
