Yc-Ma Blog

Nginx请求转发失败原因排查

 
  • Yc-Ma
  • Nov 11, 2020

Here’s the table of contents:

  1. 【一】日志报错
  2. 【一】报错解析
  3. 【一】报错原因
  4. 【二】日志报错
  5. 【二】报错解析
  6. 【二】报错解决
  7. 【三】日志报错
  8. 【三】报错解析
  9. 【三】报错解决
  10. 【四】日志报错
  11. 【四】报错解析
  12. 【四】报错解决
  13. 【五】日志报错
  14. 【五】报错解析
  15. 【五】报错解决

【一】日志报错

2020/11/11 06:04:25 [error] 25231#0: *7461416 connect() failed (111: Connection refused) while connecting to upstream, client: 10.10.39.169, server: testlab.graphql.http.server, request: "POST /ongdb/graphql HTTP/1.1", upstream: "http://10.20.13.58:7424/ongdb/graphql", host: "10.20.13.130"

【一】报错解析

客户端10.10.39.169访问testlab.graphql.http.server服务时，请求被转发到了10.20.13.58:7424，但是因为某些原因导致转发失败，所以发生报错

【一】报错原因

主要从网络和服务两方面进行排查

  • IP不通
  • 端口不通
  • 服务不可用等 
    # 排查网络可以用
telnet ip port

    # 排查服务可以用
ps -ef | grep serverName

【二】日志报错

2020/11/09 06:30:26 [crit] 4013#0: accept4() failed (24: Too many open files)

【二】报错解析

操作系统可打开文件数限制导致

【二】报错解决

  • 修改最大可打开文件数 
    ulimit -n 65536
ulimit -a
# hard nofile 65536
# soft nofile 65536
# 加上用户
centos soft nofile 65535
centos hard nofile 65535
sudo vim /etc/security/limits.conf
# sudo ulimit -n 65536 报错：sudo: ulimit: command not found，则使用下面的名称
# 修改LOGNAME
sudo sh -c "ulimit -n 65535 && exec su $LOGNAME"

ulimit -n 1024000
ulimit -a
# hard nofile 1024000
# soft nofile 1024000
# 加上用户
centos soft nofile 1024000
centos hard nofile 1024000
sudo vim /etc/security/limits.conf
# sudo ulimit -n 1024000 报错：sudo: ulimit: command not found，则使用下面的名称
# 修改LOGNAME
sudo sh -c "ulimit -n 1024000 && exec su $LOGNAME"

【三】日志报错

2020/11/11 05:19:20 [alert] 8343#0: *2558542 1024 worker_connections are not enough while connecting to upstream, client: 10.20.2.153, server: testlab.ongdb.http.server, request: "POST /db/data/transaction/commit HTTP/1.1", upstream: "http://10.20.12.173:7474/db/data/transaction/commit", host: "10.20.13.200"

【三】报错解析

worker_connections每个进程允许的最多连接数超过1024

【三】报错解决

worker_connections，这个参数表示每个进程允许的最多连接数，理论上每台nginx服务器的最大连接数为 worker_processes * worker_connections， 其中如果是4cpu，则worker_processes参数=4。此外，修改worker_connections值时，是不能超过worker_rlimit_nofile的这个值。

# 设置为CPU核数【双核4线程，可以设置为4】
worker_processes  8;
#配置Nginx worker进程最大打开文件数
worker_rlimit_nofile 65535;
events {
    #单个进程允许的客户端最大连接数
    worker_connections  4096;
}

worker_connections解析
1.connections不是随便设置的，而是与两个指标有重要关联，一是内存，二是操作系统级别的“进程最大可打开文件数”。
2.内存：每个连接数分别对应一个read_event、一个write_event事件，一个连接数大概占用232字节，2个事件总占用96字节，那么一个连接总共占用328字节，通过数学公式可以算出100000个连接数大概会占用 31M = 100000 * 328 / 1024 / 1024，当然这只是nginx启动时，connections连接数所占用的nginx。
3.进程最大可打开文件数：进程最大可打开文件数受限于操作系统，可通过 ulimit -n 命令查询，以前是1024，现在是65535,
nginx提供了worker_rlimit_nofile指令，这是除了ulimit的一种设置可用的描述符的方式。 该指令与使用ulimit对用户的设置是同样的效果。此指令的值将覆盖ulimit的值，如：worker_rlimit_nofile 20960;
设置ulimits：ulimit -SHn 65535

# CENTOS查看CPU核心数和线程数

【四】日志报错

2020/11/09 06:28:30 [error] 8343#0: *93739 client intended to send too large body: 3068795 bytes, client: 10.10.39.131, server: testlab.ongdb.http.server, request: "POST /db/data/transaction/commit HTTP/1.1", host: "testlab.ongdb.http.server"

【四】报错解析

最大文件大小过小，或者没有设置导致【默认1M】

【四】报错解决

# 配置nginx请求数据最大限制
client_max_body_size 64m;

【五】日志报错

2020/10/27 08:20:48 [error] 7949#0: *2697 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 10.10.39.162, server: testlab.ongdb.http.server, request: "POST /db/data/transaction/commit HTTP/1.1", upstream: "http://10.20.12.173:7474/db/data/transaction/commit", host: "testlab.ongdb.http.server"

【五】报错解析

  • 该请求获取的数据比较多，后端处理该请求花费的时间较长。
  • 也可能是代理服务器与上游服务器的网络问题 
    该错误是由于nginx 代理去获取上游服务器的 返回值超时了

【五】报错解决

# Nginx超时时间设置
# 该指令是指从上游服务器两次成功的读操作耗时的超时时间，也就意味着从上游服务器成功读操作后，过了60S【默认值】,没有再从上游服务器成功读操作的话，就会关闭该连接。
proxy_read_timeout 3600s;
Search