最近有用户反映，Redash下载比较大的Excel时，会出现“失败-服务器问题”，每次点击下载到出现错误提示的时间都差不多时间。我首先检查了Nginx的错误日志，它显示上游在发送给客户端时过早地关闭了连接。第一反应应该是超时引起的。1、修改Redash的configuration.env文件，修改日志级别为debugREDASH_LOG_LEVEL="DEBUG".env文件加上超时配置REDASH_BIGQUERY_HTTP_TIMEOUT=600在Redash的启动命令后添加-t600参数。10分钟应该够了！重启redash进程后试一下，不行！嗯，可能是配置参数写错了，那就改成--timeout600再试试，还是不行！继续。..2、修改Nginx配置请求超时：keepalive_timeout、client_header_timeout、client_body_timeout后台服务器处理请求时间设置：proxy_connect_timeout、proxy_read_timeout重启Nginx，下载还是失败！！！好像不是超时导致的？！3、查看进程使用的资源，先执行：top然后尝试下载。发现名为gunicorn的COMMANDCPU（Redash服务器是用gunicorn启动的）占用了100%的CPU，并在一定时间后，进程消失，新进程启动后，CPU占用率恢复正常值。那我们就来看看这个进程进行了哪些操作。4、进程跟踪跟踪CPU占用率高的gunicorn进程：$strace-T-tt-etrace=all-pprocessID表示该进程一直在读写系统调用，最后一行输出+++killed通过SIGKILL+++，跟踪停止。会不会是系统的ulimitlimit被触发了，然后被系统杀掉了？5.设置ulimit参数设置gunicorn运行用户的ulimit，再试，无解。好像不是这个问题。..谁杀了它？6、捕获kill信号，使用auditctl添加捕获规则：$auditctl-aexit,always-Farch=b64-Skill-Fa1=9下载文件，等待进程被杀死，显式捕获theresult:$ausearch-sckill输出：time->FriDec616:13:262019type=PROCTITLEmsg=audit(1575620006.444:103711):proctitle=2F6F70742F6D6F64756C65732F7265646173682D372E302E302F7265646173682F62696E2F707974686F6E322E37002F6F70742F7265646173682F7265646173682F62696E2F67756E69636F726E002D62003132372E302E302E313A35303030002D2D6E616D6500726564617368002D770034002D2D6D61782D726571756573type=OBJ_PIDmsg=audit(1575620006.444:103711):opid=11646oauid=0ouid=1001oses=14406ocomm="gunicorn"type=SYSCALLmsg=audit(1575620006.444:103711):arch=c000003esyscall=62success=yesexit=0a0=2d7ea1=9a2=0a3=0items=0ppid=11490pid=11494auid=0uid=1001gid=1001euid=1001suid=1001fsuid=1001egid=1001sgid=1001fsgid=1001tty=(none)ses=14406comm="gunicorn"exe="/opt/modules/redash-7.0.0/redash/bin/python2.7"key=(null)被父进程杀死。..7、查看gunicorn日志并进入supervisord控制台，通过tail-f打印gunicorn进程的输出。[CRITICAL]WORKERTIMEOUT(pid:15577)[INFO]Workerexiting(pid:15577)[INFO]Bootingworkerwithpid:15646timeout...原因是最开始猜测的超时问题。gunicorn给子进程的执行时间是30秒。如果超过这个限制，就会被父进程杀死。但是timeout的超时配置不生效。..
