Bitnami EC2 t3a.medium实例上WordPress的PHP-FPM配置优化咨询

我在AWS EC2 t3a.medium（4GB内存）实例上用Bitnami部署了WordPress网站，服务器内存经常被耗尽，导致崩溃，只能从EC2控制台重启。

我尝试调优PHP-FPM配置来缓解问题，当前配置如下：

pm.max_children=60
pm.start_servers=40
pm.min_spare_servers=40
pm.max_spare_servers=45
pm.max_requests=5000

这个配置可能太大了，我考虑换成以下配置：

pm.max_children = 47
pm.start_servers = 10
pm.min_spare_servers = 10
pm.max_spare_servers = 20
pm.max_requests = 1000

有两个问题：

1. 这个新配置对4GB内存的t3a.medium实例是否合理？有哪些改进建议？
2. 应用这些设置后，用什么最佳方法监控系统来确保配置有效？

附按内存降序排列的htop命令结果截图：

另外提供MariaDB配置文件内容：

[mysqladmin]
user=****************

[mysqld]
skip_name_resolve
explicit_defaults_for_timestamp
basedir=/opt/bitnami/mariadb
port=3306
tmpdir=/opt/bitnami/mariadb/tmp
socket=/opt/bitnami/mariadb/tmp/mysql.sock
pid_file=/opt/bitnami/mariadb/tmp/mysqld.pid
max_allowed_packet=16M
bind_address=127.0.0.1
log_error=/opt/bitnami/mariadb/logs/mysqld.log
slow_query_log=1
slow_query_log_file=/opt/bitnami/mariadb/logs/mysqld_slowquery.log
long_query_time=10.0
character_set_server=utf8
collation_server=utf8_general_ci
plugin_dir=/opt/bitnami/mariadb/lib/plugin

[client]
port=3306
socket=/opt/bitnami/mariadb/tmp/mysql.sock
default_character_set=utf8
plugin_dir=/opt/bitnami/mariadb/lib/plugin

[manager]
port=3306
socket=/opt/bitnami/mariadb/tmp/mysql.sock
pid_file=/opt/bitnami/mariadb/tmp/mysqld.pid
!include /opt/bitnami/mariadb/conf/bitnami/memory.conf

memory.conf内容：

long_query_time = 1
query_cache_limit=2M
query_cache_type=1
query_cache_size=128M
innodb_buffer_pool_size=256M

1. 新PHP-FPM配置合理性及改进建议 #

你的新配置比当前配置合理很多，但pm.max_children=47仍偏高，需要进一步调整：

计算合理的max_children值 #

t3a.medium总内存4GB，需预留系统、MariaDB、Nginx等服务的内存：

• 系统基础内存：约512MB-1GB
• MariaDB当前配置：innodb_buffer_pool_size=256M加query_cache等，实际占用约300MB-400MB
• Nginx+其他进程：约200MB-300MB

剩余给PHP-FPM的内存约2.3GB-2.9GB。WordPress环境下，单个PHP-FPM进程平均占用内存约50MB-80MB（受插件、主题影响）。按60MB/进程计算，合理的pm.max_children应为：
(2.3GB*1024)/60 ≈ 39，保守建议设为30-35，避免内存被占满。

其他参数调整建议 #

• pm.start_servers=10：合理，初始启动进程数适中，不会刚启动就占用过多内存
• pm.min_spare_servers=10：和start_servers一致，既能保证有足够空闲进程处理突发请求，又不会闲置太多浪费内存
• pm.max_spare_servers=20：合理，避免空闲进程过多消耗资源
• pm.max_requests=1000：比原配置小，能更频繁回收进程防止内存泄漏，建议保留，甚至可降到500-800，进一步降低内存泄漏风险

额外优化点 #

• 清理WordPress插件：禁用不必要的高内存插件，可通过wp-cli的wp plugin status排查，或查看PHP内存日志定位
• 确认OPcache启用：检查php.ini中opcache.enable=1，配置opcache.memory_consumption=64M-128M，减少PHP重复编译代码的内存消耗
• MariaDB优化：query_cache_size=128M可降至64MB（高并发下query cache易有锁竞争，且WordPress本身有缓存插件，利用率有限）；innodb_buffer_pool_size可提至512MB，提升数据库缓存效率，减少磁盘IO间接稳定内存

2. 配置生效后的监控方法 #

• 实时内存监控：
  • 用htop/top实时查看内存占用、PHP-FPM进程数，重点关注%MEM和RES列，确保PHP-FPM总内存不超预留值
  • 定时执行free -h，查看available值，避免接近0
• PHP-FPM日志监控：
  • 查看PHP-FPM慢日志（若开启），排查长时间运行的进程
  • 检查错误日志，定位内存泄漏相关报错
• 系统级监控：
  • 用vmstat 1查看swap交换情况，若si/so持续不为0，说明内存仍不足，需继续调整配置
  • 配置AWS CloudWatch：添加EC2内存、CPU使用率指标，设置告警阈值（如内存使用率超85%告警）
• 进程统计：
  • 执行ps aux | grep php-fpm | wc -l统计当前PHP-FPM进程数，确认不超过pm.max_children
  • 用ps aux --sort=-%mem | grep php-fpm查看单个进程内存占用，计算平均值后再调整pm.max_children

内容的提问来源于stack exchange，提问作者Damiano Dotto