V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
NGINX
NGINX Trac
3rd Party Modules
Security Advisories
CHANGES
OpenResty
ngx_lua
Tengine
在线学习资源
NGINX 开发从入门到精通
NGINX Modules
ngx_echo
Livid
V2EX  ›  NGINX

关于 NGINX 的 upstream 配置的 fail_timeout=0 参数的意义

  •  2
     
  •   Livid · 2016-12-23 16:54:53 +08:00 · 15147 次点击
    这是一个创建于 2929 天前的主题,其中的信息可能已经有所发展或是发生改变。

    今天在下面的这个 NGINX 例子配置文件里里看到一个有意思的观点,就是如果后端是一个动态程序,那么 upstream 的 fail_timeout 应该设置为 0 :

    https://bogomips.org/unicorn/examples/nginx.conf

    upstream app_server {
      ...
      server 192.168.0.7:8080 fail_timeout=0;
      ...
    }
    

    fail_timeout 的默认值是 10 秒,配合默认值为 1 的 max_fails 参数,意思是如果在 fail_timeout 期间后端失败了 max_fails 次,那么就将这个后端标识为不可用,在接下来的 fail_timeout 期间, NGINX 不会再将请求分配到这个后端。

    如果将 fail_timeout 设置为 0 ,那么无论后端失败了多少次, NGINX 会继续把请求分发到这个后端服务器地址。

    如果后端是一个动态程序,比如 Python 或者 Node.js ,那么就应该将 fail_timeout 设置为 0 ,这样即使后端偶尔抛出一个 500 错误,那么也不应该暂停服务。在动态应用中,出现偶尔的 500 错误是很正常而且几乎无法避免的。如果后端因为某些更严重的原因一直出现 500 错误,那么这种问题其实也是任何 NGINX 配置都解救不了的。

    fail_timeout 设置为 10 秒或者更长时间,可能对于静态的后端会更有意义。因为静态的后端通常很难出现 500 错误。如果出错了,一般也都是因为一些更麻烦的问题,比如硬盘坏了,或者内存满了之类,这种时候通过 fail_timeout 的值来暂时避免将请求发送到有问题的静态后端,是有意义的。

    15 条回复    2017-07-25 10:14:13 +08:00
    ctsed
        1
    ctsed  
       2016-12-23 16:58:39 +08:00 via iPhone
    动态程序也可能硬盘坏了内存满了
    glasslion
        2
    glasslion  
       2016-12-23 17:04:00 +08:00
    这样的话,对动态程序难道不是增大 max_fails 更合理吗?
    finab
        3
    finab  
       2016-12-23 17:04:11 +08:00 via iPhone
    @ctsed 别钻牛角尖呀,重点是静态的后端很少出现 500 ,出现了也是硬盘满了之类的。

    而动态出现 500 的可能很大,因为磁盘的原因 500 的概率相对来说很小很小。
    est
        4
    est  
       2016-12-23 17:09:28 +08:00   ❤️ 2
    这是一个坑点。仔细读文档才会发现。专业的 sa 如果不知道这个是个扣分点。

    还有一个点就是用 http 1.1 和 connection keep-alive 可以提高效率。

    nginx 默认给 upstream 是 connection: close
    ctsed
        5
    ctsed  
       2016-12-23 17:11:04 +08:00
    r#3 @finab 很少出现 500 那这个功能不就没啥用么
    qq286735628
        6
    qq286735628  
       2016-12-23 17:18:32 +08:00
    既然认为后端的 500 是偶发现象可以接收,那就应该加大 max_fails 来支持这种偶发的。
    否则真的连续故障了, nginx upstream 的自动剔除机制就废了
    lhbc
        7
    lhbc  
       2016-12-23 17:23:57 +08:00
    楼主这个理解是不正确的
    1. 假如 upstream 只有一个 server ,那 max_fails 和 fail_timeout 都是没用的。

    2. 假如 upstream 有多个 server ,那超过了 max_fails 次错误后,在 fail_timeout 时间内会摘除这个 server
    如果全部 server 都失败, nginx 会清空这个状态,轮询所有服务器

    就是说,无论怎么配置, nginx 都会保证 upstream 里有可用的 server
    lhbc
        8
    lhbc  
       2016-12-23 17:39:16 +08:00
    @qq286735628 +1

    多 server 的回源,偶发异常,加大 max_fails 就可以了,要保证 fail_timeout 能起到作用;
    如果是单点回源,这两个参数就不用写了。

    无论是纯静态还是动静混合的后端
    应该用 proxy_next_upstream 和 proxy_cache_use_stale 保证静态资源的可用率
    Livid
        9
    Livid  
    MOD
    OP
       2016-12-23 17:45:10 +08:00
    有的时候情况是这样的,后端其实还有处理能力,但是因为 fail_timeout 和 max_fails 的值不理想,而被浪费了。这也是为什么有时候后端明明还活着,但是错误日志里却出现 no live upstreams while connecting to upstream
    wupher
        10
    wupher  
       2016-12-23 17:55:51 +08:00
    受教,最近正好碰到类似问题。晚上回家试一下。
    banxi1988
        11
    banxi1988  
       2016-12-23 18:06:59 +08:00
    之前没有配置过 fail_timeout
    看来之后要注意下这一点了. 我的后端还是比较有可能抛出 500 错误的.
    fangpeishi
        12
    fangpeishi  
       2016-12-23 18:10:54 +08:00
    可以再配合 proxy_next_upstream ,对抛 500 的请求再转给下一个 server 。

    Syntax: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | non_idempotent | off ...;
    Default:
    proxy_next_upstream error timeout;
    Context: http, server, location
    Specifies in which cases a request should be passed to the next server:

    https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream
    justfly
        13
    justfly  
       2016-12-23 19:33:25 +08:00   ❤️ 2
    楼主的方法是错误的。

    问题关键是不应该让 nginx 认为 500+的 http code 是错误。应当使用 proxy_next_upstream 来决定什么时候决定换 backend 。

    The cases of error, timeout and invalid_header are always considered unsuccessful attempts, even if they are not specified in the directive. The cases of http_500, http_502, http_503 and http_504 are considered unsuccessful attempts only if they are specified in the directive. The cases of http_403 and http_404 are never considered unsuccessful attempts.

    设置 fail_timeout 为 0 当某个后端阻塞 会有很多不必要的尝试 进而影响吞吐量
    Livid
        14
    Livid  
    MOD
    OP
       2017-07-25 09:36:07 +08:00
    今天在某个生产环境中遇到了一个很难搞的 no live upstreams while connecting to upstream 错误,尝试了一下把 max_fails 和 fail_timeout 都设置为 0,貌似解决了。

    之前是每次 upstream timed out 错误之后,就会跟一大串 no live upstreams while connecting to upstream (其实是因为这个时候 fail_timeout 的默认 10 秒等待),加入了这两个设置之后,现在只会有偶尔的 upstream timed out。
    keakon
        15
    keakon  
       2017-07-25 10:14:13 +08:00   ❤️ 1
    看了下源码,nginx 发现连接超时、读取超时、status code >= 300 就会尝试下一个 upstream,如果它成功就换它响应,如果它失败就自己返回失败。
    所以对于动态服务器,确实应该禁用。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1100 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 23:00 · PVG 07:00 · LAX 15:00 · JFK 18:00
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.