做网站 上海wordpress模板放

做网站 上海,wordpress模板放,营销策划与运营的书,长沙网站建设推荐大多数开发者来说#xff0c;PHP-FPM 的配置并不是日常工作中需要深入研究的东西。这没什么问题#xff0c;毕竟不是每个人都想或需要在服务器调优上花时间。况且#xff0c;现在有很多托管服务#xff08;宝塔, 1panel等#xff09;可以帮你把服务器配置好#xff0c;安…大多数开发者来说PHP-FPM 的配置并不是日常工作中需要深入研究的东西。这没什么问题毕竟不是每个人都想或需要在服务器调优上花时间。况且现在有很多托管服务宝塔, 1panel等可以帮你把服务器配置好安装所有依赖包括 PHP-FPM你只需要在控制面板点几下就能部署代码。也许你们公司有专门的运维或者有资深开发在负责这块。即便真要自己配置 PHP-FPM多半也就是翻几篇文章改改参数或者直接用默认配置。这很正常——谁有那么多时间去钻研每个服务器配置细节尤其这只是工作的一小部分。但随着应用不断迭代、用户越来越多你可能会发现服务器开始变慢请求处理时间越来越长内存占用接近上限甚至服务器直接挂掉。最近我的一台服务器就遇到了类似问题所以我决定花点时间搞清楚 PHP-FPM 到底是怎么工作的不同配置会带来什么影响。我看了很多文章、讨论和评论然后自己做了些测试来验证。以下是我的一些心得。原文 深入理解 PHP-FPM 的最佳配置问题排查如果问题确实出在 PHP-FPM 上有几个排查方向。首先检查 PHP-FPM 的日志重点关注 max children 相关的警告。PHP-FPM 的主进程会按需生成子进程直到达到 max children 的上限。每个子进程一次只能处理一个请求比如对你应用的一次访问。所以如果 max_children 设置成 5而同时有 10 个用户在访问应用日志里很可能会出现这样的警告WARNING: [pool www] server reached pm.max_children setting (5), consider raising it这会导致部分请求被延迟直到有子进程空闲出来。可以用下面的命令检查日志里有没有这类警告。如果你用的是 PHP-FPM 8.2sudo grep max_children /var/log/php8.2-fpm.log.1 /var/log/php8.2-fpm.log注意你系统上的日志路径可能不同记得先确认。另外除了替换 PHP 版本号有些系统的日志文件名里不带版本号那就直接用 php-fpmsudo grep max_children /var/log/php-fpm.log.1 /var/log/php-fpm.log后面提到的所有 php-fpm 命令都是同样的道理。我会用 php-fpm8.2 或 php8.2-fpm因为这是我的版本你的可能是 php-fpm7.4php7.4-fpm或者直接就是 php-fpm。不想打开配置文件的话可以用这个命令快速查看当前配置sudo php-fpm8.2 -tt这样就能找到 pm.max_children 这一行确认 max_children 是不是真的设置成了 5[19-Mar-2024 22:48:10] NOTICE: pm.max_children 5另外要关注的是服务器内存使用情况。用 htop 按内存排序可以看到内存是不是快用完了PHP-FPM 进程占了多少。这可能是 max_children 设置太高生成的子进程太多服务器内存撑不住了。或者如果重启 PHP-FPM 后内存使用量下降然后又慢慢涨回去那多半是代码有内存泄漏。理想情况下当然要找到泄漏点并修复但定位内存泄漏有时候挺难的尤其在大项目里而且泄漏可能来自某个必需的第三方库。第一个问题可以通过优化配置解决内存泄漏的话 PHP-FPM 这边也有些缓解办法稍后会讲。顺便说一下重启 PHP-FPM 的命令可能是这样的但你的情况可能不同所以要确认一下sudo service php8.2-fpm restart如前面说的重启 PHP-FPM 能临时缓解内存泄漏问题但不是根本解决给你争取时间去修复泄漏或调整配置。配置进程管理器现在可以开始修改 PHP-FPM 的配置文件了看看怎么针对实际情况做优化。编辑主配置文件的命令sudo nano /etc/php/8.2/fpm/pool.d/www.conf里面有各种配置项我们只讲几个对性能影响最大的。首先要决定进程管理器如何控制子进程数量。有 3 个选项static、dynamic 和 ondemand。大多数情况下默认是 dynamic。这几个选项有什么区别假设你确定服务器最多需要 10 个子进程static 会始终保持所有 10 个进程运行理论上最快因为进程都已经在那儿了负载上来时不需要 fork 新进程。但代价是即使没人访问网站这 10 个进程也会一直占着内存。dynamic 可以灵活调整比如一开始启动 3 个进程负载上来时 fork 到最多 10 个负载下去后减少到 6 个等待连接。这个选项在内存占用和响应速度之间找平衡至少理论上如此。最后是 ondemand一开始不生成任何子进程负载上来时最多创建 10 个负载下去后可能又回到 0 个。这个选项理论上适合流量不大的中小型应用、预发布环境或者多租户共享服务器。由于子进程一直在回收可以帮助控制内存泄漏因为进程在内存累积之前就被干掉了。缺点是需要频繁 fork 新进程可能影响性能和响应速度。设置这些选项之前需要算出 PHP-FPM 进程的最大负载。也就是确定服务器能跑多少个子进程然后设置 max_children 值。怎么算这有点麻烦因为理想情况下要知道单个子进程平均用多少内存。问题是多个进程通常会共享一些内存所以很难精确算出单个进程的实际内存使用量。网上有很多脚本和文章教你怎么算 PHP-FPM 进程的平均内存消耗但大多数我试下来感觉不太对算出来的值比预期高很多。有个 Python 脚本在好几篇文章里都提到了看起来比较靠谱。可以用这个命令算出每个程序的总内存使用量cd ~ wget https://raw.githubusercontent.com/pixelb/ps_mem/master/ps_mem.py chmod ax ps_mem.py sudo python3 ps_mem.py注意我用的是 python3你的系统可能只需要 python。跑完脚本后可能会看到类似这样的结果2.1 GiB 127.5 MiB 2.2 GiB php-fpm8.2 (31)这说明 31 个 PHP-FPM 进程用了 2.2 GB 内存平均每个进程约 73 MB。另一个有用的命令可以查看空闲和活动进程数sudo service php8.2-fpm status -l看这一行就能知道子进程的当前状态Status: Processes active: 0, idle: 30, Requests: 56116, slow: 0, Traffic: 0req/sec这里没有活动进程30 个空闲进程加上 1 个主进程总共 31 个和 Python 脚本报的一致。Python 脚本也会报总内存使用量。可以随时跑 htop 或 free -hl 检查服务器当前内存使用情况看看这些数字是否合理、是否对得上。还有一点如果真有内存泄漏单个进程的内存可能会涨到 php.ini 里定义的 memory_limit默认一般是 128 MB。所以保守起见可以直接用这个值作为单个进程的平均值。好现在可以算 max_children 值了。假设有台 8 GB 内存的服务器其他程序用了 2 GB剩 6 GB。再留 1 GB 作为缓冲防止意外情况或者未来应用增长、新增进程什么的。这样就剩 5 GB 给 PHP-FPM。前面算出单个进程用约 73 MB 内存用 5 GB 除以 73 MB 就得到 max_children 值5120 (MB) / 73 (MB) 70.14所以这台服务器的 max_children 应该设置成 70。这样无论选哪个进程管理器pm选项PHP-FPM 最多都只会生成 70 个子进程。如果用 pm static就不需要设置其他选项了。70 个子进程会立即生成随时待命。但要记住代价这些进程会一直占着 5 GB 内存。如果用 pm ondemand只需要考虑一个额外设置pm.process_idle_timeout。由于 ondemand 模式下子进程会不断生成和终止这个设置告诉 PHP-FPM 什么时候干掉空闲的子进程。默认是 10 秒需要的话可以改不过默认值已经挺合理了。如果用 pm dynamic需要考虑几个额外设置。pm.start_servers 是启动或重启 PHP-FPM 时立即生成的子进程数。pm.min_spare_servers 设置最小空闲子进程数。pm.max_spare_servers 决定最大空闲子进程数。假设我们这样设置pm dynamicpm.max_children 70pm.start_servers 20pm.min_spare_servers 20pm.max_spare_servers 40实际运行是这样的。上面例子里 start_servers 设置为 20PHP-FPM 一启动就会生成 20 个子进程占用相应的内存。有请求过来时这 20 个进程中的部分或全部会变成活动状态处理请求。没流量时这 20 个进程会空闲等待它们不会被终止继续占着内存。把 min_spare_servers 设置得比 start_servers 低比如 15没什么意义因为 20 个子进程会立即生成即使空闲主进程也不会为了达到 15 的最小值而终止 5 个。而且 min_spare_servers 不能比 start_servers 大所以最好就把 min_spare_servers 设置成和 start_servers 一样。如果大量请求涌入20 个子进程不够用主进程会生成额外的子进程最多到 max_children 值这里是 70。假设为了应对流量激增生成了 70 个子进程。过一会儿流量恢复正常不再需要 70 个进程了大部分或全部进程变成空闲。这时主进程会终止空闲子进程直到 max_spare_servers 值这里是 40。然后你就剩 40 个空闲进程它们不会被进一步终止继续占着内存。所以设置这些值时要记住如果需要生成比 start_servers 更多的进程流量高峰过后你会剩下那么多子进程最多到 max_spare_servers 值在运行。比如需要生成 30 个子进程你会剩 30 个在运行需要生成 50 个过一会儿会剩 40 个因为 max_spare_servers在运行。所以如果不想最终可能有 40 个子进程在后台跑着可以考虑降低这个值甚至让它和 start_servers 一样。这些情况会一直保持到你重启 PHP-FPM。重启后会根据 start_servers 重新生成 20 个子进程。很多文章里有个公式建议根据 CPU 核心数来设置 start_servers、min_spare_servers 和 max_spare_servers 以获得最佳性能pm.start_servers CPU 核心数 x 4pm.min_spare_servers CPU 核心数 x 2pm.max_spare_servers CPU 核心数 x 4这个公式据说是基于单个 CPU 核心能并发处理多少进程的某种假设。我不确定是谁开始这么搞的这些乘数怎么推导出来的但有一点让我觉得不对劲——把 min_spare_servers 设得比 start_servers 低如我上面解释的会导致 min_spare_servers 值永远用不上。而且在我的测试中稍后会讲用这个方法并没看到明显的性能提升。所以我觉得这个公式不该盲目照搬要根据实际情况调整。关于 max_children 和 dynamic 相关设置最好的建议就是边监控边调优。每种情况都不一样——你的资源、负载、整体策略都不同。按照上面的指导原则从合理的值开始随着应用增长和变化不断调整配置。这一节还有个值得注意的选项pm.max_requests。如果真有内存泄漏这个设置可以让子进程在处理一定数量请求后被回收。默认是 0意味着进程不会因为这个选项被终止。合理的值可能是 500 或 1000 个请求取决于你的场景。比如设置成 500子进程处理了 500 个请求后会被终止释放累积的内存然后重新生成。实际测试我决定做几个性能测试来验证理论static 处理请求应该最快因为不需要临时 fork 子进程dynamic 应该居中因为部分进程已经在跑部分需要按需 forkondemand 应该最慢因为它不停地生成和终止进程。结果如下。我用 ApacheBench 做测试按照建议从另一台服务器发送请求不是从被测服务器本身发的。被测服务器有 16 GB 内存和 4 个 CPU 核心PHP-FPM 配合 NGINX请求走 Laravel 应用。所有测试用例的 max_children 都是 80。我比较的是 90% 请求的响应时间。下面表格里只列出不同 pm 选项之间的毫秒差异0ms 是最快的。测试命令示例ab -n 1000 -c 10 https://example.com这个例子会发送 1000 个请求并发级别是每次 10 个。先看第一个测试。我想看看明显达到 max_children 限制时不同 pm 选项如何影响响应时间。所以发了 25000 个请求并发级别 1000。用 dynamic 时的额外值如下后面简称 20/20/40pm.start_servers 20pm.min_spare_servers 20pm.max_spare_servers 40结果如下Static Dynamic On demand1223ms 845ms 0ms结果显示理论上应该最慢的 ondemand 实际上最快而 static 出人意料地最慢比 ondemand 慢了一秒多。第二个测试发了 10000 个请求并发级别 100。测试了两种 dynamic 设置一种是第一个测试的20/20/40另一种用基于 CPU 核心的公式16/8/16Static Dynamic (20/20/40) Dynamic (16/8/16) On demand0ms 14ms 2ms 24ms这次 static 最快基于公式的 dynamic 紧随其后ondemand 最慢符合理论预期。但总的来说对大多数网站而言24ms 算不上什么性能提升不同选项之间差异不大。最后一个测试只发了 2000 个请求并发级别 16。同样用了两种 dynamic 设置20/20/40 和 16/8/16Static Dynamic (20/20/40) Dynamic (16/8/16) On demand2ms 7ms 10ms 0ms这个规模下 ondemand 再次获胜static 紧随其后基于公式的 dynamic 垫底。这次差异更小了第一名和最后一名之间只差 10ms。最终得到了一些意外结果。测试表明当并发请求数量远超 max_children 值或者远低于 max_children 值时ondemand 是最佳选择。当并发请求数量接近 max_children 值时static 最佳。但要注意第二个测试特别是第三个测试中响应时间差异相当小。而且如果重新跑这些测试排名很可能会变。所以这些结果不能当成铁律理论也是如此。我觉得在现代服务器上fork 一个新子进程已经不是什么昂贵操作了不会明显影响响应时间至少在测试的规模上不会。这就是为什么 ondemand 不该被轻易否定即使在处理请求速度方面也是如此。最好的前进方式是做你自己的测试因为你的负载、设置和每个请求执行的操作可能完全不同然后根据这些测试应用看起来最高效的设置。其他设置还有几个额外的设置我们应该了解一下在 PHP-FPM 出问题或者你需要追踪慢请求时可能会很有用。要启用 slowlog当然是用来记录慢请求的我们需要编辑之前的同一个配置文件sudo nano /etc/php/8.2/fpm/pool.d/www.conf然后找到 slowlog 部分slowlog /var/log/php8.2-fpm.log.slow取消注释。那里还有几个相关选项你应该考虑取消注释。第一个是 request_slowlog_timeout默认设置为 5 秒。如果你只想记录耗时 3 秒及以上的请求应该取消注释并修改这个值。第二个是 request_slowlog_trace_depth默认设置为 20。在 Laravel 应用中这个值可能太低无法遍历所有 vendor 函数并到达实际被调用的代码比如你的 controller。所以我认为大多数情况下50 应该没问题但要确认一下是否适合你。最终整个 slowlog 设置可能是这样的slowlog /var/log/php8.2-fpm.log.slowrequest_slowlog_timeout 3srequest_slowlog_trace_depth 50最后还有另一个配置文件我们可以编辑控制当子进程因为某种原因开始失败时会发生什么。下面是编辑这个文件的示例sudo nano /etc/php/8.2/fpm/php-fpm.conf在那个文件中我们关注 3 个相互关联的选项它们默认都设置为 0 并被注释掉。如果你打算使用它们确保先取消注释。之后你可以把它们设置为这些值emergency_restart_threshold 10emergency_restart_interval 1mprocess_control_timeout 10s使用的值是你可能在其他一些文章中也会看到的。前两个设置告诉 PHP-FPM如果在一分钟内有 10 个子进程失败PHP-FPM 应该自动重启。第三个设置意味着子进程在响应主进程发送的信号之前会等待 10 秒。所以如果主进程向子进程发送 KILL 信号它会有 10 秒时间完成任务后再退出。当然你可以根据需要调整这些值。在失败时重启 PHP-FPM 可能会解决一些问题但如果问题与即使 PHP-FPM 重启后仍会重现的东西有关它会一直重启直到你弄清楚到底发生了什么。所以你应该自己决定当发生意外情况时是想让 PHP-FPM 完全失败还是让它自动重启。总结本人讨论了 max_children 选项的最佳值。探讨了不同进程管理器设置的优势和缺陷以及如何测试它们。还了解了一些在调试慢请求或处理失败时可能有用的额外设置。希望这篇文章对你有帮助你能够用文章中的信息作为起点更好地监控和调优你服务器上的 PHP-FPM。