兄弟的公司所 to B 业务
后端大概就是 pg + nignx + php-fpm
偶然会遇到这么个问题很好奇,所以来请教 v 站的大佬们,希望各位大佬不吝赐教!
fpm 配置
贴上编译信息 + 运行配置,
php.ini
是默认配置就不贴了
# 版本
PHP 7.4.20 (cli) (built: Nov 29 2021 15:48:06) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
# 编译信息
./configure --prefix=/usr/local/php7 --exec-prefix=/usr/local/php7 --bindir=/usr/local/php7/bin --sbindir=/usr/local/php7/sbin --includedir=/usr/local/php7/include --libdir=/usr/local/php7/lib/php --mandir=/usr/local/php7/php/man --with-mhash --with-openssl --with-mysqli=shared,mysqlnd --with-pdo-mysql=shared,mysqlnd --enable-gd --with-iconv --with-zlib --with-zip --enable-inline-optimization --disable-debug --disable-rpath --enable-shared --enable-xml --enable-bcmath --enable-shmop --enable-sysvsem --enable-mbregex --enable-mbstring --enable-ftp --enable-pcntl --enable-sockets --with-xmlrpc --enable-soap --without-pear --with-gettext --enable-session --with-curl --with-jpeg --with-freetype --enable-opcache --enable-fpm --with-fpm-user=nginx --with-fpm-group=nginx --without-gdbm --disable-fileinfo PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/
# 配置
[www]
user = nginx
group = nginx
listen = 127.0.0.1:9000
pm = dynamic
pm.max_children = 12
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.max_requests = 300
现象
这个部分目前我没法定位到问题,目前没有办法复现,使用一段时间后
有概率
出现,重启fpm
可解决
贴一个案例的现象,因为无法复现,无法贴上排查的屏显
服务器10C16G
, 主频3.7GHz
2 倍
以上。(证实描述不虚)。disk
、pg
、redis
、nginx
都挺正常,因为每次都是重启fpm
能解决,应该排除了。free -h
显示 avaliable 还有1/3
以上。top
显示平均负载在8-10
之间,cpu 占用高的都是fpm
进程。重点就是 cpu 平均负载满了,感觉像是某个进程陷入了死锁,一直在占用 cpu 时间,现在想了解的是:
print stack
机制?最后感谢各位路过,赐教的 V 站大佬们!
1
Dcynsd 2023-08-31 11:05:13 +08:00
开启 php-fpm 慢日志看看
|
2
dusu 2023-08-31 11:07:42 +08:00 via iPhone
碰巧最近 7.4 我们线上也出现了
原因目前确定在 apcu 上限内存满了导致的问题 暂时还没有深究 但能通过出问题 reload fpm 来临时解决 |
3
ygtq 2023-08-31 11:08:46 +08:00
这也太难猜了吧,要不你装个类似 Tideways 的监控一下?
|
4
kokutou 2023-08-31 11:11:57 +08:00 via Android
先升级 php8 看看
|
5
kphcdr 2023-08-31 11:24:08 +08:00
1. 慢日志
2. xhprof 3. 排除一下 mysql 和 redis 等服务问题 |
6
aaronnum7 2023-08-31 11:25:57 +08:00
用 strace -p 命令看下 FPM 进程执行阻塞时的系统调用呢
|
7
BeforeTooLate 2023-08-31 11:29:34 +08:00
pm.max_children = 12
pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3 你这么好的配置为啥这里设置才这么点? |
8
BeforeTooLate 2023-08-31 11:31:48 +08:00
机器配置还不如你,我都设置静态了。
pm = static pm.max_requests = 102400 pm.max_children = 200 pm.start_servers = 100 pm.min_spare_servers = 10 pm.max_spare_servers = 250 request_terminate_timeout = 600 request_slowlog_timeout = 10s slowlog = php-fpm.log.slow |
9
php0yyds 2023-08-31 11:32:00 +08:00
楼上说的好像有道理,fpm 进程太少了 8
|
10
skvi OP @Dcynsd #1 我准备给他们开一下慢日志看看,trace 深度建议一般多少呢老哥
@dusu #2 我这边也是 reload 就好,我去了解下你这个问题哈 @ygtq #3 说的是,之前试过装了个`php_fpm_exporter`, prometheus+grafana, 感觉看不到什么东西,我再了解下监控 @kokutou #4 目前升不了呢 @kphcdr #5 mysql 其实没用,pg 和 redis 目前看都是没什么异常,可能我看的不够仔细 @aaronnum7 #6 OKK, 下次出现我试试看 @BeforeTooLate #7 之前开过静态 200 ,也是一样,看起来 stuck 的进程没有保持在 cpu 进程数量附近,所以先改成动态了,加上其实并发并没有那么可怕,我研究下你 #7 的配置参数下次尝试一下 @php0yyds #8 嗯嗯,目前感觉不是大量并发导致的,所以现改小了 多谢各位老哥的建议 |
11
julyclyde 2023-08-31 13:08:23 +08:00
php 不是有 max requests 么,可以自动重启的呀
|
12
kkk9 2023-08-31 13:48:15 +08:00
先考虑 sql 慢查询,再考虑 php 的问题
|
14
8355 2023-08-31 14:25:11 +08:00
按照你这个配置就是这种情况,并发量高了就会是 cpu 打满持续夯死。
pm = dynamic pm.max_children = 12 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3 pm.max_requests = 300 按照 8 楼的配置先改一版 之后再慢慢晚上加就行。 pm.max_children = 200 pm.start_servers = 100 我估计 16g 内存我觉得加到 500 以上是没问题的 |
15
skvi OP |
16
devopsdogdog 2023-09-01 21:25:07 +08:00
1. 进程确实太少了,16g,按我的经验是 200 个左右,是否这块问题,可以通过 php-fpm 日志确认,如果有相关 提示
2.避免内存溢出等问题 pm.max_requests 确实要设置 不宜过大过小 3. php-fpm 我是建议以 socket 方式进行交互, 假设没有网络方面的调优,端口占用也会出现类似问题 4. nginx 和 php-fpm 均开启日志,检查是卡 nginx 还是 php-fpm 上,upstream 的时间占用 5.关闭缓存或者一些奇怪的扩展。 6.检查对应时段是否有被 扫描漏洞,导致负载流量增大。 7. 楼上说的 apm 手段 和 strace 都对 8. 以前遇过的奇怪问题导致 ssl oscp 被墙 9. 确保 数据库 redis 等 网络延迟,一般内网没啥问题 10. 某些奇怪的 安全控件也可能导致 比如 OpenRASP 等等 以上均个人经验 仅供参考 |
17
putyy 2023-09-12 14:17:02 +08:00
1. opencache 开了吗?
2. dynamic 也没问题,但是 start_servers 、max_children 这些明显太小,可以参考网上的参数调整大一些 |