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 分位数，比盯着文档里的推荐值管用得多。
