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
