[Linux主机] 优化你的php-fpm(php5.3+)让你的网站跑得更快

从php5.3以后php自带了php-fpm不是和php5.2一样以插件的方式存在了。这给我们带来一个好处502没有那么容易出现了
坛子里用linux的绝大多数应该还是在用小军的lnmp的那个包,但是配置优化却是不尽人意。
php-fpm的配置文件位置:
/usr/local/php/etc/php-fpm.conf
pid = run/php-fpm.pid
pid设置,默认在安装目录中的var/run/php-fpm.pid,建议开启
error_log = log/php-fpm.log
错误日志,默认在安装目录中的var/log/php-fpm.log
log_level = notice
错误级别. 可用级别为: alert(必须立即处理), error(错误情况), warning(警告情况), notice(一般重要信息), debug(调试信息). 默认: notice.
emergency_restart_threshold = 60
emergency_restart_interval = 60s
表示在emergency_restart_interval所设值内出现SIGSEGV或者SIGBUS错误的php-cgi进程数如果超过 emergency_restart_threshold个,php-fpm就会优雅重启。这两个选项一般保持默认值。
process_control_timeout = 0
设置子进程接受主进程复用信号的超时时间. 可用单位: s(秒), m(分), h(小时), 或者 d(天) 默认单位: s(秒). 默认值: 0.
daemonize = yes
后台执行fpm,默认值为yes,如果为了调试可以改为no。
在FPM中,可以使用不同的设置来运行多个进程池。 这些设置可以针对每个进程池单独设置。
listen = 127.0.0.1:9000
fpm监听端口,即nginx中php处理的地址,一般默认值即可。
可用格式为: ‘ip:port’, ‘port’, ‘/path/to/unix/socket’. 每个进程池都需要设置.
listen.backlog = -1
backlog数,-1表示无限制,由操作系统决定,此行注释掉就行。backlog含义参考:
listen.allowed_clients = 127.0.0.1
允许访问FastCGI进程的IP,设置any为不限制IP,如果要设置其他主机的nginx也能访问这台FPM进程,listen处要设置成本地可被访问的IP。默认值是any。
每个地址是用逗号分隔. 如果没有设置或者为空,则允许任何服务器请求连接
listen.owner = www
listen.group = www
listen.mode = 0666
unix socket设置选项,如果使用tcp方式访问,这里注释即可。
user = www
group = www
启动进程的帐户和组
pm = dynamic
pm表示使用那种方式,有两个值可以选择,就是static(静态模式)或者dynamic(动态模式5.2的时候叫apache-like但是不好使)
如果选择static,则由pm.max_children指定固定的子进程数。
如果选择dynamic,则由下开参数决定:
pm.max_children ,子进程最大数
pm.start_servers ,启动时的进程数
pm.min_spare_servers ,保证空闲进程数最小值,如果空闲进程小于此值,则创建新的子进程
pm.max_spare_servers ,保证空闲进程数最大值,如果空闲进程大于此值,此进行清理
对于专用服务器,pm可以设置为static。
pm.max_requests = 1000
设置每个子进程重生之前服务的请求数. 对于可能存在内存泄漏的第三方模块来说是非常有用的. 如果设置为 ’0′ 则一直接受请求. 等同于 PHP_FCGI_MAX_REQUESTS 环境变量. 默认值: 0.
pm.status_path = /status
FPM状态页面的网址. 如果没有设置, 则无法访问状态页面. 默认值: none.
ping.path = /ping
FPM监控页面的ping网址. 如果没有设置, 则无法访问ping页面. 该页面用于外部检测FPM是否存活并且可以响应请求. 请注意必须以斜线开头 (/)。
ping.response = pong
用于定义ping请求的返回相应. 返回为 HTTP 200 的 text/plain 格式文本. 默认值: pong.
request_terminate_timeout = 0
设置单个请求的超时中止时间. 该选项可能会对php.ini设置中的’max_execution_time’因为某些特殊原因没有中止运行的脚本有用. 设置为 ’0′ 表示 ‘Off’.
当经常出现502错误时可以尝试更改此选项。
request_slowlog_timeout = 10s
当一个请求该设置的超时时间后,就会将对应的PHP调用堆栈信息完整写入到慢日志中. 设置为 ’0′ 表示 ‘Off’
slowlog = log/$pool.log.slow
慢请求的记录日志,配合request_slowlog_timeout使用
rlimit_files = 1024
设置文件打开描述符的rlimit限制. 默认值: 系统定义值
系统默认可打开句柄是1024,可使用 ulimit -n查看,ulimit -n 2048修改。
rlimit_core = 0
设置核心rlimit最大限制值. 可用值: ‘unlimited’ 、0或者正整数. 默认值: 系统定义值.
chroot =
启动时的Chroot目录. 所定义的目录需要是绝对路径. 如果没有设置, 则chroot不被使用.
chdir =
设置启动目录,启动时会自动Chdir到该目录. 所定义的目录需要是绝对路径. 默认值: 当前目录,或者/目录(chroot时)
catch_workers_output = yes
重定向运行过程中的stdout和stderr到主要的错误日志文件中. 如果没有设置, stdout 和 stderr 将会根据FastCGI的规则被重定向到 /dev/null . 默认值: 空
下面已我的php配置例子:
[global]pid = /usr/local/php/var/run/php-fpm.pid
error_log = /home/wwwlogs/php-fpm.log
log_level = notice
rlimit_files = 65535
rlimit_core = 0
[www]
listen = /tmp/php-cgi.sock
user = nobody  nginx, php-fpm进程的权限不能以网站所有权运行安全有问题
group = nobody  nginx, php-fpm进程的权限不能以网站所有权运行安全有问题
pm = dynamic
pm.max_children = 36 静态模式开启进程数
pm.start_servers = 9 动态模式默认开启进程 数
pm.min_spare_servers = 8 动态模式默认最低保留进程 数
pm.max_spare_servers = 36 动态模式默认最高 进程数具体通过netstat -napo |grep "php-fpm" | wc -l和系统负载确定
pm.max_requests = 4096 进程执行xxx后重启释放内存避免内存泄漏
request_terminate_timeout = 100 进程超时时间
request_slowlog_timeout = 3s 记录大于3秒的php执行命令
slowlog = /home/wwwlogs/php-fpm.log.slow
rlimit_files = 65535 这个值一定要改默认的太小不改日志会有错误但是要和全局文件数相同具体查看ulimit -n系统全局设置
rlimit_core = 0

