在几乎没有任何负载的情况下（可能有几个人每分钟触碰一次服务器），我们有一些超时令我疯狂。
我们使用nginx将非SSLredirect到SSL，终止SSL，然后将请求反向代理到haproxy，将其发送到我们的应用服务器之一。
我们的应用程序服务器运行乘客（导轨）+ nginx。 我们有一个mysql master + slave和一个memcached实例，我们最近开始使用它来进行一些查询。
这是我在nginx错误日志的第一层看到的一个典型错误，它将请求传递给haproxy（详细信息模糊处理）：
2012/02/25 06:42:15 [error] 7838＃0：* 60797上游超时（110：连接超时），从上游读取响应头时，client：1.2.3.4，server：domain.com，request： “GET / api / v1 / some_route HTTP / 1.1”，上游：“ http://127.0.0.1:82/api/v1/some_route ”，主机：“domain.com”
我不确定它是haproxy，乘客+ nginx，rails，memcached。 一个经验数据表明，它们似乎是一堆发生的，也就是说，如果我们有一个超时，我们看到其他几个，那么它们就会消失。
任何帮助将不胜感激。 很高兴发布任何configuration或任何有用的信息。
（它可能是值得一提的，我不是一个nginx的用户，或者实际上是rails，所以这只是初步的猜测，也许是为了回答一些想法而开始的）
从日志条目的详细信息看来，外部请求正在通过nginx在具有主机stringdomain.com的服务器上内部转发到运行在本地主机上的本地haproxy上：
如果是这样的话，那么我真的会把从nginx到haproxy的日志条目关联起来，即在haproxy日志中find相同的请求。
鉴于我不知道nginx所以我猜测，我认为你需要确定这个110消息是否对应于proxy_connect_timeout或proxy_read_timeout ，前者意味着nginx没有得到任何来自haproxy的响应（主机A发送SYN，你的localhost：82丢弃了数据包），后者连接了数据但没有发送任何数据（syn-syn-ack ack，但没有数据stream）。
如果是后者，它的问题可能会进一步回溯到您的Web堆栈中，并且您应该在memcache或mysql日志中查找相同的日志条目。
例如，在mysql上设置缓慢的查询日志my.confconfiguration ，并查看在该日志文件中是否有对应于您的请求的条目。 我想我的默认是在/var/lib/mysql/slow.log，但我想可能是一些自定义。
更一般地说，在这些已经创build了一个相当复杂的系统的平台中，有一些集中的日志logging基础设施来处理事件关联是有帮助的。 我目前正在部署logstash ，出于这样的目的，显然是商业替代scheme的splunk和logblaze。
我遇到了http响应只能部分回到浏览器的问题。 问题是nginx的autocaching。 我已经安装了nginx到一个特殊的目录。 我发现如果我添加了行
在http proxy_cache_path / var / lib / nginx / proxy levels = 1：2 keys_zone = my-cache：8m max_size = 1000m inactive = 600m; proxy_temp_path / var / cache / tmp;
并在位置proxy_cache我的caching; proxy_cache_valid 200 302 60m; proxy_cache_valid 404 1m;
并更改了tmp和proxy目录的权限，然后将整个http响应发送到我的浏览器