Hello!
2013/8/10 赵石:
> hello,我们现在服务器总是出现redis连接不上,并且处于D状态,然后导致nginx也会处于D状态,系统内存飙升,负载飙升,请问这种情况应该怎样解决
>
建议在报告这样的问题时总是提升下列信息:
1. 你使用的相关软件的名称和版本号。例如,Nginx 中可用的非阻塞的 redis 客户端至少就有三种:ngx_redis
模块,ngx_redis2 模块,以及 lua-resty-redis 库。
2. “连接不上”是一个很笼统的描述,你需要说明具体是哪一种连接错误,比如连接超时,或者是连接被重置,等等。一般地,你总是可以在 Nginx
的错误日志文件中看到详细的错误信息。你在报告时也应提供原始的错误日志消息。
3. 你应当提供 Nginx 进程具体的内存使用细节,比如 SHR、VIRT 和 RES 等指标的绝对值以及变化情况。
4. 你应当给出你使用的核心的配置和相关代码。最理想的情况下,是提供一个可以复现问题的最小化的完整用例。
基于你目前已经提供的信息,我有如下建议:
1. 确定你当前的客户端并发数。对于连接超时的情形,在客户端请求速率一定的情况下,由于单位请求的延时增加,会出现并发数快速提高,于是
nginx 同时处理的请求数便快速增加,从而导致内存占用提高。
2. 确定你的 Lua 代码(如果你有使用 Lua 的话,显然你并没有说明)对连接错误进行了恰当的处理,以免误入你并不期望执行的代码路径。
3. D 进程状态说明你的 nginx 进程阻塞在 I/O 操作上面。你可以使用相关的工具确定当前正在执行的系统调用(比如使用 strace
工具),也可以通过 pstack 这样的工具获取当前的用户态调用栈信息。这里一种常见的情形是,你的 nginx
把大量时间花在了刷错误日志文件上面了。由于错误日志的输出总是不带写缓冲的,所以是高代价操作。
4. 你可以使用 Nginx Systemtap Toolkit 中的相关工具对你的 nginx 服务进程进行活体分析,从而可以了解更多的内部工作细节:
https://github.com/agentzh/nginx-systemtap-toolkit
最后,一个好的 bug 报告应当尽可能地包含相关的信息,否则我只能靠猜测,同时给你写一堆的可能情况,显然是吃力不讨好的事情。
Best regards,
-agentzh