V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
zzhpeng
V2EX  ›  程序员

nginx+ PHP -fpm 出现 502

  •  
  •   zzhpeng · 2019-12-26 18:11:32 +08:00 · 3188 次点击
    这是一个创建于 1013 天前的主题,其中的信息可能已经有所发展或是发生改变。

    问题概述

    在某段时间段,网站出现 nginx 502,通过宝塔查看,负载状态是 100%,查看监控,磁盘 IO 飙高,如下为近 7 日 IO 磁盘图:

    FilqyanVhrxGwgOxksnDlyWAnw-W

    排查数据

    nginx 抛出 502,证明是它的反向代理出错,这个代理 php-cgi 出了问题,我用的是 php-fpm,出了问题。 查看 php-fpm 日志,发现并没有什么异常,提示需要提升 start_servers 是因为在这个时候我重载了 php-fpm, 但是重启后并没作用。然后重启了 nginx,才恢复了正常。

    FilqyanVhrxGwgOxksnDlyWAnw-W

    查看 nginx 日志,出现了很多*12359859 connect() to unix:/tmp/php-cgi-72.sock failed (11: Resource temporarily unavailable) while connecting to upstream

    FilqyanVhrxGwgOxksnDlyWAnw-W

    根据这个 nginx 这个提示查了相关资料,得到了 3 个解决方案

    1、php-fpm 的 sock 通讯方式 改为 tcp

    结论:不考虑,查了相关的 blog,出现了相同问题,还从 tcp 改为 sock 模式呢!!

    2、用两个 php-fpm sock,nginx 负载均衡

    2.1、复制一份配置文件,修改里边的 pid sock cp /usr/local/php/etc/php-fpm.conf cp /usr/local/php/etc/php-fpm2.conf

    [global]
    pid = /usr/local/php/var/run/php-fpm2.pid
    error_log = /usr/local/php/var/log/php-fpm2.log
    log_level = notice
    
    [www]
    listen = /tmp/php-cgi2.sock
    

    2.2、复制一个启动文件,也修改相关的信息

    cp /etc/init.d/php-fpm /etc/init.d/php-fpm2

    php_fpm_BIN=${exec_prefix}/sbin/php-fpm
    php_fpm_CONF=${prefix}/etc/php-fpm2.conf
    php_fpm_PID=${prefix}/var/run/php-fpm2.pid
    

    2.3、启动 /etc/init.d/php-fpm2 start

    2.4、nginx 配置文件,增加 upstream 模块

    upstream backend{
        server unix:/tmp/php-cgi.sock;
        server unix:/tmp/php-cgi2.sock;
    }
    

    2.5、把 fastcgi_pass unix:/tmp/php-cgi.sock;改成 fastcgi_pass backend; 重新加载 /etc/init.d/nginx reload

    结论:这个方法,和我直接调大 php-fpm max_children 差不多,不考虑。

    3、php-fpm 的 listen.backlog 默认-1 改为 1024 或者 4096,即是调大

    结论:待检验,

    V 友们,又遇到我这种情况吗?

    第 1 条附言  ·  2019-12-26 19:32:59 +08:00

    更多服务器信息

    1、云服务器ECS

    1.1、系统磁盘BPS,其他监控内容无太大的异常 FilqyanVhrxGwgOxksnDlyWAnw-W

    2、RDS数据库

    2.1、-网络流量 FilqyanVhrxGwgOxksnDlyWAnw-W

    2.2、RDS数据库-CPU使用率 FilqyanVhrxGwgOxksnDlyWAnw-W

    2.3、RDS数据库-TPS/QPS FilqyanVhrxGwgOxksnDlyWAnw-W

    第 2 条附言  ·  2019-12-26 19:35:44 +08:00

    2.4、RDS数据库-慢日志 FilqyanVhrxGwgOxksnDlyWAnw-W

    第 3 条附言  ·  2019-12-27 11:20:57 +08:00

    最后选择

    用户请求飙升,平台又没有做什么活动,查看了nginx access log,分析同一个ip,同一时间段上百个请求同 一个访问链接,所以决定iptable限制下,控制单个IP的最大30并发连接数。

    sudo iptables -I INPUT -p tcp --dport 443 -m connlimit --connlimit-above 30 -j REJECT
    sudo iptables -I INPUT -p tcp --dport 80 -m connlimit --connlimit-above 30 -j REJECT
    
    17 条回复    2019-12-27 13:47:18 +08:00
    iyaozhen
        1
    iyaozhen  
       2019-12-26 18:15:22 +08:00 via Android
    这就是扛不住了,加机器就行
    hero2040407
        2
    hero2040407  
       2019-12-26 19:31:27 +08:00
    你同一台机器负载均衡做什么?先看看有没有慢查询,优化一下数据库,不行就升级一下数据库
    zzhpeng
        3
    zzhpeng  
    OP
       2019-12-26 19:36:21 +08:00
    @hero2040407 没有慢日志,不关数据库问题
    lhx2008
        4
    lhx2008  
       2019-12-26 19:39:25 +08:00 via Android
    php 502 就是 php 并发太多了,一定是哪里卡住了,然后请求太多,满了就 502 了
    lhx2008
        5
    lhx2008  
       2019-12-26 19:45:58 +08:00 via Android
    如果不是数据库的问题,有可能是请求了别的远程资源,你先估计下每个请求要多久时间,然后你一秒有多少个请求,然后看看能不能处理过来
    onepunch
        6
    onepunch  
       2019-12-26 19:49:05 +08:00   ❤️ 1
    前两天公司服务器出问题,一样的问题,下面是大佬的调查以及改善
    [错误日志]
    24926#24926: *680716664 connect() to unix:/run/php/php7.2-bi-svc.sock failed (11: Resource temporarily unavailable) while connecting to upstream,

    [调查]
    nginx (客户端) 和 php-fpm (服务端) 通过 unix socket 通信,在 connet() 时,会进行类似 tcp 的三次握手,
    如果 accpet queue 队列满了,server 将发送一个 ECONNREFUSED 错误信息 Connection refused 到 client。这样 nginx 就会报这个错了,连接不上。

    php-fpm 的 backlog 是 accpet queue 的最大长度
    cat /proc/sys/net/core/somaxconn 128
    查看 php-fpm 里的配置 listen.backlog 是 4096
    由于会取这 2 个的最小值, 所以是 128

    验证当时的请求:
    [email protected]:/var/log/nginx$ grep '2019-12-06T16:48' bi_svc.access.log.1 | wc -l
    9903
    每秒请求数 165
    165>128 了, 请求太多了,应该是 accpet queue 满了

    [解决办法]
    vi /etc/sysctl.conf
    net.core.somaxconn = 1024
    将 /proc/sys/net/core/somaxconn 改成 1024 就不会出问题了
    zzhpeng
        7
    zzhpeng  
    OP
       2019-12-26 19:50:19 +08:00
    @lhx2008 有时候并非并发太多会 502,还可能与程序有关,这里有一遍关于框架 session 问题导致的 502,https://www.zzhpeng.com/nginx502.html
    haiyang416
        8
    haiyang416  
       2019-12-26 19:54:17 +08:00
    PHP worker 进程用完了。
    检查系统哪个地方出现了问题,比如磁盘或者网络 IO 耗时过多。
    另外你说负载 100% 这个负载到底是什么负载,如果是 CPU 的话就要去找占用 CPU 最高的进程查问题。
    zzhpeng
        9
    zzhpeng  
    OP
       2019-12-26 19:54:34 +08:00
    @onepunch 我也是查看的相关类似这种处理,但是我这种是突然间飙升的,该这样做吗?不这样做又 502。2333333
    zzhpeng
        10
    zzhpeng  
    OP
       2019-12-26 19:57:03 +08:00
    @haiyang416 负载 100% ,由多个指标影响,如磁盘 io,网络 io,cpu,内存。当时是由于磁盘 io,飙高影响
    lhx2008
        11
    lhx2008  
       2019-12-26 19:57:39 +08:00
    @zzhpeng #9 最关键是还是看 slow log 排查啊,加连接数有用的话,根本不是问题,加机器就完事了
    onepunch
        12
    onepunch  
       2019-12-26 20:01:40 +08:00
    @zzhpeng 你可以根据我给你的东西,调查一下出问题那一刻的 log,核实一下原因。
    zzhpeng
        13
    zzhpeng  
    OP
       2019-12-26 20:51:18 +08:00
    @onepunch 按照你们的思路,算了峰值,并没有达到每秒 128 个,只有在那段时间段平均 17.8 个左右,比原来翻了 6.5 倍,b 端系统。我觉得像是恶意攻击,一个时间段,都是同一个 ip 地址,同一种请求连接。
    onepunch
        14
    onepunch  
       2019-12-26 21:10:55 +08:00
    不能吧,每秒 18 个请求都应付不了吗?你算的是 nginx log 吧??
    onepunch
        15
    onepunch  
       2019-12-26 21:24:09 +08:00   ❤️ 1
    还有就是他访问的接口你执行的速度是不是有问题? 150 个 php-fpm 子进程都不是空闲状态,是不是存在慢查询啊?

    somaxconn 这个内核参数你在看下配置的是多少吧? 它跟 backlog 取最小的那个
    zzhpeng
        16
    zzhpeng  
    OP
       2019-12-26 23:00:13 +08:00
    @onepunch 是算 nginx access log,我抽出了出问题的十分钟平均计算的。这 18 个请求都走数据库了,响应会比较慢,我的 somaxconn 数值也和你的一样 128。仔细看了日志,排查了下,出问题的这一段时间内,nginx error log 出现很多重复的同一个 ip,同一种请求链接的请求,初步确定是存在恶意攻击了,而且隔一段时间都会出现。目前解决方案是先弄个 iptables。
    qsbaq
        17
    qsbaq  
       2019-12-27 13:47:18 +08:00
    502 大部分情况下是 PHP 的问题,试着把 php 进程数调高试一下。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1967 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 135ms · UTC 04:57 · PVG 12:57 · LAX 21:57 · JFK 00:57
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.