最近总有用户反馈说Redash下载比较大的Excel就会出现“失败 - 服务器出现问题”,并且每次从点了下载到出现错误提示时间都是差很少的。我先查看了Nginx的error日志,显示 upstream prematurely closed connection while sending to client
,第一反应应该是超时致使的。python
REDASH_LOG_LEVEL="DEBUG"
REDASH_BIGQUERY_HTTP_TIMEOUT=600
-t 600
参数。10分钟应该够用了!重启redash进程后,进行尝试试,很差使!好吧,也许是配置参数写错了,那改为 --timeout 600
再试一下,发现还很差使!继续。。。后端
重启Nginx,下载仍是失败!!!看来不是超时致使的了?!服务器
先执行:top
再尝试下载操做,发现名叫gunicorn
(Redash的server是用gunicorn启动的)的COMMAND
CPU占用CPU到了100%,而且持续必定时间后,进程消失,新的进程启动后,CPU占用恢复正常值。那接下来就看看此进程都执行了哪些操做。python2.7
跟踪CPU占用超高的 gunicorn
进程:ui
$ strace -T -tt -e trace=all -p 进程ID
显式进程一直在 read
、write
的系统调用,最后一行输出+++ killed by SIGKILL +++
后,跟踪就中止了。难道是触发了系统的ulimit
限制,而后被系统杀掉了?调试
设置 gunicorn
运行用户的 ulimit
,从新尝试,没有解决。看来也不是这个问题。。。那是被谁 kill
掉的呢?日志
使用 auditctl
,添加捕捉规则:code
$ auditctl -a exit,always -F arch=b64 -S kill -F a1=9
进行下载文件操做,等待进程被杀死以后,显式捕捉到结果:server
$ 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)
原来是被父进程搞死了。。。
进入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的超时配置并不生效。。。