精华内容
下载资源
问答
  • 我们这边是一个基于Nginx的API网关(以下标记为A),最近两天有调用方反馈,偶尔会出现502错误,我们从Nginx的error日志里看,就会发现有" upstream prematurely closed connection while reading response header ...

    问题背景

    我们这边是一个基于Nginx的API网关(以下标记为A),最近两天有调用方反馈,偶尔会出现502错误,我们从Nginx的error日志里看,就会发现有" upstream prematurely closed connection while reading response header from upstream"这么一条错误日志,翻译过来其实就是上游服务过早的关闭了连接,意思很清楚,但是为什么会出现这种情况呢。而且是在业务低峰出现这种情况(也只是小概率的出现),在业务高峰的时候没有出现这种情况,而且上游服务方(以下标记为B)说出问题的请求他们那边没有收到,也就是没有任何记录,这就比较诡异了。测试环境不知道如何去复现,也就不好排查。

    排查过程

    1、在服务器上开启tcpdump抓包 tcpdump -nps0 -iany -w /tmp/20180617.pcap net [ip] and net [ip],如果不知道tcpdump怎么使用的同学可以百度一下。
    在这里插入图片描述
      2、在nginx的error.log中观察到到有两条" upstream prematurely closed connection while reading response header from upstream"错误日志,分别是2018/06/07 20:41:27和2018/06/08 09:10:46两个时间点,如下图

    3、然后查看抓包数据,找到了对应时间点的包数据,从这个可以看出,A向B发送了一个1060-2143的包,,而服务端发送了一个Fin断开连接。为什么服务端会断开连接了,我们不得而知。
    在这里插入图片描述

    4、上一步A发送包首字节数是1060,那必然前面肯定发送过包,那我们继续往上查,发现了如下图所示的现象。在20:40:22的时候3次握手建立连接并发送了第一个包;而且也查了在20:40:22到20:41:27中间这条长连接没有发送任何包
    在这里插入图片描述

    5、和B沟通,他们的Nginx中的keepalive_timeout配置为65秒,keepalive_timeout这个配置的意思是说长连接保持的时间,如果没有任何数据传输的话,超过这个时间,服务端会关闭这个连接。那这就对上了,说明在这65秒没有任何数据传输,也正好在这个点,A向B发送了数据,而B关闭了这个连接,于是就出现了上面的现象。

    6、当然这是我根据抓包分析出来的结果,我也自己模拟了这种情况,写了一个定时任务,每隔一分钟向第一台nginx发送请求,转发到第二台nginx上。第二台nginx的keepalive_timeout配置为60,在发送第七次的时候,出现了同样的问题,nginx打印同样的错误日志,抓包的结果也和上述情况一致。验证了我上述的分析过程。

    问题总结

    1、如果系统并发量不大,没有必要开启长连接,有两种方式,一、第一台nginx可以去除proxy_http_version 1.1; proxy_set_header Connection “0”;这两个配置;二、第二台nginx的keepalive_timeout可以配置为0(默认是75)。

    2、上述问题我的解决方案是:暂时调大keepalive_timeout的值,先观察,但很有可能还是会有这个问题。

    后记

    1、网络问题的排查过程是很痛苦了,再一次验证了基础知识的重要性。

    2、偶然报出的问题,一定不要忽视,说不定以后就是系统的瓶颈。

    展开全文
  • upstream的指令参数

    2021-01-04 19:27:15
    文章目录一、upstream是什么...翻译过来为最大连接数,顾名思义该参数设置每一台服务器同时最大连接的数量。 注:当设置Nginx的worker_processes为多个时,每一个工作进程之间会共享内存,所以最大连接数会大于设置的m


    一、upstream是什么?

    upstream也称为上游服务器,是在Nginx进行集群开发时配置服务器的称呼。

    二、指令

    1.max_conns

    翻译过来为最大连接数,顾名思义该参数设置每一台服务器同时最大连接的数量。

    注:当设置Nginx的worker_processes为多个时,每一个工作进程之间会共享内存,所以最大连接数会大于设置的max_conns。


    2.slow_start

    设置服务器启动的方式为慢开始,在实际运作过程中,往往在一开始的时候用户访问量不会很多,采取慢开始的方式会逐渐升高服务器的轮训权重,在规定的时间内上升到设置的轮训权重为止。

    注:该指令只在商业版本的Nginx中存在


    3.down

    停止掉向该服务器发送请求,但是并不意味着这台服务器宕机。

    注:后续会更新Nginx的负载均衡的方式,其中的ip_hash方式中,如果某台服务器宕机,为了保证尽量减少用户的会话和缓存的丢失,不能直接停止掉该服务器,而是需要在配置配置文件中设置该服务器的down指令。


    4.backup

    设置该服务器为备用服务器;在其他服务器宕机或崩溃的时候,该服务器会自动顶替掉宕机的服务器,继续完成用户请求。


    5.max_fails,fail_timeout

    在规定时间内允许最大失败次数,超过后会被认为宕机,nginx会停止将请求发送给该服务器,在fail_timeout时间后,再次尝试请求该服务器,如果还是失败,则重复动作直到重新运作为止

    展开全文
  • 最近两天有调用方反馈,偶尔会出现502错误,我们从Nginx的error日志里看,就会发现有" upstream prematurely closed connection while reading response header from upstream"这么一条错误日志,翻译过来其实就是...

    问题背景

      我们这边是一个基于Nginx的API网关(以下标记为A),最近两天有调用方反馈,偶尔会出现502错误,我们从Nginx的error日志里看,就会发现有" upstream prematurely closed connection while reading response header from upstream"这么一条错误日志,翻译过来其实就是上游服务过早的关闭了连接,意思很清楚,但是为什么会出现这种情况呢。而且是在业务低峰出现这种情况(也只是小概率的出现),在业务高峰的时候没有出现这种情况,而且上游服务方(以下标记为B)说出问题的请求他们那边没有收到,也就是没有任何记录,这就比较诡异了。测试环境不知道如何去复现,也就不好排查。

    排查过程

    1、在服务器上开启tcpdump抓包 tcpdump -nps0 -iany -w /tmp/20180617.pcap net [ip] and net [ip],如果不知道tcpdump怎么使用的同学可以百度一下。

    2、在nginx的error.log中观察到到有两条" upstream prematurely closed connection while reading response header from upstream"错误日志,分别是2018/06/07 20:41:27和2018/06/08 09:10:46两个时间点,如下图:

      

    3、然后查看抓包数据,找到了对应时间点的包数据,从这个可以看出,A向B发送了一个1060-2143的包,而服务端发送了一个Fin断开连接。为什么服务端会断开连接了,我们不得而知。

    4、上一步A发送包首字节数是1060,那必然前面肯定发送过包,那我们继续往上查,发现了如下图所示的现象。在20:40:22的时候3次握手建立连接并发送了第一个包;而且也查了在20:40:22到20:41:27中间这条长连接没有发送任何包

    5、和B沟通,他们的Nginx中的keepalive_timeout配置为65秒,keepalive_timeout这个配置的意思是说长连接保持的时间,如果没有任何数据传输的话,超过这个时间,服务端会关闭这个连接。那这就对上了,说明在这65秒没有任何数据传输,也正好在这个点,A向B发送了数据,而B关闭了这个连接,于是就出现了上面的现象。

    6、当然这是我根据抓包分析出来的结果,我也自己模拟了这种情况,写了一个定时任务,每隔一分钟向第一台nginx发送请求,转发到第二台nginx上。第二台nginx的keepalive_timeout配置为60,在发送第七次的时候,出现了同样的问题,nginx打印同样的错误日志,抓包的结果也和上述情况一致。验证了我上述的分析过程。

    问题总结

    1、如果系统并发量不大,没有必要开启长连接,有两种方式,

    1. 第一台nginx可以去除proxy_http_version 1.1; proxy_set_header Connection "0";这两个配置;
    2. 第二台nginx的keepalive_timeout可以配置为0(默认是75)。

    2、上述问题我的解决方案是:暂时调大keepalive_timeout的值,先观察,但很有可能还是会有这个问题。

    后记

    1、网络问题的排查过程是很痛苦了,再一次验证了基础知识的重要性。

    2、偶然报出的问题,一定不要忽视,说不定以后就是系统的瓶颈。

    展开全文
  •  我们这边是一个基于Nginx的API网关(以下标记为A),最近两天有调用方反馈,偶尔会出现502错误,我们从Nginx的error日志里看,就会发现有" upstream prematurely closed connection while reading response header...

    问题背景

      我们这边是一个基于Nginx的API网关(以下标记为A),最近两天有调用方反馈,偶尔会出现502错误,我们从Nginx的error日志里看,就会发现有" upstream prematurely closed connection while reading response header from upstream"这么一条错误日志,翻译过来其实就是上游服务过早的关闭了连接,意思很清楚,但是为什么会出现这种情况呢。而且是在业务低峰出现这种情况(也只是小概率的出现),在业务高峰的时候没有出现这种情况,而且上游服务方(以下标记为B)说出问题的请求他们那边没有收到,也就是没有任何记录,这就比较诡异了。测试环境不知道如何去复现,也就不好排查。

    排查过程

      1、在服务器上开启tcpdump抓包 tcpdump -nps0 -iany -w /tmp/20180617.pcap net [ip] and net [ip],如果不知道tcpdump怎么使用的同学可以百度一下。

      2、在nginx的error.log中观察到到有两条" upstream prematurely closed connection while reading response header from upstream"错误日志,分别是2018/06/07 20:41:27和2018/06/08 09:10:46两个时间点,如下图

      3、然后查看抓包数据,找到了对应时间点的包数据,从这个可以看出,A向B发送了一个1060-2143的包,,而服务端发送了一个Fin断开连接。为什么服务端会断开连接了,我们不得而知。

      4、上一步A发送包首字节数是1060,那必然前面肯定发送过包,那我们继续往上查,发现了如下图所示的现象。在20:40:22的时候3次握手建立连接并发送了第一个包;而且也查了在20:40:22到20:41:27中间这条长连接没有发送任何包

      5、和B沟通,他们的Nginx中的keepalive_timeout配置为65秒,keepalive_timeout这个配置的意思是说长连接保持的时间,如果没有任何数据传输的话,超过这个时间,服务端会关闭这个连接。那这就对上了,说明在这65秒没有任何数据传输,也正好在这个点,A向B发送了数据,而B关闭了这个连接,于是就出现了上面的现象。

      6、当然这是我根据抓包分析出来的结果,我也自己模拟了这种情况,写了一个定时任务,每隔一分钟向第一台nginx发送请求,转发到第二台nginx上。第二台nginx的keepalive_timeout配置为60,在发送第七次的时候,出现了同样的问题,nginx打印同样的错误日志,抓包的结果也和上述情况一致。验证了我上述的分析过程。

    问题总结

      1、如果系统并发量不大,没有必要开启长连接,有两种方式,一、第一台nginx可以去除proxy_http_version 1.1; proxy_set_header Connection "0";这两个配置;二、第二台nginx的keepalive_timeout可以配置为0(默认是75)。

      2、上述问题我的解决方案是:暂时调大keepalive_timeout的值,先观察,但很有可能还是会有这个问题。

    后记

      1、网络问题的排查过程是很痛苦了,再一次验证了基础知识的重要性。

      2、偶然报出的问题,一定不要忽视,说不定以后就是系统的瓶颈。

    转载于:https://www.cnblogs.com/coder-yoyo/p/9157148.html

    展开全文
  • Upstream Server 中文翻译上游服务器,意思就是负载均衡服务器设置,白话文表示(就是被nginx代理最后真实访问的服务器)。 负载均衡算法:配置多个上游服务器(真实业务逻辑访问的服务器)的负载均衡机制。 失败重试...
  • git本地仓库push远程仓库的时候,报了异常:fatal the current branch master has no upstream branch 经过查询发现目前有两种解决方案: 1.翻译后大致意思是,远程仓库创建时候要建立一个README文件,然后再进行...
  • Netty教程—Part6—Upstream、Downstream

    千次阅读 2014-03-03 22:34:35
    本文由 ImportNew - 刘海波 翻译自 seeallhearall.blogspot。如需转载本文,请先参见文章末尾处的转载要求。 本文是Netty教程的第六篇。 你可能会有疑问ObjectEncoder和ObjectDecorder在pipeline的一个...
  • 这个问题简单翻译过来就是: fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 这行配置无法帮我找到 传过来的文件。试了一下写一个 index.html 文件进行测试,发现是有的。然而,index.php就...
  • 关于RxJava的一些翻译

    2018-08-13 11:04:25
    关于RxJava一些翻译 UpStream and DownStrea 上游和下游 在RxJava中数据流可以分为数据源,数据源的操作和数据消费者。 站在操作的位置,可以把输入看作上游,把输出看作下游。 Object in motion 运动对象 在...
  • 首先fork我的项目把fork过去的项目也就是你的项目clone到你的本地在命令行运行 git branch develop 来创建一个新分支运行 git checkout develop 来切换到新分支运行 git remote add upstream ...
  • 朋友可能不太清楚如何帮忙翻译,我这里写一个简单的流程,大家可以参考一下:首先fork我的项目把fork过去的项目也就是你的项目clone到你的本地在命令行运行 git branch develop 来创建一个新分支运行 git ...
  • 很简单,上代码:#反向代理 upstream backend { server access-1:8080 ; server access-2:8080 ; server access-3:8080 ; } #路由 location / { #看英文翻译就明白了 proxy_next_upstream err
  • Nginx之负载均衡(四)

    2019-10-04 20:17:05
    Upstream Server 中文翻译上游服务器,意思就是负载均衡服务器设置,白话文表示(就是被nginx代理最后真实访问的服务器) 负载均衡算法:配置多个上游服务器(真实业务逻辑访问的服务器)的负载均衡机制 失败重试机制:...
  • USB 2.0 协议中文注解

    千次阅读 2017-06-15 00:46:25
    最近在做USB相关的开发,特别是USB设备的断开以及识别的过程...一、 upstream&downstream Host or Hub:我们这里可以简单的理解为USB Host; Function:一个USB设备有多个Function,这里可以简单的理解为一个USB设备;
  • To make your branch track a remote branch call, for example, git branch --set-upstream-to=origin/master master 翻译:没有为分支主节点配置跟踪分支,或者分支不存在.为了使您的分支跟踪远程分支,如何做?...
  • 可以看到翻译过来是:将主机推送到资源站被拒绝. 在查阅了很多资料后,发现是码云上不小心把自己的邮箱设为了不可见, 然后把邮箱设置为公开的后,再在git的命令行跑一下命令 ```bash git pull git pull origin ...
  • Git 必会基础操作指令

    2021-01-25 21:44:40
    专用名词翻译 Workspace:工作区 Index / Stage:暂存区 Repository:仓库区(或本地仓库) Remote:远程仓库 本地分支关联远程:git branch --set-upstream-to=origin/beta beta 一、新建代码库 在当前目录新建...
  • USB Hub Chip之GL850

    千次阅读 2012-09-29 15:43:07
    没找到中文的GL850 的 datasheet,自己翻译一下,以后用时,容易看。 一、概述 GL850是一个4口的标准USB hub控制器,它遵守USB2.0标准。既可连接到USB1.1 host/hub,又可以连接到USB2.0 host/hub。 当GL850...
  • Google翻译如下 当前分支没有跟踪信息。 请指定您要合并的分支。 有关详细信息,请参见git-pull(1)。 git pull <远程> <分支> 如果您希望为此分支机构设置跟踪信息,可以使用以下方法: git ...
  • git常用命令学习总结

    2018-03-13 23:24:00
    英语真是我的硬伤啊,提示都要用百度翻译看一遍,费劲。。。 下面是我日常工作中遇到的各种问题汇总 1、远程服务器分支与本地代码合并 我第一次打出 git pull 显示下面的错误 就怪我英语太差,都懒得看报的...
  • 提取所有的中文翻译提交 <pre><code>bash git checkout release-1.16 git diff release-1.16 release-1.14 content/zh/ > release-1.14-zh.patch </code></pre> <h2>Step2. 强制应用补丁 <pre><code>bash git ...
  • 翻阅资料时学到了不少,参考了wiki nginx,英文不好的同学可以参考其翻译nginx模块参考手册中文版。  上诉资料很详细的讲解了nginx的方方面面,在此总结下我经常用到的。 一、Http模块  所有的http配置项必须...
  • \注:本文最初发布于MaxCDN博客,InfoQ中文站在获得作者授权的基础上对文章进行了翻译。\正文\NGINX允许使用upstream指令配置后台。最值得注意的是会话持久化和负载均衡策略。\在会话持久化方面,有三个有用的变量...
  • 15、高性能Web服务器Nginx的配置与部署研究(15)Upstream负载均衡模块 内容:讲述Nginx的HttpUpstreamModule如何实现对后端服务器的HTTP请求的负载均衡。 16、高性能Web服务器Nginx的配置与部署研究(16)小议...
  • <ul><li>对中文翻译文档变更的文件重命名</li><li>移除翻译过时文档</li><li>获取新增加的文件列表 - add-issue</li><li>获取更新的文件列表 - update-issue</li><li>比较原始英文与翻译文档的差异</li></ul> ...

空空如也

空空如也

1 2
收藏数 27
精华内容 10
关键字:

upstream翻译