如何为生产环境正确配置Laravel Octane的workers？ (内存管理)

workers数量应设为CPU核心数×2起步（如4核设8），再依octane:status的memory_usage峰值逐步下调，避免OOM；需配合max-requests=300与memory-limit=96M防内存泄漏，且app_DEBUG必须为false。

workers 数量设多少才不爆内存？

Octane 的 workers 数量不是越多越好，它直接决定常驻 php 进程数，每个进程都会占用独立内存（通常 20–50 MB，取决于应用加载的类和配置）。若设为 16 而单进程占 40 MB，仅 workers 就吃掉 640 MB，还没算 Supervisor、redis 连接、OPcache 等开销。

• 用 php artisan octane:status 查看当前各 worker 内存占用（memory_usage 字段）
• 上线前在压测环境跑 ab -n 1000 -c 100 http://localhost/health，同时监控 ps aux --sort=-%mem | head -20
• 保守起见：从 workers = CPU核心数 × 2 开始（如 4 核 → 设 8），再根据 memory_usage 峰值逐步下调
• 切忌在 2 GB 内存的机器上设 workers=12 —— 很可能触发 OOM Killer 杀掉 Octane 主进程

max-requests 配合 memory-limit 才能防内存泄漏

即使没有明显 leak，laravel 应用长期运行后也会因事件监听器残留、静态属性累积、Query Builder 缓存等导致内存缓慢上涨。Octane 的 max-requests 和 memory-limit 是两道保险，但必须配合使用，只设一个效果有限。

• max-requests=500 表示每个 worker 处理 500 个请求后自动重启，适合请求轻、生命周期短的 API
• memory-limit=128M 表示任一 worker 内存超过 128 MB 立即重启（需 PHP 8.0+，且 memory_get_usage(true) 可靠）
• 生产建议组合：max-requests=300 + memory-limit=96M，既避免太频繁重启影响连接复用，又防止内存爬升到危险水位
• 注意：memory-limit 对 swoole 模式有效，RoadRunner 模式需通过 RR 的 supervisor.max_worker_memory 控制

APP_DEBUG=true 会显著放大内存压力

开发时习惯开 APP_DEBUG=true，但在 Octane 下这是高危操作：异常处理器会保留完整 trace、View 编译缓存不清理、日志上下文对象持续堆积，单个请求内存多占 3–8 MB 很常见。

• Octane 启动前必须确保 .env 中 APP_DEBUG=false，否则 octane:status 里能看到 memory_usage 异常偏高
• 调试时不要改 .env 再 reload，而应临时用 php artisan octane:start --server=swoole --workers=2 --max-requests=10 快速验证逻辑
• 若需追踪错误，改用 LOG_LEVEL=debug + 日志服务（如 Papertrail），而非开启全量 debug

Swoole 模式下 opcache.preload 与 workers 的冲突

启用 opcache.preload 能提升冷启动性能，但它会让预加载的类全局共享 —— 而 Swoole 的 workers 是 fork 出来的子进程，若 preload 文件中含静态属性或全局变量，多个 worker 会共用同一份内存地址，引发数据污染或内存无法释放。

• 检查 php --ini 加载的 opcache.ini，确认 opcache.preload 在生产 Octane 环境中被注释或设为空
• 替代方案：用 opcache.enable_cli=1 + opcache.memory_consumption=256，让每个 worker 独立 warm up 自己的 OPcache
• RoadRunner 无此问题（它用多线程而非 fork），但要注意其 rr.yaml 中的 pool.num_workers 仍受内存限制约束

内存不是标量，是随请求模式、中间件深度、Eloquent 关系加载方式动态变化的变量。配完 workers 后，盯住 memory_usage 的 95 分位数，比盯着文档里的推荐值管用得多。