1 : An another FPM instance seems to already listen on /tmp/php-cgi.sock
有关/tem/php-cgi.sock问题
查看进程可以或者log文件可以看到php-fpm已正常运行
service php-fpm stop
Gracefully shutting down php-fpm warning,no pid file found – php-fpm is not running?
查看进程可以看到php-fpm进程未被关闭
问题原因:php-fpm.conf文件和/etc/init.d/php-fpm文件里的pid值设置不一致
2:NOTICE: PHP message: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/redis.so' - /usr/lib64/php/modules/redis.so: undefined symbol: zend_new_interned_string in Unknown on line 0
PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/redis.so' - /usr/lib64/php/modules/redis.so: undefined symbol: zend_new_interned_string in <b>Unknown</b> on line <b>0</b><br />
有关安装php 扩展redis后报错的问题。
注意查看extension的位置
extension_dir和extension
3 php启动后,9000端口没有起来
php服务安装后,启动php-fpm,启动的时候没有报错。
然后ps -ef|grep php没有发现进程起来,lsof -i:9000发现端口也没有起来。
查看日志,发现系统所允许打开的文件数超过了预定设置。
/usr/local/php/sbin/php-fpm
ps -ef|grep php
lsof -i:9000
查看错误日志发现问题
tail -f /usr/local/php5/var/log/php-fpm.log
[15-Nov-2015 23:53:15] NOTICE: fpm is running, pid 18277
[15-Nov-2015 23:53:15] ERROR: failed to prepare the stderr pipe: Too many
open
files (24)
[15-Nov-2015 23:53:16] NOTICE: exiting, bye-bye!
[15-Nov-2015 23:53:59] NOTICE: fpm is running, pid 18855
[15-Nov-2015 23:53:59] ERROR: failed to prepare the stderr pipe: Too many
open
files (24)
[15-Nov-2015 23:54:00] NOTICE: exiting, bye-bye!
发现是系统允许打开的文件数超了预定的设置。需要调大这个值
#ulimit -n
1024
#ulimit -n 65535 //临时解决办法
#ulimit -n
65535
永久解决办法:
在
/etc/security/limits
.conf文件底部添加下面四行内容:
# cat /etc/security/limits.conf
.........
# End of file
* soft nproc unlimited
* hard nproc unlimited
* soft nofile 65535
* hard nofile 65535
然后再次启动php-fpm程序,9000端口就能正常启动了
/usr/local/php/sbin/php-fpm
ps -ef|grep php
root 21055 1 0 00:12 ? 00:00:00 php-fpm: master process
(
/usr/local/php/etc/php-fpm
.conf)
nobody 21056 21055 0 00:12 ? 00:00:00 php-fpm: pool www
nobody 21057 21055 0 00:12 ? 00:00:00 php-fpm: pool www
之前将线上php服务升级到5.6.x版本后,php-error.log报出错误:
PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated
原因:
上面的报错意思是“自动变量$HTTP_RAW_POST_DATA已过时(deprecated)”
这个问题和PHP版本有关系,PHP5.6之后的高版本都已废弃了$HTTP_RAW_POST_DATA这个全局变量设置,可以使用 php:
//input
替代 $HTTP_RAW_POST_DATA。
使用always_populate_raw_post_data会导致在填充$HTTP_RAW_POST_DATA时产生E_DEPRECATED 错误。
设置always_populate_raw_post_data 为-1来体验新的行为,因为这样会强制 $HTTP_RAW_POST_DATA 未定义,所以也不会导致 E_DEPRECATED的错误) 来体验新的行为。
解决方法:
修改php.ini配置文件:
# vim php.ini
........
; Always populate the $HTTP_RAW_POST_DATA variable.
;always_populate_raw_post_data = On
always_populate_raw_post_data = -1
.......
然后重启php服务即可!
Warning: phpinfo(): It is not safe to rely on the system's timezone settings. You are
*required* to use the
date
.timezone setting or the date_default_timezone_set()
function
. In
case
you used any of those methods and you are still getting this
warning, you most likely misspelled the timezone identifier. We selected the
timezone
'UTC'
for
now, but please
set
date
.timezone to
select
your timezone.
in
/usr/local/www/zabbix2/phpinfo
.php on line 2
date
/time
support enabled
"Olson"
Timezone Database Version 2013.8
Timezone Database internal
Default timezone UTC
修改php.ini 文件
# vim /usr/local/php/etc/php.ini
........
[Date]
; Defines the default timezone used by the
date
functions
; http:
//php
.net
/date
.timezone
date
.timezone = Asia
/Shanghai
注意必须把要 php.ini 复制一份到
/usr/local/php/lib/
下,否则 php 服务默认会到这个 lib 目录下读取 php.ini 文件,
没有的话,就是默认时区UTC,这个时区和北京时间相差8小时。
[root@i-gxcmjlge lib]
# pwd
/usr/local/php/lib
[root@i-gxcmjlge lib]
# ll
total 72
drwxr-xr-x 14 root root 4096 Nov 18 01:11 php
-rw-r--r-- 1 root root 65681 Nov 18 15:01 php.ini
然后重启php服务和nginx
/apache
服务
request_terminate_timeout = 10
值如果设置为0或者过长的时间,可能会引起file_get_contents的资源问题。
如果访问请求的远程资源反应过慢,php-cgi进程就会一直卡在那里不会超时。虽然php.ini文件里面max_execution_time可以设置PHP脚本的最大执行时间,
但是,在php-cgi(php-fpm) 中该参数不会起效。真正能够控制PHP脚本最大执行时间的是php-fpm.conf配置文件中的request_terminate_timeout参数。
request_terminate_timeout默认值为0秒,也就是说,PHP脚本会一直执行下去。这样当所有的php-cgi进程都卡住时,这台Nginx+PHP的WebServer已经无法
再处理新的PHP请求了,Nginx 将给用户返回“502 Bad Gateway”。
修改该参数,设置一个PHP脚本最大执行时间是必要的,但是治标不治本。例如改成30s,如果发生访问获取网页内容较慢的情况,这就意味着150个php-cgi
进程,每秒钟只能处理5个请求,WebServer同样很难避免”502 Bad Gateway”。
解决办法是request_terminate_timeout设置为10s或者一个合理的值。
pm.max_requests = 1024
max_requests参数配置不当,可能会引起间歇性502错误
设置每个子进程重生之前服务的请求数. 对于可能存在内存泄漏的第三方模块来说是非常有用的.
如果设置为0,则一直接受请求,等同于php_fcgi_max_requests环境变量。默认值为 0.
比如:pm.max_requests = 1000 这个配置的意思是,当一个 php-cgi 进程处理的请求数累积到500个后,自动重启该进程。
但是为什么要重启进程呢?
一般在项目中,多多少少都会用到一些PHP的第三方库,这些第三方库经常存在内存泄漏问题,如果不定期重启php-cgi进程,势必造成内存使用量不断增长。
因此php-fpm作为php-cgi的管理器,提供了这么一项监控功能,对请求达到指定次数的php-cgi进程进行重启,保证内存使用量不增长。正是因为这个机制,
在高并发的站点中,经常导致502错误,
目前解决方法是,把这个值尽量设置大些,尽可能减少php-cgi重新SPAWN的次数,同时也能提高总体性能。在实际的生产环境中发现,内存泄漏如果不明显,
可以将这个值设置得非常大(比如204800)。要根据自己的实际情况设置这个值(比如我们线上设置1024),不能盲目地加大。
话说回来,这套机制目的只为保证php-cgi不过分地占用内存,为何不通过检测内存的方式来处理呢?通过设置进程的峰值内在占用量来重启php-cgi进程,
会是更好的一个解决方案。
3)php-fpm的慢日志,debug及异常排查神器
request_slowlog_timeout设置一个超时的参数,slowlog设置慢日志的存放位置
opcache_reset();
php启动了opcache的模块(php的代码优化和加速模块)!执行php-config命令可以看到php编译安装时跟了--
enable
-opcache参赛,
直接访问如下的php的测试文件:
#
cat
test
.php
<?php
phpinfo()
?>
可以看到界面中的“Zend OPcache”模块显示下面两行,表示opcache被启用了!
Opcode Caching Up and Running
Optimization Enabled
[root@iZwz96p8207vmn7amyxvw6Z ~]
# cat /usr/local/php/etc/php.ini|grep opcache
[opcache]
;opcache.
enable
=0
;opcache.enable_cli=0
;opcache.memory_consumption=64
;opcache.interned_strings_buffer=4
;opcache.max_accelerated_files=2000
;opcache.max_wasted_percentage=5
;opcache.use_cwd=1
;opcache.validate_timestamps=1
;opcache.revalidate_freq=2
;opcache.revalidate_path=0
;opcache.save_comments=1
;opcache.load_comments=1
;opcache.fast_shutdown=0
;opcache.enable_file_override=0
;opcache.optimization_level=0xffffffff
;opcache.inherited_hack=1
;opcache.dups_fix=0
;opcache.blacklist_filename=
;opcache.max_file_size=0
;opcache.consistency_checks=0
;opcache.force_restart_timeout=180
;opcache.error_log=
;opcache.log_verbosity_level=1
;opcache.preferred_memory_model=
;opcache.protect_memory=0
; opcache.validate_permission=0
; opcache.validate_root=0
[root@iZwz96p8207vmn7amyxvw6Z ~]
# /usr/local/php/bin/php -m
........
[Zend Modules]
Zend OPcache
the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured)
这就导致了php文件修改后,在浏览器里访问不会立马生效,需要过30秒左右才生效!因为有opcache缓存的原因!
解决办法:
在php文件内容的前面添加清理opcache的函数,即opcache_reset(); 如下:
[root@iZwz96p8207vmn7amyxvw6Z itime]
# cat test.php
<?php
opcache_reset();
//
这一行就是清理opcache缓存
echo
'hjhjhjhjhjh'
;
?>
这样访问
test
.php文件,当它的内容更新时,在新的浏览器页面里打开就是更新后的内容了。
如果在老页面里继续访问,第一次刷时清理缓存,第二次刷新就是更新后的内容了!