服务器中找到php-fpm.conf配置（有的会在引入的www.conf中）

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

一. pm= static

首先说一下pm这个值   pm = dynamic 这个是php的进程数是动态的  会根据访问量来确定来回增加

而在高负载的php环境下我推荐设置  pm= static php-fpm进程数固定

二.  pm.max_children=???

当用静态模式下 进程数确定根据 pm.max_children来进进行确定    那么问题来了我的服务器应该设定多少php-fpm呢 ?

    从理论的角度上说php-fpm进程数越多越好，相当于一个酒店有很多个充足的服务员来为你服务肯定会比较爽啊 ，你也不需要等待。

     但是。。。。现实上总是残酷的   php-fpm的进程数会受到你的内存大小的限制。一般情况下我们    进程数 =用机器内存（M）除以2  再除以20(M);

     当然这个也不是绝对的   你需要知道:

1.  你可以分配给php多大内存 ：你的服务器上是不是单纯的php服务器  有没有比较耗费内存的其他程序（mysql）。
2.  你的每个php-fpm内存占多大 ：内存占用多大要根据你的php代码质量和处理的相关业务。当然你可以用命令去统计你的php-fpm平均占用内存大小。

        有人会问我如果设置不恰当会有什么状况出现呢？

 　  　当数值偏小时请求到nginx会无法分配到php-fpm进程 导致502错误

   　　当数值偏大如果没有大访问量还好  如果访问量较大的话 内存都会被php占光了。导致系统响应缓慢   cpu-system  升高 系统不断的去调整内存分配

          严重时会导致较高的 cup-wait 较高   内存不够用了  直接写磁盘  磁盘io直线增加 。cpu使用率也开始爆满。（如图所示）

    三.request_terminate_timeout

 　　计算方式如下：如果你的服务器性能足够好，且宽带资源足够充足，PHP脚本没有循环或BUG的话你可以直接将”request_terminate_timeout”设 置成0s。0s的含义是让PHP-CGI一直执行下去而没有时间限制。

　　 而如果你做不到这一点，也就是说你的PHP-CGI可能出现某个BUG，或者你的宽带不够充足或者其他的原因导致你的PHP-CGI能够假死那么就建议你给”request_terminate_timeout”赋一个值，这个值可以根 据你服务器的性能进行设定。

一般来说性能越好你可以设置越高，20分钟-30分钟都可以。由于我的服务器PHP脚本需要长时间运行，有的可能会超过10分钟因此我设置了900秒，这样不会导致PHP-CGI死掉而出现502 Bad gateway这个错误。

四.pm.max_requests

        这个参数的含义是php-fpm工作进程处理完多少请求后自动重启，主要目的就是为了控制请求处理过程中的内存溢出，使得内存占用在一个可接受的范围内。比较适用于服务器搭载项目比较杂乱，有点请求会比较占用内存

        导致php-fpm占用比较大。在经过一定次数请求后会结束掉进程，释放自己的内存。如果这个值太小就会导致所有的工作进程几乎同时达到这个值并且进入需要重启的状态，当所有的工作进程都在同一时刻重启就会发生在

　　数秒内甚至更长的时间PHP将停止响应直到所有的进程均重启完为止。这是不能接受的，所以我一般会把这个值设置为PHP启动后第一批工作进程达到此值需要重启时，第一个进程重启与最后一个进程重启之间的时间相差

　　1分钟以上，一般在压力比较大的晚上这个差值将会扩大到5分钟左右，此时对进程重启对服务器的负面影响就可以忽略了。

下面补充几个命令统计相关php-fpm 相关数据  

1、查看php-fpm的进程个数

ps -ef |grep "php-fpm"|grep "pool"|wc -l

2、查看每个php-fpm占用的内存大小

ps -ylC php-fpm --sort:rss

3.查看PHP-FPM在你的机器上的平均内存占用

ps --no-headers -o "rss,cmd" -C php-fpm | awk '{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,"M") }'

4.查看单个php-fpm进程消耗内存的明细

pmap $(pgrep php-fpm) | less

 重启php-fpm

概念

系统的吞吐量是指系统的抗压、负载能力，指的是单位时间内处理的请求数量。通常情况下，吞吐率用 “字节数/秒” 来衡量，也可以用 “请求数/秒”，“页面数/秒”，其实，不管是一个请求还是一个页面，本质都是网络上传输的数据，那么表示数据的单位就是字节数。

