day106 NGINX优化

Nginx性能优化实践

1.性能优化概述

2.系统性能优化

3.代理服务优化

4.静态资源优化

• 4.1 静态资源缓存
• 4.2 静态资源读取
• 4.3 静态资源压缩
• 4.4 静态资源防盗链
• 4.5 静态资源防爬⾍
• 4.6 CPU亲和配置

5.Nginx配置总结

6.PHP服务优化

• 6.1 PHP配置⽂件
• 6.2 PHP监控模块
• 6.3 PHP⽇志管理
• 6.4 PHP最终配置

本章课程内容⼤纲

1.性能优化概述

基于Nginx性能优化，我们将分为如下⼏个⽅⾯来做介绍
1.⾸先我们需要了解性能优化要考虑哪些⽅⾯。
2.然后我们需要了解会影响Nginx性能的⼀些指标。
3.最后我们需要了解优化系统以及Nginx服务的哪些⽅⾯。

1.在做性能优化⼯作前，我们重点需要考虑哪些⽅⾯，和了解哪些⽅⾯。

1.⾸先需要了解我们当前系统结构和瓶颈，了解当前使⽤的是什么，运⾏的是什么业务，都有哪些服务，了解每个服务最⼤能⽀撑多⼤并发。⽐如Nginx作为静态资源服务的并发是多少，最⾼瓶颈在哪⾥，能⽀持多少qps(每秒查询率)的访问请求，那我们怎么得出这组系统结构瓶颈呢，⽐如top查看系统的cpu负载、内存使⽤率、总的运⾏进程等，也可以通过⽇志去分析请求的情况，当然也可以通过我们前⾯介绍到的stub_status模块查看当前的连接情况，也可以对线上低峰期的业务进⾏压⼒测试，去了解当前这套系统能承担多少的请求和并发，已做好相应的评估。这个是我们做性能优化最先考虑的地⽅。

2.其次我们需要了解业务模式，我们的性能优化其实是为业务所提供服务的，所以需要了解每个业务接⼝的类型，⽐如:电商⽹站中的抢购模式，平时没什么流量，但到了抢购时间流量会突增。 同时我们还需要了解系统结构，⽐如: 我们使⽤Nginx做的是代理、还是动静分离、还是后端直接服务⽤户，那么这个就需要我们对每⼀层做好相应的梳理。以便更好的服务业务。

3.最后我们需要考虑性能与安全，往往注重了性能，但是忽略了安全。往往过于注重安全，性能⼜会产⽣影响。⽐如:我们在设计防⽕墙功能时，检测过于严密，这样就会给性能带来影响。那么如果对于性能完全追求，却不顾服务的安全，这个也会造成很⼤的隐患，所以需要评估好两者的关系，权衡好对应的点。

2.影响Nginx性能的⼀些指标

1.硬件层⾯需要了解: 磁盘损坏、磁盘速率。
1.⽹络层⾯需要了解: ⽹络带宽、⽹络是否丢包、因为这些都会影响http的请求与调⽤。
2.系统层⾯需要了解: 系统负载、系统内存，以及系统整体的稳定性。
3.服务层⾯需要了解: 连接与请求的限速，同时还需要根据业务形态做对应的服务设置。
4.程序层⾯需要了解: 接⼝性能、处理速度、程序执⾏效率。
5.数据层⾯需要了解: 数据库。

PS: 每个服务与服务之间都或多或少有⼀些关联, 我们需要将整个架构进⾏分层, 找到对应系统或服务的短板, 然后进⾏优化

2.系统性能优化

⽂件句柄, Linux⼀切皆⽂件，⽂件句柄可以理解为就是⼀个索引，⽂件句柄会随着我们进程的调⽤频繁增加，系统默认⽂件句柄是有限制的，不能让⼀个进程⽆限的调⽤，所以我们需要限制每个进程和每个服务使⽤多⼤的⽂件句柄，⽂件句柄也是必须要调整的优化参数。
⽂件句柄的设置⽅式，
1.系统全局性修改。
2.⽤户局部性修改。
3.进程局部性修改

[root@nginx ~]# vim /etc/security/limits.conf
#针对root⽤户，soft仅提醒，hard限制，nofile打开最⼤⽂件数
# *代表所有⽤户
* soft nofile 25535
* hard nofile 25535
root soft nofile 65535
root hard nofile 65535
#针对Nginx进程
worker_rlimit_nofile 65535;

