PHP + OpCache 缓存清理：是否需要手动执行清理操作？

开发者是否需要手动清理OpCache？ #

OpCache本身内置LRU（最近最少使用）淘汰机制，当缓存容量占满时，会自动移除最久未被访问的缓存条目，无需开发者日常手动清理。

只有在代码部署更新的场景下，才需要主动清理OpCache——因为OpCache会缓存旧版本的PHP文件，若不清理，用户会持续访问到旧代码。这种情况下的清理是必要的运维/开发操作。

多站点清理导致服务器不稳定的原因及解决方案 #

问题根源 #

同时对多个站点执行OpCache清理，会触发大量PHP进程同时重新编译未缓存的代码，瞬间占用大量CPU、内存资源，导致服务器负载飙升，引发不稳定。

解决办法 #

• 精准清理而非全局重置：不要直接调用opcache_reset()全局清空缓存，改用opcache_invalidate($file_path, true)仅清理变更的单个文件；如果是整站部署，可针对对应站点的PHP-FPM进程池单独清理（不同进程池的OpCache是隔离的）。
• 分批执行清理操作：给不同站点的清理任务设置时间间隔（比如30秒到1分钟），避免所有站点同时触发代码重编译。
• 优化OpCache配置：
  • 调大opcache.memory_consumption：根据站点数量和代码规模，给每个PHP-FPM进程池分配足够的缓存内存，减少频繁触发LRU淘汰的情况。
  • 调整opcache.max_accelerated_files：确保数值能覆盖站点的所有常用PHP文件，避免缓存溢出。
  • 生产环境设置opcache.revalidate_freq=0：关闭自动文件校验，完全依赖部署时的手动清理，减少不必要的开销。
• 利用进程池隔离特性：不同站点使用独立的PHP-FPM进程池，每个池配置独立的OpCache参数，清理时仅操作目标站点的进程池，不会影响其他站点的缓存和运行。

最佳实践总结 #

• 日常运行：完全依赖OpCache的自动LRU淘汰机制，无需手动干预。
• 部署场景：仅在代码变更时，针对变更的站点或文件执行精准清理，避免全局批量操作。
• 配置调优：根据服务器资源和站点规模，合理分配每个进程池的OpCache资源，降低缓存淘汰频率。
• 运维策略：清理操作分批执行，避免瞬间资源过载。

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