系统吞吐量的几个重要参数：QPS（TPS），并发数，响应时间等，系统的吞吐量通常由这几个参数值来决定。

服务器并发处理能力的量化描述，单位是reqs/s，指的是在某个并发用户数下单位时间内处理的请求数。某个并发用户数下单位时间内能处理的最大请求数，称之为最大吞吐率。

记住：吞吐率是基于并发用户数的。这句话代表了两个含义：

a、吞吐率和并发用户数相关

b、不同的并发用户数下，吞吐率一般是不同的

计算公式：总请求数/处理完成这些请求数所花费的时间，即

Request per second=Complete requests/Time taken for tests

Queries Per Second，每秒查询数，即是每秒能够响应的查询次数，注意这里的查询是指用户发出请求到服务器做出响应成功的次数，简单理解可以认为查询=请求request

qps = 每秒钟request数量

Transactions Per Second ，每秒处理的事务数。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
针对单接口而言，TPS可以认为是等价于QPS的，比如访问一个页面/index.html，是一个TPS，而访问/index.html页面可能请求了3次服务器比如css、js、index接口，产生了3个QPS。

tps = 每秒钟事务数量

并发数是指系统同时能处理的请求数量，反映了系统的负载能力。

并发数 = 系统同时处理的request/事务数

Response Time，简单理解为系统从输入到输出的时间间隔，宽泛的来说，代表从客户端发起请求到服务端接收到请求并响应所有数据的时间差。一般取平均响应时间。

QPS = 并发数 / 评价响应时间

一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。

ab是apache bench的简称，是apache提供的压力测试工具。

ab [options] [http://]hostname[:port]/path

命令其余请参见 http://apache.jz123.cn/programs/ab.html

-n1000 //代表本次测试发起1000个请求

-c1000 代表每次都同时发起1000次请求,也就是并发数为1000

-t10 代表10秒后就结束测试

-s30 代表每个请求如果超时30秒,则直接代表该请求超时

栗子：

ab -c100 -n10000 -p index.txt -T "application/x-www-form-urlencoded"  http://dev.host.net/

index.txt 里面是请求参数：如下

username=choudalao&pwd=123456

-v1 默认值为1,只显示请求的总统计
-v2 显示响应头,响应数据,并包含1的显示
-v3 显示响应状态码,并包含2的显示
-v4 显示更多信息

-C "cookie1=cookie1,cookie2=cookie2"

命令：

ab -c1000 -n100000 http://dev.host.net/

结果：

This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http:

测试结果显示：nginx吞吐率为：Requests per second: 384.18 [#/sec] (mean)。

通过上面的数据可分析出服务器响应情况,并发处理能力,尤其是Requests per second参数,它确定了服务器的秒并发能力。

   netstat -n |awk '/^tcp/ {++S[$NF]}END{for(a in S)print a,S[a]}'

或者

  netstat -n|grep  ^tcp|awk '{print $NF}'|sort -nr|uniq -c

或者：

netstat -n |awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"t",state[key]}'

返回结果一般如下：
LAST_ACK 5 （正在等待处理的请求数）
ESTABLISHED 1597 （正常数据传输状态） FIN_WAIT1 51 FIN_WAIT2 504
TIME_WAIT 1057 （处理完毕，等待超时结束的请求数）

其他参数说明：
CLOSED：无连接是活动的或正在进行
LISTEN：服务器在等待进入呼叫
SYN_RECV：一个连接请求已经到达，等待确认
SYN_SENT：应用已经开始，打开一个连接
ESTABLISHED：正常数据传输状态
FIN_WAIT1：应用说它已经完成
FIN_WAIT2：另一边已同意释放
ITMED_WAIT：等待所有分组死掉
CLOSING：两边同时尝试关闭
TIME_WAIT：另一边已初始化一个释放
LAST_ACK：等待所有分组死掉 LAST_ACK 5 （正在等待处理的请求数）
ESTABLISHED 1597 （正常数据传输状态） FIN_WAIT1 51 FIN_WAIT2 504
TIME_WAIT 1057 （处理完毕，等待超时结束的请求数）

ps -ef |grep nginx|wc -l

 ps -ef |grep httpd|wc -l

netstat -antp|grep 80|grep ESTABLISH -c

ps -axef|grep mysqld -c