内核参数优化

[root@web01 ROOT]# vim /etc/sysctl.conf
net.ipv4.ip_local_port_range = 10240 61000 #调整系统能使⽤的端⼝数量
net.core.somaxconn = 1024 #默认128，连接队列
net.ipv4.tcp_fin_timeout = 10 #time_wait的超时时间
net.ipv4.tcp_tw_reuse = 1 #重新使⽤time_wait的连接
net.ipv4.tcp_timestamps = 1
[root@web01 ROOT]# sysctl -p

3.代理服务优化

通常Nginx作为代理服务，负责代理⽤户的请求，那么在代理的过程中建议开启HTTP⻓连接，⽤于减少握⼿次数，降低服务器损耗。

1.⻓连接语法示例,(应⽤层⾯优化)

Syntax: keepalive connections;
Default: —
Context: upstream
Syntax: keepalive_requests number; #keepalive_requests设置通过⼀个keepalive连
接提供的最⼤请求数。在发出最⼤请求数后，将关闭连接。
Default: keepalive_requests 100;
Context: upstream
Syntax: keepalive_timeout timeout; #keepalive_timeout超时，在此期间与代理服务器的
空闲keepalive连接将保持打开状态。
Default: keepalive_timeout 60s;
Context: upstream

2.配置Nginx代理服务使⽤⻓连接⽅式NGINX ⽀持 Keepalive ⻓连接

upstream http_backend {
 server 127.0.0.1:8080;
 server 127.0.0.1:8081;
 keepalive 32; #Nginx到应⽤服务器的连接池⾥⾯最⼤的空闲⻓连接数。也就是最
多有32个空闲的⻓连接
 keepalive_requests 100; #Nginx到应⽤应⽤服务器的⼀个⻓连接最多可承载处理的HTTP请求
个数，最多处理100个，到100个后⾃动关闭该连接，有需要Nginx会再⽣成新的⻓连接
 keepalive_time 60s; #keepalive_timeout超时，在60s时间内代理服务器的空闲
keepalive连接将保持打开状态
}
server {
 ...
 location /http/ {
 proxy_pass http://http_backend;
 proxy_http_version 1.1; #这⾥设置了proxy代理的协议，如果没有设置的化
默认是1.0。只有http1.1后才增加了⻓连接的⽀持。
 proxy_set_header Connection ""; #清除“connection”头字段，是清理从 Client
过来的 http header，因为即使是 Client 和 NGINX 之间是短连接，NGINX 和 upstream 之间也
是可以开启⻓连接的。这种情况下必须清理来⾃ Client 请求中的 “Connection” header。

 #proxy_params代理优化参数[此前已讲，不再复述]
 proxy_set_header Host $http_host;
 proxy_set_header X-Forwared-For $proxy_add_x_forwarded_for;
 proxy_connect_timeout 30s; # 代理连接web超时时间
 proxy_read_timeout 60s; # 代理等待web响应超时时间
 proxy_send_timeout 60s; # web回传数据⾄代理超时时间
 proxy_buffering on; # 开启代理缓冲区,web回传数据⾄缓冲区,代理边收边传返回
给客户端
 proxy_buffer_size 32k; # 代理接收web响应的头信息的缓冲区⼤⼩
 proxy_buffers 4 128k; # 缓冲代理接收单个⻓连接内包含的web响应的数量和⼤⼩

 #异常后的超时与重试机制
 proxy_next_upstream error timeout http_500 http_502 http_503 http_504; #
重试upstream中的下⼀台后端
 proxy_next_upstream_timeout 6s; #重试次数的总时间超出了6s
 proxy_next_upstream_tries 3; #重试3次(但因为之前已经请求1次了，所以还能重试2次)，
则表示重试失败
 }
}

3.对于fastcgi服务器，需要设置fastcgi_keep_conn以便保持⻓连接

