php-fpm 在运行长时间后会突然出现假死情况,导致网站无法访问。还好客服反应快,能及时反馈到技术。 看了看日志 大概 2 个月左右会出现一次,问题一直没有排查出来。 也找不到原因
想到一种方案,在某个业务上写一些代码。 定时执行,如果返回非 200 直接发送短信到手机。。
不知道大 pro 们能不能提供一些思路, 如果能彻底解决问题更好了。
1
miyavis 2018-05-16 09:04:21 +08:00
心跳 检测?
|
2
wwqgtxx 2018-05-16 09:09:05 +08:00 via iPhone
不是有一些专门的监控网站比如监控宝之类的能隔多少分钟检测你的网站能否正常访问,一旦有问题就会给你发短信
|
3
owenliang 2018-05-16 09:10:48 +08:00 via Android
考虑升级一下版本先,按道理不存在那么严重的问题哈。
|
4
defunct9 2018-05-16 09:13:38 +08:00
直接 curl 发请求,1 分钟一次,如果掉了,拉起来。
|
5
tomczhen 2018-05-16 09:15:44 +08:00 via Android
php - fpm 配置参数了解一下。
|
6
Luckyray 2018-05-16 09:15:59 +08:00
直接写个脚本一分钟检测一次...
|
7
Quarter 2018-05-16 09:19:24 +08:00 via iPhone
服务器放一个定时任务,检测可不可以访问,不可以就重启服务?
|
8
alexsunxl 2018-05-16 09:20:51 +08:00
php-fpm 的子进程设置是不是太少了
你要别人帮忙, 要把配置也发出来呀 |
9
liwl 2018-05-16 09:21:20 +08:00
supervisord
|
10
wr410 2018-05-16 09:21:46 +08:00
免费的公网监测有 pingdom 可以了解一下
实际上监控不如自己写一个 crontab,挂了重启或者干脆直接定时重启就好了 |
11
d0m2o08 2018-05-16 09:22:14 +08:00
zabbix 有站点监控 或者 curl 获取状态码 非 200 调用钉钉机器人报警 加到 cron
|
12
nosay 2018-05-16 09:28:14 +08:00 1
楼上已经说了那么多了,我来个另类的思路。
每月定时重启一下 php-fpm,最好是整个服务器。 蹓了蹓了.. |
13
alen 2018-05-16 09:30:08 +08:00
monitorix 了解下
|
15
zhixiao 2018-05-16 09:39:52 +08:00
|
16
wwek 2018-05-16 09:41:19 +08:00
各种 AMP 系统了解下
http://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-module-php_fpm.html metricbeat 了解下 |
17
zhaojjxvi 2018-05-16 09:59:11 +08:00 via iPhone
Uptimerobot 可以做到宕了有提醒
|
18
defunct9 2018-05-16 10:01:02 +08:00 1
开 ssh,让我上去看看
|
20
guoyu4126 OP @alexsunxl
;pm = dynamic pm=ondemand ; The number of child processes to be created when pm is set to 'static' and the ; maximum number of child processes when pm is set to 'dynamic' or 'ondemand'. ; This value sets the limit on the number of simultaneous requests that will be ; served. Equivalent to the ApacheMaxClients directive with mpm_prefork. ; Equivalent to the PHP_FCGI_CHILDREN environment variable in the original PHP ; CGI. The below defaults are based on a server without much resources. Don't ; forget to tweak pm.* to fit your needs. ; Note: Used when pm is set to 'static', 'dynamic' or 'ondemand' ; Note: This value is mandatory. pm.max_children = 50 ; The number of child processes created on startup. ; Note: Used only when pm is set to 'dynamic' ; Default Value: min_spare_servers + (max_spare_servers - min_spare_servers) / 2 pm.start_servers = 10 ; The desired minimum number of idle server processes. ; Note: Used only when pm is set to 'dynamic' ; Note: Mandatory when pm is set to 'dynamic' pm.min_spare_servers = 5 ; The desired maximum number of idle server processes. ; Note: Used only when pm is set to 'dynamic' ; Note: Mandatory when pm is set to 'dynamic' pm.max_spare_servers = 15 ; The number of seconds after which an idle process will be killed. ; Note: Used only when pm is set to 'ondemand' ; Default Value: 10s ;pm.process_idle_timeout = 10s; ; The number of requests each child process should execute before respawning. ; This can be useful to work around memory leaks in 3rd party libraries. For ; endless request processing specify '0'. Equivalent to PHP_FCGI_MAX_REQUESTS. ; Default Value: 0 ;pm.max_requests = 500 这里自己配置的。 |
21
realityone 2018-05-16 10:28:31 +08:00
每天晚上低峰期重启下不就行了嘛
|
22
Kinnice 2018-05-16 10:30:23 +08:00 via Android
|
24
timchou 2018-05-16 10:41:38 +08:00
LZ,第一步,欢迎先使用 ifuptime 来监控网站 down 机情况,好让你第一时间知道 down 了
https://www.ifuptime.com 注册码:v2exifuptime0502 第二部,可能就需要去增加一些 debug 信息,来分析 down 机时候发生了什么,来具体分析了:) |
25
DavidNineRoc 2018-05-16 10:44:59 +08:00
探针?
|
26
defunct9 2018-05-16 10:49:04 +08:00 via iPhone
不开就自己搞定,无难度撒
|
27
onion83 2018-05-16 10:56:53 +08:00 2
12 楼的做法在某种意义上来是正确的,在业务低峰定时重启 PHP-FPM,也基本上有点经验运维的标准操作。
nginx+php-fpm 502 的问题,主要有两个: 1、php-fpm 的子进程数不够,无法再接受更多的请求(衍生思考:php-fpm 进程管理的三种模式 ) 2、因为业务原因:如慢查询、内核参数,程序本身 bug 导致,甚至是 php 自己 core 掉. 传统意义上监控,例如 ps aux 查看进程数,其实无法发现问题的,因为进程都在,只是它们都死了。 如果真的要监控,建议走 httpcheck 7 层的检查,直接检查是否包含指定内容,如果有负载均衡的话直接屏蔽掉。 开发视觉: ----------------- 如果确实要分析问题的话,可以通过三个参数 error_log、slowlog、request_slowlog_timeout 来定位,如有可能上日志分析或者自建 ELK,进行实时告警和分析. 运维视觉: ----------------- 关注 emergency_restart_interval、pm.max_requests、request_terminate_timeout 三个参数,尤其后者,可以作为对服务器资源保护的最后强制暴力手段。 “重启可以快速解决 90% 的问题” 对运维来说确实是最佳实践,对 PHP-FPM 尤其适用。 |
28
vus520 2018-05-16 11:04:35 +08:00
如果有多个 upstream,直接定时重启后端的 php-fpm 就行。
|
30
salmon5 2018-05-16 11:22:19 +08:00
supervisor+其插件 superlance 了解下,就别造轮子了
|
31
DRcoding 2018-05-16 11:28:05 +08:00
如果你只是想监控一个 http 返回状态,写个定时任务,发送一个 head 请求到你的域名或者 IP,然后买个短信接口,返回不是 200,就调用发短信的接口发短信呗。
另外,一般云服务厂商都是会提供这种简单的 http 监控功能,如我所知,阿里云。 |
32
opengps 2018-05-16 11:30:02 +08:00
2 月一次,应该不是 cpu 资源问题
关注下内存,系统句柄数,网络连接数,系统端口数等资源消耗情况,我以前的 socket 服务器,因为句柄的泄露,压力大的的时候,每周都需要手动重启下释放掉泄漏的句柄,直到后来找到问题,现在稳定运行,系统不死程序就不挂 |
33
fortunezhang 2018-05-16 11:52:53 +08:00
宝塔
一个客户用的宝塔,从来没有过假死情况。不过问题是和 lampp 的 php 不一样,具体说不出来,我遇到过几次。 很蛋疼。 |
35
lwldcr 2018-05-16 13:28:38 +08:00
prometheus 了解一下
|
36
xsec 2018-05-16 13:33:36 +08:00
内存泄露?
|
38
dorothyREN 2018-05-16 15:57:01 +08:00
两个月一次?那你计划任务每个月重启一次不就行了?
|
39
7sDream 2018-05-16 16:07:01 +08:00
https://github.com/firehol/netdata
我自己没试过,不负责任的推荐 |
40
jssyxzy 2018-05-16 16:28:23 +08:00
这个不就是 health check 么,搜搜一堆解决方案.
自己写, crontab + 脚本. |
43
dishuibaby 2018-05-16 17:25:52 +08:00
监控宝啊
|
44
vibbow 2018-05-16 17:28:13 +08:00
php-fpm 不是会自动回收的么?
|
45
liujinsong668 2018-05-16 17:33:46 +08:00
说个简单的恢复办法,自己写个 shell,定期 curl 这个网站的域名,一旦检测到状态不对,直接重启 php-fpm,可以恢复业务;但是最好找到问题的根源好一些,看看 php-fpm 的配置文件
|
46
vibbow 2018-05-16 17:37:19 +08:00
LZ 了解一下 PHP_FCGI_MAX_REQUESTS 这个参数
|
47
cabing 2018-05-16 18:40:32 +08:00
了解下 php-fpm 启动固定数目的进程
|
48
jsjscool 2018-05-16 18:43:13 +08:00
https://github.com/laynefyc/xhgui-branch 大厂都在用的 PHP 性能监控了解下
|
49
Aalen 2018-05-16 18:45:41 +08:00
关注一波 serverchan 吧,跟微信关联的
|
50
jimmyczm 2018-05-16 20:35:29 +08:00
我自己搭的 workpress 也会有这个问题,调整了 php frm 的参数就行了
|
51
cxbig 2018-05-16 20:47:41 +08:00
多数情况是因为 PHP 配置不当或代码问题导致内存泄漏
图省事可以监控 log 里的相关错误信息,到达一定阈值触发重启 fpm 服务 想追踪具体问题,得装系统监控工具 |
52
lfzyx 2018-05-16 20:52:35 +08:00
白盒监控了解一下?
|
53
musclepanda 2018-05-16 21:01:00 +08:00
我自己家的路由器我都设置凌晨 3 点重启下。。
|
54
shiny 2018-05-16 21:03:53 +08:00
这种直接阿里云监控添加一个监控任务就行了,出现问题短信、邮件、钉钉都可以通知你。
|
55
shiny 2018-05-16 21:05:46 +08:00
这种情况考虑下是不是可用的 fpm 进程耗尽。首先确定下内存是否耗完,如果有空余内存,可以调高最大进程数,然后把 fpm 的 status 也监控起来,观察下是不是有代码阻塞导致超时。
|
56
Admstor 2018-05-16 22:05:16 +08:00
运维路过
首先无论有没有故障,适当时机对服务进行重启都是有必要的,uptime 的意义在我看了除了秀一下也没啥,当然了 linux 本身健壮性挺好的,重启有关服务就 OK,更何况热补丁也是成熟技术,apache 用的少,nginx 下都有平滑重启,低峰时段对用户基本无感知 其次日志记录很重要,日志虽然会影响一部分性能,但是出现异常 /新版本上线之后都应该有适当提高日志等级的必要,尤其是没有 AB 测试. 然后监控系统很有必要,若自己没有监控系统,那么至少需要 2 个第三方监控作为相互监督,监控点也最好选择物理距离较远避免区域网络波动造成的异常报警,例如你在服务器在上海,主要客户群体在江浙沪,那么在选择在上海本地异地机房 /江浙沪范围内一个机房 /北京一个机房这样 3 个监测点相互检测,也大致可以提供整体网络波动情况 自动异常处理,楼上很多都说了,写个脚本之类,但是建议自动异常处理也要做一个日志输出,短时间频繁触发也是很不正常,需要进一步分析的 |