-----------------------------------------------------------------------------------------------------------

[global]

pid = /usr/local/php/var/run/php-fpm.pid

error_log = /home/wwwlogs/php-fpm.log

log_level = notice

rlimit_files = 65535

rlimit_core = 0

[www]

listen = /tmp/php-cgi.sock

user = nobody

group = nobody

pm = dynamtic

pm.max_children = 20

pm.start_servers = 2

pm.min_spare_servers = 1

pm.max_spare_servers = 20

pm.max_requests = 4096

request_slowlog_timeout = 3s

slowlog = /home/wwwlogs/php-fpm.log.slow

request_terminate_timeout = 100

rlimit_files = 65535

rlimit_core = 0

时间: 2024-10-22 00:53:39

[Linux主机] 优化你的php-fpm(php5.3+)让你的网站跑得更快的相关文章

辛星让mysql跑的更快第一节之优化的方向和数据库建模

最近计划写一套书目,也就是关于mysql的优化的,那么首先在博客上写写,然后整理成pdf的文档的形式,当然也期待各位的关注了.对于mysql的优化是一个比较大的话题,可优化的地方也很多,大致想了一下,可以从这些地方下手. 首先就是硬件层次,包括选择合适的操作系统.选择合适的硬件,然后就是源码层次,不过虽然mysql是开源的,但是能够修改其源代码的公司虽然不少,但是也没有那么多,但是我们可以选择更加合适的编译器重新编译其源代码,然后就是设计到表的设计,也就数据库建模. 其次可以考虑使用一些其他技术

【MySQL】10条SQL优化语句,让你的MySQL数据库跑得更快!

慢SQL消耗了70%~90%的数据库CPU资源: SQL语句独立于程序设计逻辑,相对于对程序源代码的优化,对SQL语句的优化在时间成本和风险上的代价都很低: SQL语句可以有不同的写法: 1 不使用子查询 例:SELECT * FROM t1 WHERE id (SELECT id FROM t2 WHERE name='hechunyang'); 子查询在MySQL5.5版本里,内部执行计划器是这样执行的:先查外表再匹配内表,而不是先查内表t2,当外表的数据很大时,查询速度会非常慢.在Mari