upstream fastcgi_backend {
 server 127.0.0.1:9000;
 keepalive 16; #Nginx到应⽤服务器的连接池⾥⾯最⼤的空闲⻓连接数。也就是最多有16个空
闲的⻓连接
}
server {
 ...
 location /fastcgi/ {
 fastcgi_pass fastcgi_backend;
 fastcgi_keep_conn on; #开启保持⻓连接
 fastcgi_connect_timeout 600; #指定连接到后端FastCGI的超时时间
 fastcgi_send_timeout 600; #向FastCGI传送请求的超时时间
 fastcgi_read_timeout 600; #指定接收FastCGI应答的超时时间
 fastcgi_buffer_size 64k;
 fastcgi_buffers 4 64k;
 fastcgi_busy_buffers_size 128k;

 #异常后的超时与重试机制
 fastcgi_next_upstream error timeout http_500 http_502 http_503 http_504;
#重试upstream中的下⼀台后端
 fastcgi_next_upstream_timeout 6s; #重试次数的总时间超出了6s
 fastcgi_next_upstream_tries 3; #重试了3次(因为之前已经请求1次了，所以还能重试2 次)，则表示重试失败.
 }
}

Nginx作为代理服务总结:

1.scgi和uwsgi协议没有保持连接的概念。
2.但⽆论是proxy、fastcgi、uwsgi协议都有 cache 缓存的功能，开启后可减少⽹站重复请求所带来的压⼒。
但需要注意的是:
proxy_cache的作⽤是缓存后端服务器的内容，可能是任何内容，包括静态的和动态，减少nginx与后端通信的次数，节省了传输时间和后端宽带。
fastcgi_cache的作⽤是缓存fastcgi⽣成的内容，很多情况是php⽣成的动态的内容，少了nginx与php的通信的次数，更减轻了php和数据库(mysql)的压⼒。

4.静态资源优化

Nginx作为静态资源Web服务器，⽤于静态资源处理，传输⾮常的⾼效

image

静态资源指的是，⾮WEB服务器端运⾏处理⽽⽣成的⽂件

静态资源类型     种类
浏览器渲染    HTML、CSS、JS
图⽚⽂件      JPEG、GIF、PNG
视频⽂件      FLV、Mp4、AVI
其他⽂件      TXT、DOC、PDF、...

4.1 静态资源缓存

浏览器缓存设置⽤于提⾼⽹站性能，尤其是新闻⽹站, 图⽚⼀旦发布，改动的可能是⾮常⼩的。所以我们希望能否⽤户访问⼀次后，图⽚缓存在⽤户的浏览器⻓时间缓存。 浏览器是有⾃⼰的缓存机制，它是基于HTTP协议缓存机制来实现的，在HTTP协议中有很多头信息，那么实现浏览器的缓存就需要依赖特殊的头信息来与服务器进⾏特殊的验证，如: Expires (http/1.0) ； Cache-control (http/1.1)。Nginx静态资源缓存参考
1.浏览器⽆缓存

image

2.浏览器有缓存

image

3.浏览器缓存过期校验检查机制，说明如下:
1.浏览器请求服务器会先进⾏Expires、Cache-Control的检查，检查缓存是否过期，如果没有过期则直接从缓存⽂件中读取。
2.如果缓存过期，⾸先检查是否存在etag，如果存在则会客户端会向web服务器请求if-None-Match，与etag值进⾏⽐对，由服务器决策返回200还是304。
3.如果etag不存在，则进⾏last-Modified检查，客户端会向web服务器请求If-Modified�Since，与last-Modified进⾏⽐对，由服务器决策返回200还是304。

image

4.如何配置静态资源缓存expires

#作⽤: 添加Cache-Control Expires头
Syntax: expires [modified] time;
expires epoch | max | off;
Default: expires off;
Context: http, server, location, if in location

5.配置静态资源缓存场景

server {
 listen 80;
 server_name static.bgx.com;

 location ~ .*\.(jpg|gif|png)$ {
 expires 7d;
 }
}

6.如果开发代码没有正式上线时, 希望静态⽂件不被缓存

#取消js css html等静态⽂件缓存
location ~ .*\.(css|js|swf|json|mp4|htm|html)$ {
 add_header Cache-Control no-store;
 add_header Pragma no-cache;
}

4.2 静态资源读取
1.⽂件读取⾼效sendfile，如下图

Syntax: sendfile on | off;
Default: sendfile off;
Context: http, server, location, if in location

image

传统读取⽂件⽅式 VS sendfile读取⽂件⽅式
2.将多个包⼀次发送，⽤于提升⽹络传输效率，⼤⽂件推荐打开，需要开启sendfile才⾏

Syntax: tcp_nopush on | off;
Default: tcp_nopush off;
Context: http, server, location

3.提⾼⽹络传输实时性，需要开启keepalive

