我有一个用Laravel/PHP编写的Web应用程序,该应用程序处于早期阶段,通常可提供 500-600 reqs/min 。我们使用Maria DB和Redis进行缓存,一切都在AWS上进行。

对于我们要在平台上推广的事件,我们向所有用户发送推送通知(移动平台),导致大约2分钟的长时间流量爆发,这使我们达到 3.5k reqs/min

在我们当前的服务器规模上,这完全使应用服务器的CPU陷入瘫痪,这些CPU通常以 10%的CPU 左右运行。在此突发期间,数据库和Redis群集似乎正常。

查看日志,似乎所有PHP-FPM工作池进程都被占用,并开始从Nginx上游排队请求。

我们目前有:

  • 三个 m4.large服务器(2个内核,每个8gb RAM)
  • 动态PHP-FPM流程管理,每个框上最多包含最多120个子进程(服务器)

  • 我的问题:

    1)我们应该增加FPM池吗?似乎在内存方面,我们可能已接近极限

    2)我们应该减少FPM池的吗?看来我们正在分派(dispatch)太多的进程,以至于CPU陷入了瘫痪,无法真正完成其中的任何一个。我想知道我们是否因此能以更少的花费获得更好的结果。

    3)我们是否应该简单地使用具有更多RAM和CPU的更大的盒子,这将使我们能够增加更多的FPM工作人员?

    4)我们应该考虑进行FPM性能调整吗?我们使用Opcache,但是,我们是否应该切换到FPM的静态流程管理,以减少流程旋转的开销呢?

    最佳答案

    与核心数量有关的子进程太多。

    首先,您需要在正常突发时间了解服务器状态。

    1)检查php-fpm进程的数量。

    ps -ef | grep 'php-fpm: pool' | wc -l
    

    2)检查平均负载。如果有2个核心,则2个或更多意味着工作开始延迟。
    top
    htop
    glances
    

    3)根据服务,我们开始从两倍于内核数的角度进行调整。
    ; Example
    ;pm.max_children = 120       ; normal) pool 5, load 0.1 / burst) pool 120, load 5  **Bad**
    ;pm.max_children = 4    ; normal) pool 4, load 0.1 / burst) pool 4, load 1
    pm.max_children = 8    ; normal) pool 6, load 0.1 / burst) pool 8, load 2  **Good**
    



    通过apache基准测试(ab),以与实际负载相似的负载测试Web服务器更为准确。
    ab -c100 -n10000 http://example.com
    
    Time taken for tests:   60.344 seconds
    Requests per second:    165.72 [#/sec] (mean)
     100%    880 (longest request)
    

    关于PHP-FPM性能调优-流量激增,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/55273761/

    10-12 00:48