Gunicorn timeout（上）

最近总有用户反馈说Redash下载比较大的Excel就会出现“失败 - 服务器出现问题”，而且每次从点了下载到出现错误提示时间都是差不多的。我先查看了Nginx的error日志，显示 upstream prematurely closed connection while sending to client，第一反应应该是超时导致的。

1. 修改Redash配置

.env文件修改log级别为调试 REDASH_LOG_LEVEL="DEBUG"
.env文件加上超时配置 REDASH_BIGQUERY_HTTP_TIMEOUT=600
Redash的启动命令后面增加 -t 600 参数。

10分钟应该够用了！重启redash进程后，进行尝试试，不好使！好吧，也许是配置参数写错了，那改成 --timeout 600 再试一下，发现还不好使！继续。。。

2. 修改Nginx配置

请求超时：keepalive_timeout、client_header_timeout、client_body_timeout
后端服务器处理请求的时间设置：proxy_connect_timeout、proxy_read_timeout

重启Nginx，下载还是失败！！！看来不是超时导致的了？！

3. 查看进程使用的资源

先执行：
top
再尝试下载操作，发现名叫gunicorn（Redash的server是用gunicorn启动的）的COMMANDCPU占用CPU到了100%，并且持续一定时间后，进程消失，新的进程启动后，CPU占用恢复正常值。那接下来就看看此进程都执行了哪些操作。

4. 进程跟踪

跟踪CPU占用超高的 gunicorn 进程：

$ strace -T -tt -e trace=all -p 进程ID

显式进程一直在 read、write 的系统调用，最后一行输出
+++ killed by SIGKILL +++
后，跟踪就停止了。难道是触发了系统的ulimit限制，然后被系统杀掉了？

5. 设置ulimit参数

设置 gunicorn 运行用户的 ulimit，重新尝试，没有解决。看来也不是这个问题。。。那是被谁 kill 掉的呢？

6. 捕捉kill信号

使用 auditctl，添加捕捉规则：

$ auditctl -a exit,always -F arch=b64 -S kill -F a1=9

进行下载文件操作，等待进程被杀死之后，显式捕捉到结果：

$ ausearch -sc kill

输出：

time->Fri Dec  6 16:13:26 2019
type=PROCTITLE msg=audit(1575620006.444:103711): proctitle=2F6F70742F6D6F64756C65732F7265646173682D372E302E302F7265646173682F62696E2F707974686F6E322E37002F6F70742F7265646173682F7265646173682F62696E2F67756E69636F726E002D62003132372E302E302E313A35303030002D2D6E616D6500726564617368002D770034002D2D6D61782D726571756573
type=OBJ_PID msg=audit(1575620006.444:103711): opid=11646 oauid=0 ouid=1001 oses=14406 ocomm="gunicorn"
type=SYSCALL msg=audit(1575620006.444:103711): arch=c000003e syscall=62 success=yes exit=0 a0=2d7e a1=9 a2=0 a3=0 items=0 ppid=11490 pid=11494 auid=0 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=(none) ses=14406 comm="gunicorn" exe="/opt/modules/redash-7.0.0/redash/bin/python2.7" key=(null)

原来是被父进程搞死了。。。

7. 查看gunicorn日志

进入supervisord控制台，通过tail -f 打印 gunicorn进程的输出。

[CRITICAL] WORKER TIMEOUT (pid:15577)
[INFO] Worker exiting (pid: 15577)
[INFO] Booting worker with pid: 15646

timeout...原因就是最开始猜测的超时问题。

gunicorn 给子进程的执行时间就有30秒，如果超过这个限制就会被父进程kill。可是timeout的超时配置并不生效。。。