Syntax: tcp_nodelay on | off;
Default: tcp_nodelay on;
Context: http, server, location

4.3 静态资源压缩

Nginx将响应报⽂发送⾄客户端之前启⽤压缩功能，然后进⾏传输，这能够有效地节约带宽，并提⾼响应⾄客户端的速度。
1.gzip传输压缩，传输前压缩，传输后解压

Syntax: gzip on | off;
Default: gzip off;
Context: http, server, location, if in location

2.gzip压缩哪些类型的⽂件

Syntax: gzip_types mime-type ...;
Default: gzip_types text/html;
Context: http, server, location

3.gzip压缩⽐率，加快传输，但压缩本身⽐较耗费服务端性能

Syntax: gzip_comp_level level;
Default: gzip_comp_level 1;
Context: http, server, location

4.gzip压缩协议版本，压缩使⽤在http哪个协议, 主流选择1.1版本

Syntax: gzip_http_version 1.0 | 1.1;
Default: gzip_http_version 1.1;
Context: http, server, location

4.静态图⽚配置压缩案例

[root@Nginx conf.d]# mkdir -p /code/
[root@Nginx conf.d]# cat static_server.conf
server {
 listen 80;
 server_name static.oldboy.com;
 location ~* .*\.(jpg|gif|png)$ {
 root /code/images;
 gzip on;
 gzip_http_version 1.1;
 gzip_comp_level 2;
 gzip_types image/jpeg image/gif image/png; 
 }
 }

5.测试没有开启gzip图⽚压缩

image

6.启⽤ gzip 压缩图⽚后(由于图⽚之前压缩过, 所以压缩⽐率不太明显)

image

7.⽂件压缩案例

[root@Nginx conf.d]# mkdir -p /code/doc
[root@Nginx conf.d]# cat static_server.conf
server {
 listen 80;
 server_name static.oldxu.com;
 root /code/doc;

 location ~ .*\.(txt|pdf)$ {
 gzip on;
 gzip_http_version 1.1;
 gzip_comp_level 1;
 gzip_types text/plain application/pdf;
 }
}

没有启⽤ gzip ⽂件压缩

image

启⽤ gzip 压缩⽂件

image

4.4 静态资源防盗链

防盗链，指的是防⽌资源被其他⽹站恶意盗⽤。
基础防盗链设置思路:

• 主要是针对客户端请求过程中所携带的⼀些Header信息来验证请求的合法性，⽐如客户端在请求的过程中都会携带referer信息(referer会告诉服务器我是丛哪⼀个⻚⾯过来的)。
• 优点是规则简单，配置和使⽤都很⽅便，缺点是防盗链所依赖的Referer验证信息是可以伪造的，所以通过Referer信息防盗链并⾮100%可靠， 但是它能够限制⼤部分的盗链情况。
  1.在盗链服务器上准备html⽂件,偷取fj.xuliangwei.com⽹站上的图⽚

[root@Nginx ~]# cat /etc/nginx/conf.d/
server {
 listen 80;
 server_name image.oldboy.com;
 location / {
 root /code;
 index index.html;
 }
}#准备⽹站
[root@Nginx ~]# cat /code/referer_test.html


 
 


 

2.使⽤浏览器能正常访问到偷链的后的图⽚资源
3.在kt.xuliangwei.com服务器上开启基于referer的防盗链规则

Syntax: valid_referers none | blocked | server_names | string ...;
Default: —
Context: server, location
#none: Referer来源头部为空的情况
#blocked: Referer来源头部不为空，这些值都不以http://或者https://开头，直接填写允许的域名
即可
#server_names: 来源头部包含当前的域名,可以正则匹配
#配置示例
location ~ .*\.(jpg|jpeg|gif|png)$ {
 #来源域名如何合法，invalid_referer这个变量被设置为0，否则设置为1
 valid_referers none blocked *.xuliangwei.com;

 #如果invalid_referer为1则返回403
 if ($invalid_referer) {
 return 403;
 }
}

以上配置表示: 所有来⾃*.xuliangwei.com都可以访问到fj.xuliangwei.com站点的图⽚，如果来源域名不在这个列表中，那么$invalid_referer等于1，在if语句中返回⼀个403给⽤户， 这样⽤户便会看到⼀个403的⻚⾯

