Question

我正在运行Nginx将请求传递给两个瘦服务器。该网站大约90％的时间都在工作，然后每隔一段时间就会变得反应迟钝而且我会收到错误。像这样

2014/11/28 21:40:05 [error] 21516#0: *1458 upstream timed out (110: Connection timed out) while reading response header from upstream, client: X.X.X.X, server: www...com, request: "HEAD / HTTP/1.1", upstream: "http://127.0.0.1:5001/", host: "www.example.com", referrer: "http://www.example.com/"

我在网上搜索解决方案但不幸的是，大多数问题都是在这个问题发生的时候发生的。在这种情况下，它通常意味着Thin只是没有运行。就我而言，我的网站大部分时间都在工作。我可以自己ping瘦服务器。虽然在网站没有响应的情况下我没有试过ping他们。这可能会让我更深入地了解这个问题。

这是我的nginx.conf和sites-available

user www-data;
worker_processes 2;
pid /var/run/nginx.pid;
events {
  worker_connections 768;
  multi_accept on;
}
http {

  sendfile on;
  tcp_nopush on;
  tcp_nodelay on;
  keepalive_timeout 70;
  types_hash_max_size 2048;

  include /etc/nginx/mime.types;
  default_type application/octet-stream;
  client_max_body_size 100M;

  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log;

  gzip on;
  gzip_disable "msie6";

  gzip_static on;

  gzip_comp_level 6;

  gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/octet-stream;

  ssl_session_cache shared:SSL:10m;
  ssl_session_timeout 10m;

  include /etc/nginx/conf.d/*.conf;
  include /etc/nginx/sites-enabled/*;
}

网站启用/默认

map $http_upgrade $connection_upgrade {
 default Upgrade;
 ''      close;
}
upstream example {
  server 127.0.0.1:5000;
  server 127.0.0.1:5001;
}
upstream websocket {
  server 127.0.0.1:5001;
}
server {
  listen 80;
  listen 443 ssl;
  keepalive_timeout 70;
  root /data/example/;
  index index.html index.htm;
  server_name www.example.com;
  ssl_certificate     <PATH>;
  ssl_certificate_key <PATH>;

  location ~ ^/assets/ {
    include /etc/nginx/block.list;
    expires 1d; 
    add_header Cache-Control public;
    add_header ETag ""; 
    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_pass http://example;
  }

  location /websocket {
    include /etc/nginx/block.list;
    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_set_header Host $http_host;
    proxy_redirect off;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_pass http://websocket;
  }

  location / {
    include /etc/nginx/block.list;
    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_set_header Host $http_host;
    proxy_redirect off;

    proxy_pass http://example;
  }
}

我做的最后一件事是删除配置文件中的一些if语句。我不确定这有什么用。从那以后问题一直没有发生，但我认为它已经足够长了。

编辑：问题确实回来了。我回到原点。

if (-f $request_filename/index.html) {
   rewrite (.*) $1/index.html break;
}
if (-f $request_filename.html) {
    rewrite (.*) $1.html break;
}
set $flags ""; 
if (!-f $request_filename) {
    set $flags "${flags}R";
}
if ($flags = "R") {
    proxy_pass http://example;
    break;
}

Answer 1

解决方案结果很简单。这个问题花了我更长的时间才弄明白。

事实证明，Google Compute Engine有一个防火墙规则，可在10分钟后断开空闲的TCP连接。这意味着Thin与数据库的连接正在断开连接。

但是，Thin 不引发超时错误。这使得很难确定Nginx超时的来源。所以也许这是Thin中的一个错误，我不确定，但我确实在Thin配置中设置了一个超时参数。

解决方案本身就是设置keepalive设置以保持TCP连接在空闲时保持活动状态。有关详细信息，请参阅此处：https://cloud.google.com/compute/docs/troubleshooting#communicatewithinternet。

从上游读取响应头时，上行时间使用Nginx，Thin / Rails

1 个答案: