在Rails查询上运行ruby时,nginx上游超时错误

时间:2018-10-04 22:27:56

标签: ruby-on-rails nginx puma

在ruby on rails应用程序中,我有一个包含约10,000个条目的表,可以使用不同的参数进行搜索。在dev框上,这可以正常工作,但是在生产框上,我得到一个错误。

2018/10/04 15:46:39 [error] 3418#3418: *6 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.1.5, server: my.site.com, request: "POST /quotes/quoteTable_js HTTP/1.1", upstream: "http://unix:///path/to/app/shared/tmp/sockets/puma.awi_staging.sock/items/itemTable_js", host: "192.168.1.25", referrer: "http://192.168.1.25/items"

我没有设置服务器,所以这里有点深入。我看了以下问题

但是,这些都不起作用,或者我没有正确实现。

我的nginx.conf文件

user nginx;
worker_processes auto;
pid /run/nginx.pid;

events {
    worker_connections 768;
    # multi_accept on;
}

http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

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

    ##
    # SSL Settings
    ##

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

    ##
    # Logging Settings
    ##

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

    ##
    # Gzip Settings
    ##

    gzip on;
    gzip_disable "msie6";

    # gzip_vary on;
    # gzip_proxied any;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # Virtual Host Configs
    ##

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

编辑

大约7秒钟后,我收到“很抱歉,但出了点问题”的提示信息。我尝试增加keepalive_timeout,但没有任何改变。

1 个答案:

答案 0 :(得分:1)

keepalive_timeout参数用于控制将空闲客户端连接保持打开状态的时间,以节省可能的重新连接成本,而这并不是您的问题所在。

对于上游超时,有proxy_connect_timeoutproxy_send_timeoutproxy_read_timeout(nginx默认值为60s,但您的配置文件中的值似乎较低),可以尝试增加后两个,但通常没有人希望服务器响应时间这么长-因为长请求阻塞了工作人员,并且客户端可能开始为所有请求(不仅是“繁重的”请求)超时。