互联网上的文章真TM不靠谱 还是自己来的好 --只写靠谱的文档

PHP进程数,已经fpm进程和mysql长短链接关系

文章摘自:http://www.epooll.com/archives/773/
做适当修改

我们都知道,php是不能直接操作 mysql的,他需要通过扩展提供接口调用,php的mysql扩展也好几个,只支持面向过程的mysql,既支持面向过程也支持面向对象的mysqli,只支持面向对象的PDO,当然无论是那个扩展,也只是php语法写法上的区别而已,底层其实是一样的。

今天我们不讲语法这些老掉牙的东西,我们随便找一个扩展,来分析一下 php底层 和 mysql 之间的通信原理。

首先我们来理解一下 php-fpm 的工作原理,php-fpm 是一个 php-cgi 进程管理器,其实就是一个连接池,它和nginx配合的工作原理如下。

我们先从最简单的静态方式入手观察他的工作原理

vim php-fpm.ini

[www]
pm = static
pm.max_children = 5
pm.max_requests = 2

上面三句话的含义是什么呢:

1、static 表示静态以静态方式生成 php-fpm 进程

2、pm.max_children = 5 表示当 php-fpm 启动时就启动 5 个 php-fpm 子进程 等待处理 nginx 发过来的请求

3、pm.max_requests = 2 表示每个 php-fpm 子进程处理 2 个请求就销毁,当然父进程每次看到有销毁的自然也就会生成新的子进程

我们来简单验证一下这个说法:

首先重启 php-fpm,让它复位一下

接下来写一条简单的语句输出当前进程ID

echo "当前 php-fpm 进程ID:".posix_getpid();

不断刷新浏览器观察输出变化

当前 php-fpm 进程ID:24548
当前 php-fpm 进程ID:24549
当前 php-fpm 进程ID:24550
当前 php-fpm 进程ID:24547
当前 php-fpm 进程ID:24551
当前 php-fpm 进程ID:24548
当前 php-fpm 进程ID:24549
当前 php-fpm 进程ID:24550
当前 php-fpm 进程ID:24547
当前 php-fpm 进程ID:24551
当前 php-fpm 进程ID:24563
当前 php-fpm 进程ID:24564
当前 php-fpm 进程ID:24565
当前 php-fpm 进程ID:24566
当前 php-fpm 进程ID:24567
当前 php-fpm 进程ID:24563
当前 php-fpm 进程ID:24564
当前 php-fpm 进程ID:24565
当前 php-fpm 进程ID:24566
当前 php-fpm 进程ID:24567
当前 php-fpm 进程ID:24568
当前 php-fpm 进程ID:24569
当前 php-fpm 进程ID:24570
当前 php-fpm 进程ID:24571
当前 php-fpm 进程ID:24572
当前 php-fpm 进程ID:24568
当前 php-fpm 进程ID:24569
当前 php-fpm 进程ID:24570
当前 php-fpm 进程ID:24571
当前 php-fpm 进程ID:24572

可以看得出,第一批id不是按照顺序执行的,进程id为24547的进程是在第四位处理的,然后从下面开始,所有id都是顺序执行的而且每次生成的一批id都是递增,是不是有种mysql自增主键的赶脚呢?

这里需要注意的是,无论是静态还是下面的动态配置方式,只要没有设置 max_requests ,那么进程是不会销毁的,也就是说当一个进程里面出现死循环或者内存溢出等导致进程僵死的情况出现的时候,处理的进程就会少一个了

好吧理解了静态的处理方式,我们其实也很容易知道这个方式的弊端了,当然我们平时服务器不可能就开5个进程每个进程处理2个请求,我们来做一个简单的加减乘除,看看一个服务器应该开多少个 php-fpm 合适

首先我们来看看一个简单的echo需要多少内存:

$size = memory_get_usage();
$unit = array('b','kb','mb','gb','tb','pb');
$memory = @round($size/pow(1024,($i=floor(log($size,1024)))),2).' '.$unit[$i];
echo "当前 php-cgi 进程所使用内存:".$memory;

观察浏览器我们可以得到一下数据:

当前 php-cgi 进程所使用内存:227.17 kb

也就是说一个简单的什么都不干的php就已经占用了200多K的内存,当然这也不算多。

不过进程多了cpu切换进程速度就会变慢,所以这个数还是需要通过ab等测试工具才能测试出具体应该开多少比较合理

我们先从200开始,不断的增加,架设增加到800的时候,效率和400一样,那我们就没必要开800那么多进程浪费内存了。

