AWS EC2实例上PHP-FPM进程内存解读及配置优化咨询

我来逐个拆解你的疑问，再针对核心的内存配置问题给出实际建议：

1. VIRT列到底是什么？ #

VIRT表示进程的虚拟内存总量，它包含了进程所有申请过的内存空间——不管这些内存有没有实际被使用、是不是来自共享库、甚至有没有被分配物理内存。比如多个PHP-FPM子进程会共享大量PHP核心库的内存，这部分会被算进每个进程的VIRT里，但实际物理内存只存一份；另外，进程可能申请了内存但还没真正使用，这部分也会被计入VIRT。所以VIRT的总和远大于物理内存是完全正常的，它不能直接反映实际的内存占用情况，真正要看实际物理内存占用的是RES列。

2. 为什么Swap总大小是0，却有1052.0 avail Mem？ #

你混淆了两个概念：avail Mem是系统认为可以立即分配给新进程的物理内存，它等于空闲内存加上可以被回收的缓存（buff/cache），和Swap完全没关系。你的EC2实例没配置Swap分区（所以MiB Swap全是0），但这不影响系统计算可用的物理内存——当需要更多内存时，系统会自动释放部分缓存给应用使用。

3. 为什么used内存只有692.3M，但%MEM总和是88.6%？ #

这里有两个关键点：

• top里的used内存指的是应用进程直接占用的物理内存，而buff/cache是系统用来缓存文件、磁盘数据的内存，这部分内存是可以被回收的，不属于应用的“已用”。但更核心的问题是共享内存的重复统计：多个PHP-FPM子进程共享的库（比如PHP核心、依赖扩展），会被计入每个进程的RES和%MEM里，但实际物理内存只存一份。你计算%MEM总和时，相当于把共享内存多次加总，所以结果会远大于实际的物理内存占用比例。
• 如果你把used + buff/cache（692.3+1065.7）加起来，刚好接近总内存1935.6M，这才是系统实际使用的内存总量，而avail Mem是其中可以快速释放给应用的部分。

4. PHP-FPM主进程为什么是睡眠状态（S）？ #

这完全正常！PHP-FPM的主进程（master）只负责管理子进程：比如根据请求量创建/销毁子进程、接收配置重载信号等，平时它不需要处理实际的HTTP请求，所以大部分时间处于睡眠状态，只有当需要执行管理操作时才会被唤醒。真正处理请求的是那些子进程，它们在有请求时会切换到运行状态（R），空闲时也会睡眠。

核心配置优化：你的思路是对的，再细化下 #

你担心内存超限的问题非常实际，EC2实例内存有限，一旦PHP-FPM进程占用内存超过系统可用内存，就会触发OOM Killer（系统强制杀死进程），导致服务中断。

你的调整思路（降低memory_limit到128M，pm.max_children到12）是合理的，再补充几个细节：

• memory_limit是PHP脚本能使用的最大内存上限，不是每个进程的固定占用。你的子进程现在空闲时RES在43-60M左右，说明脚本平时内存消耗不高，128M的上限完全足够，既给脚本留了余量，又降低了峰值内存风险。
• pm.max_children的计算要留有余地：系统本身（操作系统、其他必要服务）大概需要200-300M内存，剩下的1600M左右，按每个进程峰值128M计算，12个进程总共1536M，刚好在安全范围内，不会触发OOM。
• 除了pm.max_children，建议同步调整pm.start_servers（比如设为4）、pm.min_spare_servers（2）、pm.max_spare_servers（8），让子进程数量维持在合理范围，避免频繁创建销毁进程带来的性能开销。

另外，你可以用pm.status_path开启PHP-FPM的状态页面，实时监控子进程的内存占用、请求处理情况，后续再根据实际流量和内存使用情况微调配置。

备注：内容来源于stack exchange，提问作者dodov