10条SQL优化语句,让你的MySQL数据库跑得更快!

慢SQL消耗了70%~90%的数据库CPU资源: SQL语句独立于程序设计逻辑,相对于对程序源代码的优化,对SQL语句的优化在时间成本和风险上的代价都很低: SQL语句可以有不同的写法: 1 不使用子查询 例:SELECT * FROM t1 WHERE id (SELECT id FROM t2 WHERE name='hechunyang'); 子查询在MySQL5.5版本里,内部执行计划器是这样执行的:先查外表再匹配内表,而不是先查内表t2,当外表的数据很大时,查询速度会非常慢.在Mari

代码示例:一些简单技巧优化JavaScript编译器工作详解,让你写出高性能运行的更快JavaScript代码

告诉你一些简单的技巧来优化JavaScript编译器工作,从而让你的JavaScript代码运行的更快.尤其是在你游戏中发现帧率下降或是当垃圾回收器有大量的工作要完成的时候. 单一同态: 当你定义了一个两个参数的函数,编译器会接受你的定义,如果函数参数的类型.个数或者返回值的类型改变编译器的工作会变得艰难.通常情况下,单一同态的数据结构和个数相同的参数会让你的程序会更好的工作. function example(a, b) { // 期望a,b都为数值类型 console.log(++a * +

Yahoo Web 应用性能及linux内核优化黄金法则详解

Web 应用性能优化黄金法则:先优化前端程序(front-end) 的性能,因为这是80% 或以上的最终用户响应时间的花费所在. 法则1. 减少HTTP 请求次数80%的最终用户响应时间花在前端程序上,而其大部分时间则花在各种页面元素,如图像.样式表.脚本和Flash等,的下载上.减少页面元素将会减少HTTP请求次数.这是快速显示页面的关键所在.一种减少页面元素个数的方法是简化页面设计.但是否存在其他方式,能做到既有丰富内容,又能获得快速响应时间呢?以下是这样一些技术:Image maps 组合

[转]linux内核优化sysctl.conf参数优化

################### 所有rfc相关的选项都是默认启用的,因此网上的那些还自己写rfc支持的都可以扔掉了:) ############################### net.inet.ip.sourceroute=0 net.inet.ip.accept_sourceroute=0 ############################# 通过源路由,攻击者可以尝试到达内部IP地址 --包括RFC1918中的地址,所以 不接受源路由信息包可以防止你的内部网络被探测.

Linux 性能优化之 IO 子系统 系列 图

http://blog.sina.com.cn/s/articlelist_1029388674_11_1.html Linux 性能优化之 IO 子系统(一) 本文介绍了对 Linux IO 子系统性能进行优化时需要考虑的因素,以及一些 IO 性能检测工具. 本文的大部分内容来自 IBM Redbook - Linux Performance and Tuning Guidelines FileSystem VFS(Virtual FileSystem) 虚拟文件系统 文件系统是内核的功能,是

linux性能优化cpu 磁盘IO MEM

系统优化是一项复杂.繁琐.长期的工作,优化前需要监测.采集.测试.评估,优化后也需要测试.采集.评估.监测,而且是一个长期和持续的过程,不 是说现在优化了,测试了,以后就可以一劳永逸了,也不是说书本上的优化就适合眼下正在运行的系统,不同的系统.不同的硬件.不同的应用优化的重点也不同. 优化的方法也不同.优化的参数也不同.性能监测是系统优化过程中重要的一环,如果没有监测.不清楚性能瓶颈在哪里,怎么优化呢?所以找到性能 瓶颈是性能监测的目的,也是系统优化的关键.系统由若干子系统构成,通常修改一个子系

Linux主机性能监测

Linux主机作为服务器,在很多高并发的场景下,需要对系统参数进行优化来提升主机性能.而确认主机的性能瓶颈点在哪里就非常重要了,这里主要在以下几个方面进行说明: 1.CPU 2.内存 3.磁盘 4.网络 下面就这几个方面借助网友的经验,简单的总结一下.内容主要来自http://www.vpsee.com/ CPU的监测 在确定是否需要对系统进行优化时,我们首先需要确认系统CPU目前的负载状态.我们可以使用 vmstat命令来查看当前系统的负载. vmstat 工具提供了一种低开销的系统性能观察方