max_children设多少要看每个进程实际占多少内存

照着别人博客里的数字把max_children填上去，是这类配置最常见的起点，填完页面确实快了一阵，随后又开始偶发502，重启一下就好，过几天照旧。问题往往不是配置写得不对，而是设的那个数超过了机器真正能扛的量。php-fpm的max_children管的是同时能处理多少个请求，每个请求占一个子进程，进程占的内存是实打实的，开到上限时所有子进程的内存要能同时装得下。装不下的时候系统会挑占用最大的进程杀掉，表现出来就是随机掉请求，配置文件里不会报错。

算法只有一句：可用内存除以单个进程的常驻内存，得到的就是上限。两个数都得实测，凭感觉估出来的数字十有八九偏高，而偏高的代价就是被系统杀掉进程。

单个进程占多少，用ps看php-fpm的RSS列，命令是ps -ylC php-fpm --sort:rss，RSS单位是KB，按1024字节算，这个排序是升序、最大的在最后，想从大到小看就写成--sort:-rss。要跑起来几个请求之后再量，空转时和负载时的数差得不小，取偏大的那个。

可用内存不等于机器总内存。同机跑着MySQL、nginx、缓存服务，这些都要先扣掉，再按监控里系统实际的占用量留出一块余量，剩下的才是进程池能用的部分，直接拿总内存去算，算出来的数一定偏大。

举例，一台两核两G的机器，扣掉系统和其他服务剩下一千二百兆，单进程实测六十兆，算下来是二十。这个数只是理论上限，按它填满等于一点余量都不留，高峰时系统就开始杀进程，填十六上下比较稳。设得太大的表现很有特点：服务在跑，配置也对，就是偶发502，dmesg里能看到killed process的记录，被杀的正是php-fpm。这时候回头看max_children，通常会发现当初是照着别人博客里的数字抄的，人家的机器和你的内存根本不一样。

判断设小了，看php-fpm状态页里的max children reached这一项，它记录着有多少次请求因为进程满而被拒。这个数一直在涨，说明并发确实被卡住了，加进程数才有意义。

还要注意pm模式，static是固定开这么多进程，dynamic是按负载伸缩、max_children只是上限，ondemand有请求才起进程。三种模式下同一个数字的含义并不一样，换模式等于换了一套算法。

改完之后盯一天的状态页，max children reached那一项不再涨，才算收工。算出来的数字只是起点，实际并发还要看监控曲线。