4.使⽤浏览器验证会发现恶意的来源⽹站已经⽆法正常盗链
5.如果不想直接返回403，⽽希望优雅的返回⼀张图⽚给⽤户，那么可以使⽤rewrite跳转，如下示例返回/public/ks.jpeg图⽚给⽤户

location ~ .*\.(jpg||jpeg|gif|png)$ {
 valid_referers none blocked *.xuliangwei.com;

 if ($invalid_referer) {
 rewrite ^(.*)$ /public/ks.jpeg break;
 }
}

6.再次进⾏盗链的⽅式访问图⽚，则不再返回403，⽽是⼀张图⽚。
7.如果希望 google、baidu、等站点能够（盗链）资源，那么则可以通过server_names开放

location ~* \.(gif|jpg|png|bmp)$ {
 valid_referers none blocked *.xuliangwei.com server_names ~\.google\.
~\.baidu\.;
 if ($invalid_referer) {
 return 403;
 }
}

8.当然这种防护并不能百分百保证资源被盗链，因为我们可以通过命令修改来源的refrer信息。

4.5 静态资源防爬⾍

场景⼀代码示例:通过user_agent防⽌搜索引擎的爬取

server {
 ...
 if ($http_user_agent ~* "YisouSpider|YoudaoBot|tt") {
 return 403;
 }
 ....
}

场景⼆代码示例: 通过user_agent拦截压测测试⼯具

server {
 ...
 if ($http_user_agent ~* "Wget|ApacheBench") {
 set $block_user_agent 1;
 }
 if ($block_user_agent = 1){
 return 403;
 }
 ...
}

测试 1.curl -A "YisouSpider1.0" -I URL 2.curl -A "ApacheBench" -I URL 3.curl -A "wget" -I URL

4.6 CPU亲和配置

CPU亲和(affinity)减少进程之间不断频繁切换，减少性能损耗，其实现原理是将CPU核⼼和Nginx⼯作进程绑定⽅式，把每个worker进程固定对应的cpu上执⾏，减少切换cpu的cache miss，获得更好的性能。

image

1.查看当前CPU物理状态

[root@nginx ~]# lscpu |grep "CPU(s)"
CPU(s): 24
On-line CPU(s) list: 0-23
NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,20,22
NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,21,23
#本次演示服务器为两颗物理cpu，每颗物理CPU12个核⼼, 总共有24个核⼼

2.将Nginx worker进程绑⾄不同的核⼼上，官⽅建议与cpu的核⼼保持⼀致

# 第⼀种绑定组合⽅式
worker_processes 24;
worker_cpu_affinity 000000000001 000000000010 000000000100 000000001000
000000010000 000000100000 000001000000 000010000000 000100000000 001000000000
010000000000 10000000000;
# 第⼆种⽅式(使⽤较少)
worker_processes 2;
worker_cpu_affinity 101010101010 010101010101;
# 最佳⽅式绑定⽅式
worker_processes auto;
worker_cpu_affinity auto;

3.查看 nginx worker 进程绑定⾄对应 cpu

ps -eo pid,args,psr|grep [n]ginx

4.设置nginx worker进程的静态优先级，尽可能让nginx⼀直使⽤cpu

worker_priority number;
#默认值是0，可以设置为-20，减少cpu上下⽂切换的次数

5.Nginx配置总结

1.Nginx通⽤的主配置⽂件nginx.conf，包含静态资源优化

