PHP OPcache interned_strings_buffer 的内存规划与容量排查

PHP OPcache 的 opcache.interned_strings_buffer 不是脚本缓存条数，也不是 JIT 缓冲区，而是给驻留字符串预留的共享内存，单位是 MB。排查容量时要同时看配置值和运行时的 interned_strings_usage，只改了 php.ini 却没有让实际承载请求的 PHP-FPM 重新加载，线上读到的仍可能是旧值。

官方地址：https://www.php.net/manual/en/opcache.configuration.php

先分清 interned_strings_buffer 管的是什么

PHP 会复用一部分重复出现的字符串，例如类名、方法名和常量文本。opcache.interned_strings_buffer 为这些驻留字符串预留内存；官方文档给出的默认值是 8 MB，64 位架构的上限为 32767 MB，32 位架构为 4095 MB。PHP 8.4 之前，所有架构的上限都是 4095 MB。

规划时不要把两个参数混为一谈：opcache.memory_consumption 决定 OPcache 共享内存的总体规模，interned_strings_buffer 是其中需要单独关注的字符串区域。把字符串缓冲区调大，会挤压同一共享区中用于字节码的空间；反过来，脚本缓存告急也不能只靠增加字符串缓冲区解决。

用运行时状态判断容量是否真的紧张

先在与线上请求相同的 FPM SAPI 中放置一个受访问控制保护的诊断脚本。opcache_get_configuration() 返回当前缓存实例的 ini、黑名单和版本信息；opcache_get_status(false) 返回内存缓存状态，并且不读取文件缓存。真正判断字符串区时，优先看 interned_strings_usage，不要只看总的 cache_full。

输出中，buffer_size 是实际分配的字符串缓冲区大小，used_memory 和 free_memory 用于观察余量，number_of_strings 表示已驻留字符串数量。若 free 余量持续很小，且字符串数量随版本发布或流量增长，才有理由进入调参；一次瞬时低余量不足以证明必须放大。

按 FPM 实际配置做小步调整

确认容量确实不足后，先保存当前值，再在 FPM 使用的配置文件中调整。例如当前总共享区为 128 MB、字符串区为 8 MB，可以先把字符串区改为 16 MB，同时评估总共享区是否需要同步增加，而不是直接跳到很大的数值。

; 先保留旧值，按环境的 php.ini 目录修改
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
; 生产环境不要把配置写进只对 CLI 生效的 ini 文件

重载后重新访问诊断脚本，必须看到 buffer_size 变成目标值；只执行 php -i 只能证明 CLI 的配置，不能证明 FPM 已采用它。若新值没有变化，按“FPM 主配置文件 → 扩展加载顺序 → 进程重载方式 → 诊断脚本 SAPI”的顺序排查。改动过大时，恢复备份值并再次重载即可回滚。

上线后的复核清单

• 记录调整前后的 buffer_size、used_memory、free_memory 和 number_of_strings。
• 观察一次完整的发布或流量高峰，确认字符串区余量没有持续单向下降。
• 若总 OPcache 仍出现空间不足，分别检查字节码区和字符串区，不要用一个参数掩盖另一个问题。
• 诊断脚本只允许运维入口访问，避免把版本、路径或运行时配置暴露给公网。

相关问题

把 interned_strings_buffer 调大就一定更快吗？

不一定。它只增加字符串驻留空间；如果瓶颈在脚本数量、字节码空间或请求本身，增加该值只会减少其他区域可用空间。

为什么 php.ini 改了，FPM 的 buffer_size 还是旧值？

最常见原因是改错了 SAPI 的配置文件，或者只重启了 CLI 相关进程。以 FPM 实际加载的配置为准，重载后用状态脚本复核。

应该盯 used_memory 还是 number_of_strings？

两者一起看。数量能说明驻留对象是否增长，内存字段才能说明离容量边界还有多少空间；单看数量无法判断每个字符串的内存占用。