上周,我们通过 LXD 更新了几个 wordpress 网站,这些网站在主机(Ubuntu 20.04)内以容器形式运行 Alpine Linux。
更新概要如下:
Alpine Linux v3.8 -> 3.14
PHP 5.3.6 -> 7.4.24
Wordpress 5.0.3 -> 5.7.3
问题
在进行这些更新后,我们开始遇到服务器性能问题,我们发现更新后的容器使用的内存(常驻内存)是旧容器的 3 倍或更多(约 150MB 对 50MB),这导致服务器开始更频繁地交换。
在旧版本(使用 PHP 5.3)中,(进程)使用的内存php
会随着页面的处理而增加(正如预期的那样),但在处理完成后,内存会恢复正常。换句话说,类似于:10MB
---> 95MB
---> 10MB
。
在更新的容器中,使用的内存以php
相同的方式增加,但不会恢复到“正常”状态:10MB
---> 95MB
---> 95MB
。每次使用新进程时,都会发生相同的情况,内存使用量会增加可用子进程的数量(在本例中每个站点有 4 个)。
我尝试过
- 将 PHP 版本降级至 和
7.2.x
:7.3.x
同样的事情 - 更新至
php 8.0.11
:同样的问题 - 使用
apache2
代替lighttpd
(当前 php 以 fcgi 形式运行):相同的行为 - 仅更新 Alpine 和 PHP 以确定 Wordpress 是否是原因:wordpress 不是原因
- 运行没有插件的 wordpress(了解某些插件是否可能导致问题):没有变化
- 执行了一个简单的连接循环(纯 php):同样的事情
- 在不同的服务器上使用不同的 WordPress 网站进行测试:行为相同
无法恢复内存的原因是什么?如何修复?
更新
- 我设置了一个干净的
Alpine 3.14
容器并执行了“简单循环”测试。在这种情况下,驻留内存按预期减少了。但是,一旦我用一个实际的 wordpress 网站进行测试,问题仍然存在。 - 我设置了一个干净的
Ubuntu 20.04
容器并进行了相同的测试。结果与干净的相同Alpine 3.14
。
答案1
根据此错误报告这不是一个真正的错误,而是 PHP7+ 中的一个功能Zend Engine 内存管理:
[电子邮件保护]:这是预期行为。请求关闭时,Zend 内存管理器不会释放所有已分配的块,而是保留一些[1],以避免可能需要为下一个请求重新分配它们。
建议的解决方案是调用:gc_mem_caches()。如果需要,您可以使用auto_prepend_file
和auto_append_file
指令来始终执行它。php.ini
但是,该解决方案对我的情况没有帮助,因此不能保证它会起作用。
由于目前没有简单的方法来改变这种行为,我找到了另一种解决内存问题的方法(它适用于 PHP7、PHP8):
php-cgi
不要使用,而是使用php-fpm
- 设置 FPM 配置以使用最少数量的子进程,但如果需要则让它创建子进程,为此,您可以使用
ondemand
模式或dynamic
:
/etc/php7/php-fpm.d/www.conf
:
pm = ondemand
; Adjust as needed:
pm.max_children = 10
或者:
pm = dynamic
; Adjust as needed:
pm.max_children = 10
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 1
它们之间的主要区别在于,ondemand
空闲时会使用较少的内存,但客户端连接时速度会更慢。
这是我的结果的比较:
PHP | 模式 | 孩子们 | 最大限度 | 空闲内存。 | 最大内存。 | 加载时间 | 最大时间* |
---|---|---|---|---|---|---|---|
PHP5 | 电脑生成图像处理 | 4 | 4 | 50MB | 200MB | 5秒 | 15秒 |
PHP7 | 电脑生成图像处理 | 4 | 4 | 200MB | 200MB | 5秒 | 30 秒 |
PHP7 | FPM/按需 | 0 | 10 | 15MB | 500MB | 7秒 | 10 秒 |
PHP7 | FPM/动态 | 1 | 10 | 25MB | 500MB | 6秒 | 10 秒 |
- 最大加载时间是同时运行 50 个客户端测试的
表中的数值为近似值,仅供说明之用(并非任何形式的真实基准)。