[root@nginx ~]# cat nginx.conf
user www; # nginx进程启动⽤户
worker_processes auto; #与cpu核⼼⼀致即可
worker_cpu_affinity auto; # cpu亲和
error_log /var/log/nginx/error.log warn; #错误⽇志
pid /run/nginx.pid;
worker_rlimit_nofile 35535; #每个work能打开的⽂件描述符，调整⾄1w以上,负荷较⾼建议
2-3w
events {
 use epoll; # 使⽤epoll⾼效⽹络模型
 worker_connections 10240; # 限制每个worker进程能处理多少个连接，10240x[cpu核 ⼼] }
http {
 include mime.types;
 default_type application/octet-stream;
 charset utf-8; # 统⼀使⽤utf-8字符集
 # 定义⽇志格式
 log_format main '$remote_addr - $remote_user [$time_local] "$request" '
 '$status $body_bytes_sent "$http_referer" '
 '"$http_user_agent" "$http_x_forwarded_for"';

 access_log /var/log/nginx/access.log main; # 访问⽇志

 server_tokens off; # 禁⽌浏览器显示nginx版本号
 client_max_body_size 200m; # ⽂件上传⼤⼩限制调整

 # ⽂件⾼效传输，静态资源服务器建议打开
 sendfile on;
 tcp_nopush on;

 # ⽂件实时传输，动态资源服务建议打开,需要打开keepalived
 tcp_nodelay on;
 keepalive_timeout 65;

 # Gzip 压缩
 gzip on;
 gzip_complevel 2;
 gzip_disable "MSIE [1-6]\.";
 gzip_http_version 1.1;
 gzip_types .....;
 # 虚拟主机
 include /etc/nginx/conf.d/*.conf;
}

4.⾯试：你对Nginx有做过哪些⽅⾯的优化，能简单说说吗?

1. 调整cpu亲和、worker进程数、以及Nginx⽂件描述符
2. 使⽤epool⽹络模型、调整每个worker进程的最⼤连接数
3. 使⽤⽂件⾼效读取sendfile、nopush、⽂件实时性nodealy、keepalive
4. 使⽤tcp⻓链接、同时调整keepalive_timeout⻓连接超时时间
5. 针对静态资源进⾏浏览器缓存expores、以及gzip压缩，当然还是建议CDN
6. 隐藏当前Nginx软件版本号，避免暴露版本所带来的攻击 7) 使⽤全站https、确保⽹站的数据传输安全
7. 禁⽌通过IP地址直接访问⽹站，只允许域名访问
8. 基于refere实现的放盗链，避免恶意盗链所带来的流量攻击。⾄于跨域访问(根据实际情况)
9. 限制IP地址每秒连接数，以及每秒请求数limit
10. 优雅的返回错误⻚⾯信息(如404、403)
11. nginx proxy_cache、fastcgi_cache、uwsgi_cache缓存
12. 差不多就⾏了， 重点：优化思路-->具体的⾏为事例 star。

6.PHP服务优化

6.1 PHP配置⽂件

1.php程序配置管理⽂件/etc/php.ini，主要调整⽇志、⽂件上传、禁⽌危险函数、关闭版本号显示、等

#实际上公司的php开发⼈员会在代码中指定php错误⽇志输出的位置。
#;;;;;;;;;;;;;;;;;
# Error logging ; #错误⽇志设置
#;;;;;;;;;;;;;;;;;
error_reporting = E_ALL # 记录PHP所有错误⽇志
log_errors = On # 开启错误⽇志
log_errors_max_len = 1024 #
error_log = /var/log/php_error.log # 错误⽇志存储路径
display_error = Off # 错误信息会在浏览器显示，⽣产环境建议关闭
expose_php = Off # 关闭php版本信息
date.timezone = Asia/Shanghai # 调整时区,默认PRC
#;;;;;;;;;;;;;;;
# File Uploads ; #⽂件上传设置
#;;;;;;;;;;;;;;;
file_uploads = On # 允许⽂件上传
upload_max_filesize = 300M # 允许上传⽂件的最⼤⼤⼩
post_max_size = 300M # 允许客户端单个POST请求发送的最⼤数据
max_file_uploads = 20 # 允许同时上传的⽂件的最⼤数量
memory_limit = 128M # 每个脚本执⾏最⼤内存
#php禁⽌危险函数执⾏(取决于实际情况，需要和开发沟通)
disable_functions = chown,chmod,pfsockopen,phpinfo

php危险函数禁⽤参考列表
2.php-fpm进程管理配置⽂件/etc/php-fpm.conf

#第⼀部分，fpm配置
[root@nginx ~]# cat /etc/php-fpm.conf
....
;include=etc/fpm.d/*.conf
....
#第⼆部分，全局配置
[root@nginx ~]# cat /etc/php-fpm.d/www.conf
[global]
;pid = /var/log/php-fpm/php-fpm.pid #pid⽂件存放的位置
;error_log = /var/log/php-fpm.log #错误⽇志存放的位置
;log_level = error #⽇志级别, alert, error, warning, notice,
debug
rlimit_files = 65535 #php-fpm进程能够使⽤的⽂件描述符
#第三部分，进程池定义
[www] #池名称
user = www #进程运⾏的⽤户
group = www #进程运⾏的组
;listen = /dev/shm/php-fpm.sock #监听在本地socket⽂件
listen = 127.0.0.1:9000 #监听在本地tcp的9000端⼝
;listen.allowed_clients = 127.0.0.1 #允许访问FastCGI进程的IP，any不限制
pm = dynamic #动态调节php-fpm的进程数
pm.max_children = 512 #最⼤启动的php-fpm进程数 （峰值就到512个进程）
pm.start_servers = 32 #初始启动的php-fpm进程数
pm.min_spare_servers = 32 #最少的空闲php-fpm进程数
pm.max_spare_servers = 64 #最⼤的空闲php-fpm进程数
pm.max_requests = 1500 #每⼀个进程能响应的请求数
pm.process_idle_timeout = 15s;
#第四部分，⽇志相关
php_flag[display_errors] = off
php_admin_value[error_log] = /var/log/phpfpm_error.log
php_admin_flag[log_errors] = on
#fpm慢⽇志
request_slowlog_timeout = 5s #php脚本执⾏超过5s的⽂件
slowlog = /var/log/php_slow.log #记录⾄该⽂件中

6.2 PHP监控模块

3.php-fpm监控模块，⽤于监控php-fpm状态使⽤

[root@nginx ~]# vim /etc/php-fpm.d/www.conf
pm.status_path = /phpfpm_status #开启php的状态⻚⾯
#修改nginx配置
[root@nginx conf.d]# cat /etc/nginx/conf.d/fpm.conf
server {
 listen 80;
 server_name php.bgx.com;
 location / {
 root /code;
 index index.php;
 }
 #新增如下配置
 location /phpfpm_status {
 fastcgi_pass 127.0.0.1:9000;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 include fastcgi_params;
 }
 location ~ \.php$ {
 fastcgi_pass 127.0.0.1:9000;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 include fastcgi_params;
 }
 }

4.访问测试phpfpm_status状态⻚⾯

[root@nginx ~]# curl http://127.0.0.1/phpfpm_status
pool: www #fpm池名称,⼤多数为www
process manager: dynamic #动态管理phpfpm进程
start time: 05/Jul/2016 #启动时间，如果重启会发⽣变化
start since: 409 #php-fpm运⾏时间
accepted conn: 22 #当前池接受的连接数
listen queue: 0 #请求等待队列,如果这个值不为0,那么需要增加FPM的进程数量
max listen queue: 0 #请求等待队列最⾼的数量
listen queue len: 128 #请求等待队列的⻓度
idle processes: 4 #php-fpm空闲的进程数量
active processes: 1 #php-fpm活跃的进程数量
total processes: 5 #php-fpm总的进程数量
max active processes: 2 #php-fpm最⼤活跃的进程数量(FPM启动开始计算)
max children reached: 0 #进程最⼤数量限制的次数，如果数量不为0，则说明phpfpm最⼤进
程数量过⼩,可以适当调整。

6.3 PHP⽇志管理

php⽇志分为错误⽇志和慢⽇志。
1.通过 upstream_response_time 可以监控 Nginx 到 php 所消耗的时间

#Nginx在log_format中添加upstream_response_time
#编写⼀个php代码，然后观察处理事件

2.php 的 error ⽇志说明。

#编写php代码测试

#注意：如果启⽤display_errors = On，会直接将错误显示⽹⻚上。

3.php-fpm的慢⽇志，php只要处理超过1s就会有记录

slowlog = /tmp/phpslow.log
request_slowlog_timeout = 1s
#编写php代码测试

6.4 PHP最终配置

5.PHP-FPM配置⽂件 4核16G、4核32G

[root@nginx ~]# cat /etc/php-fpm.d/www.conf
[global]
pid = /var/run/php-fpm.pid
error_log = /var/log/php-fpm.log
log_level = warning
rlimit_files = 655350
events.mechanism = epoll
[www]
user = nginx
group = nginx
listen = 127.0.0.1:9000
listen.owner = www
listen.group = www
listen.mode = 0660
listen.allowed_clients = 127.0.0.1
pm = dynamic
pm.max_children = 512
pm.start_servers = 32
pm.min_spare_servers = 32
pm.max_spare_servers = 64
pm.process_idle_timeout = 15s;
pm.max_requests = 2048
pm.status_path = /phpfpm_status
#php-www模块错误⽇志
php_flag[display_errors] = off
php_admin_value[error_log] = /var/log/php/php-www.log
php_admin_flag[log_errors] = on
#php慢查询⽇志
request_slowlog_timeout = 5s
slowlog = /var/log/php-slow.log