昨晚线上出故障,紧急处理切换容灾后缓解了故障,解决故障后从容灾切换回正式服务时发现PHP文件更新无效,重启FPM后才生效。下面记录复盘追查的过程。
因为是PHP文件更新不生效,所以马上怀疑到opcache上面,到线上看了一眼php.ini,果然使用了opcache,并且检测间隔时间设置为60秒。查看昨晚的日志,更新不生效持续时间远远大于60秒,所以这个检测间隔时间的问题可以PASS了,我们继续。
在线上环境查看更新的文件和日志中的时间的时候,突然发现PHP文件时间和日志中的时间对应不上,马上找OP确认,OP交待说这个文件是回滚mv回来的,所以文件时间和我预期的不一致。我用stat命令看了一下,果然modify time相比access time早了一段时间,依据这点线索推测opcache依靠的是PHP文件的modify time作为文件被修改的检测条件。在线下复现问题,填坑成功!
下面总结一下填坑过程中查的一些相关的知识点
加载opcache
在php.ini中增加opcache时需要使用zend_extension,而不是extension,不然会得到以下WARNING
PHP Warning: PHP Startup: Invalid library (appears to be a Zend Extension, try loading using zend_extension=opcache.so from php.ini) in Unknown on line 0
配置opcache
使用下列推荐设置来获得较好的性能:
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1
本次涉及到的有两个参数
revalidate_freq,默认2
检查脚本时间戳是否有更新的周期,以秒为单位。 设置为 0 会导致针对每个请求, OPcache 都会检查脚本更新
validate_timestamps,默认1
如果启用,那么 OPcache 会每隔 opcache.revalidate_freq 设定的秒数 检查脚本是否更新。 如果禁用此选项,你必须使用 opcache_reset() 或者 opcache_invalidate() 函数来手动重置 OPcache,也可以 通过重启 Web 服务器来使文件系统更改生效。
系统命令和函数stat
access time 表示我们最后一次访问文件的时间
modify time 表示我们最后一次修改文件的时间
change time 表示我们最后一次对文件属性改变的时间,包括权限,大小,属性等等
C/C++中也可以使用stat方法查询文件的这3个时间属性,一般应用都会通过modify time判断文件是否更新,我们本次踩坑就是因为文件是mv操作的,modity time没有更新,所以opcache没有更新。