那么问题就来了,如果同一时间请求出超过400呢?有人说会排队等待,真的会排队等待吗?答案明显是 php-fpm 是没能力排队了,因为处理请求的php-fpm子进程都用完了,那么等待也就只能是在 nginx 等待,通常一个 nginx 也不只是转发请求给 php-fpm 就完事了,他还要处理静态文件呢?如果这些php请求导致nginx的请求数过多一直在等待,那么访问静态文件自然也会卡了,这时候我们就需要配置成下面的动态处理方式。

[www]
pm = dynamic 
pm.max_children = 10
pm.start_servers = 5
pm.min_spare_servers = 2
pm.max_spare_servers = 8
;pm.max_requests = 2

上面五句话的含义是什么呢:

1、dynamic 表示静态以动态方式生成 php-fpm 进程

2、pm.max_children = 10 同时活动的进程数 10个

3、pm.start_servers = 5 表示当 php-fpm 主进程启动时就启动 5 个 php-fpm 子进程

4、pm.min_spare_servers = 2 表示最小备用进程数

5、pm.max_spare_servers = 8 表示最大备用进程数

6、pm.max_requests = 2 上面说过就不说了

当前 php-fpm 进程ID:2270
当前 php-fpm 进程ID:2271
当前 php-fpm 进程ID:2272
当前 php-fpm 进程ID:2273
当前 php-fpm 进程ID:2274
当前 php-fpm 进程ID:2270
当前 php-fpm 进程ID:2271
当前 php-fpm 进程ID:2272
当前 php-fpm 进程ID:2273
当前 php-fpm 进程ID:2274
当前 php-fpm 进程ID:2270
当前 php-fpm 进程ID:2271
当前 php-fpm 进程ID:2272
当前 php-fpm 进程ID:2273
当前 php-fpm 进程ID:2274

为什么这里没有重新生成新的进程?因为pm.max_requests = 2被注释掉了,这个上面其实已经提及过一次了

我们也可以从 ps 看出这批进程id

ps aux|grep php

root      2269  0.0  0.1 134560  4616 ?        Ss   14:27   0:00 php-fpm: master process (/etc/php/php-fpm.ini)
www-data  2270  0.2  0.2 136736  9188 ?        S    14:27   0:00 php-fpm: pool www
www-data  2271  0.2  0.2 136740  9192 ?        S    14:27   0:00 php-fpm: pool www
www-data  2272  0.2  0.2 134684  7284 ?        S    14:27   0:00 php-fpm: pool www
www-data  2273  0.2  0.2 136732  9120 ?        S    14:27   0:00 php-fpm: pool www
www-data  2274  0.1  0.2 134684  7244 ?        S    14:27   0:00 php-fpm: pool www

从上面我们可以看到一个 id 为 2269 的 php-fpm 主进程 管理着 id 为 2270、2271、2272、2273、2274 的5个php-fpm 子进程

这里需要注意的是,当并发大过start_servers数的处理能力是,备用进程才会启动,当并发数小的时候,备用进程也会销毁掉,所以无论什么时候,ps 出来的进程都是上面那5个

下面来看看php-fpm+mysql的效果

mysql> show processlist;
+----+------------------+-----------+------+---------+------+----------------+-------------------------+
| Id | User             | Host      | db   | Command | Time | State          | Info                    |
+----+------------------+-----------+------+---------+------+----------------+-------------------------+
|  9 | root             | localhost | NULL | Query   |    0 | NULL           | show processlist        |
+----+------------------+-----------+------+---------+------+----------------+-------------------------+

接下来我们看短连接:

$conn = new mysqli("192.168.0.170", "redol", "redol", "test_db");

然后不断访问上面的php文件,每次看到的都是

+----+---------+-----------+------+---------+------+----------------+--------------------+
| Id | User    | Host      | db   | Command | Time | State          | Info               |
+----+---------+-----------+------+---------+------+----------------+--------------------+
|  9 | root    | localhost | NULL | Query   |    0 | NULL           | show processlist   |
+----+---------+-----------+------+---------+------+----------------+--------------------+

这也是php神奇的地方,居然不用close的,每次请求完了他就自己给你close掉和mysql的连接了,这点确实也让很多新手少了不少下面的烦恼啊

Warning: mysqli::mysqli(): (HY000/1040): Too many connections in ...

不要以为语言应该都是这样那就打错特错了,去看看golang吧

下面看看长连接

$conn = new mysqli("p:192.168.0.170", "redol", "redol", "test_db");

你没看错,mysqli的长连接和mysql不同,是在host前面加 p:,没有mysqli_pconnet 的用法,估计很多刚开始用mysqli也是摸不着头脑吧?

第一次访问:

+----+-------+-------------------------+-------+---------+------+-------+------------------+
| Id | User  | Host                    | db    | Command | Time | State | Info             |
+----+-------+-------------------------+-------+---------+------+-------+------------------+
|  9 | root  | localhost               | NULL  | Query   |    0 | NULL  | show processlist |
| 10 | redol | bbs.demo.kkk5.com:16650 | redol | Sleep   |   34 |       | NULL             |
+----+-------+-------------------------+-------+---------+------+-------+------------------+
刷新一下网页

+-----+-------+-------------------------+-------+---------+------+-------+------------------+
| Id  | User  | Host                    | db    | Command | Time | State | Info             |
+-----+-------+-------------------------+-------+---------+------+-------+------------------+
|   9 | root  | localhost               | NULL  | Query   |    0 | NULL  | show processlist |
|  10 | redol | bbs.demo.kkk5.com:16650 | redol | Sleep   |    4 |       | NULL             |
| 727 | redol | bbs.demo.kkk5.com:16657 | redol | Sleep   |    1 |       | NULL             |
+-----+-------+-------------------------+-------+---------+------+-------+------------------+
再刷新一下网页,效果我就不发了,反正你知道最后无论怎么刷新,都是如下即可

+-----+-------+-------------------------+-------+---------+------+-------+------------------+
| Id  | User  | Host                    | db    | Command | Time | State | Info             |
+-----+-------+-------------------------+-------+---------+------+-------+------------------+
|   9 | root  | localhost               | NULL  | Query   |    0 | NULL  | show processlist |
|  10 | redol | bbs.demo.kkk5.com:16650 | redol | Sleep   |    4 |       | NULL             |
| 727 | redol | bbs.demo.kkk5.com:16657 | redol | Sleep   |    1 |       | NULL             |
| 728 | redol | bbs.demo.kkk5.com:16659 | redol | Sleep   |   16 |       | NULL             |
| 729 | redol | bbs.demo.kkk5.com:16661 | redol | Sleep   |   12 |       | NULL             |
| 730 | redol | bbs.demo.kkk5.com:16663 | redol | Sleep   |    8 |       | NULL             |
+-----+-------+-------------------------+-------+---------+------+-------+------------------+

也就是说,长连接是真的会一直霸占mysql连接的,那么问题就来了,如果我没有重启 php-fpm,只重启了mysql,会出现什么问题呢?答案是第一次连接的时候会报下面错误

Warning: mysqli::mysqli(): MySQL server has gone away in

所以用长连接query前还是先判断有没有连接,没有就close连接,注意一定要close,再连接,否则连接是失效的。

下面我们来试试 Too many connections 的错误吧

先调整一下mysql的最大连接数

vim /etc/mysql/my.cnf
max_connections = 3

你没看错,我只给了他3个连接,而上面的php-fpm是5个,所以结果不用我说都知道了吧,如期的出现

Warning: mysqli::mysqli(): (HY000/1040): Too many connections in ...

所以线上的mysql,还是注意一下这个max_connections数吧,我只能告诉你他默认是100,如果你觉得100不够用的话,自己改去吧

从上面可知,短连接是不用close也会自动关闭的,那如果是设置了 pm.max_requests = 2,每个php-fpm处理两个请求就销毁,销毁了会close么?我就不截图了,直接告诉答案吧,会的,所以无论如何,看到的mysql都是1、2、3、4、5、4、3、2、1、2、3、4、5这样的连接数,就是慢慢增加,再慢慢减少,减少是因为php-fpm子进程销毁了嘛

好吧,论文结束了,好好把php-fpm的原理已经mysql长短连接理解了一遍

以上是原博主的全部内容,我自己想做一些补充

推想1:

就是关于mongodb的

因为mongodb在php中的插件的问题,每一个php-fpm进程都会和mongodb服务器建立一个长连接
如果你有2台服务器,每一台有300个fpm进程
比如我们的服务器fpm进程数是这样的

# ps -ef | grep php-fpm | wc -l
242

那么在mongodb服务器上,在static模式下,并且没有设置 "pm.max_requests"的 最大值就会创建300*2个连接,
按照每个连接10m的内存占用计算,几个G的内存妥妥的没有了
比如我们线上的mongo内存占用是

# ps -e -o 'pid,comm,args,pcpu,rsz,vsz,stime,user,uid' | grep mongo |  sort -nrk5
26180 mongod          /www/server/mongodb/bin/mon 22.1 1007416 2275200 Mar15 root      0

在dynamic 模式下也会按照实际运行的fpm进程数开启mongodb连接,并且保持住

所以说如果说要使用fpm+mongodb 连接的结构 那么维护合适的fpm进程数是很重要的
推荐使用dynamic模式,并且开启pm.max_requests 在一定情况下释放掉fpm进程

推想2:如果说php使用mysql长连接,mysql的连接数长连接数是否会超过fpm的进程数?

OK 推想完毕,下个blog争取能验证这两个问题

标签: none

添加新评论