部署 Hyperf 容器时，CPU 和内存最好都用 Docker cgroups 做严格约束。不要只停留在“差不多够用”的层面。

CPU 这一块，建议直接上 --cpus 硬限制。轻量服务可按 0.8 来配，中等负载通常用 1.5。

如果运行环境是 NUMA 架构，还可以进一步做核心绑定。

内存方面也不能只设一个上限了事。通常要同时配置 --memory（例如 1g）、--memory-reservation（例如 768m）和 --memory-swap=1g。

然后再据此反推 max_connections 与 pool.size 的合理取值。

与此同时，Hyperf 自身的配置也要同步收紧。比如调整 worker_num、关闭 devtool、启用 opcache、适当下调日志级别。

最后别忘了做验证。结合 docker stats、dmesg 和压测结果看实际表现，再接入 cAdvisor+Prometheus，持续监控限频和 OOM 事件。这一步才是真正把资源控制闭环起来。

Hyperf 本质上是一个高性能、基于协程的 PHP 微服务框架。

但一旦以单机方式部署，又没有提前把资源边界收紧，并发请求突然冲高，或者出现内存泄漏，容器就很容易大量挤占宿主机的 CPU 和内存。

结果也很直接：轻则拖慢其他服务，重则直接触发 OOM Killer。

需要先厘清一点，Docker 并不会主动替你做资源管理。真正把限制执行下去的，其实是 Linux cgroups。

说到底，关键不在“有没有限制”，而在于参数是否设置准确、阈值是否校准到位，以及有没有预留出必要的缓冲空间。

Hyperf 单机部署为何必须先收紧资源边界

单机部署场景下，Hyperf 的高并发能力是一把双刃剑。

• 并发突增时，CPU 很容易被快速拉高
• 出现内存泄漏时，容器可能持续吞噬宿主机内存
• 限制不到位时，其他服务也会被连带拖慢

真正需要关注的，不是是否配置了限制，而是限制是否可执行、可验证、可监控。

CPU 限制：按实际负载选配额或权重

Hyperf 默认启用多协程 Worker。CPU 密集型操作，如 JSON 解析、加密计算，会显著拉升 CPU 使用率。

推荐优先使用 --cpus 做硬性限制：

• 轻量 API 服务（QPS < 500）：设 --cpus=0.8，避免单核跑满引发调度延迟
• 中等负载（含 Redis/MySQL 同步调用）：设 --cpus=1.5，兼顾突发处理能力
• 不建议仅靠 --cpu-shares，因为 Hyperf 进程常驻且活跃度高，权重在空闲时无效，争抢时又难精准控压
• 若宿主机为 NUMA 架构（常见于 16 核以上服务器），可加 --cpuset-cpus="0-2" 绑定物理核心，减少跨节点内存访问开销

内存限制：必须设硬上限 + 合理预留

PHP 应用内存增长往往较隐蔽。Hyperf 的协程栈、连接池、注解反射缓存都会持续占用内存。

仅设 -m 不够，需组合使用：

• 根据 php -i | grep memory_limit 和实际压测峰值，设 --memory=1g（例如）——这是硬上限，超限直接 OOM
• 加 --memory-reservation=768m，告诉内核“这个容器至少需要 768MB 才能稳定启动和运行”，避免内存紧张时被过早回收
• 禁用 swap 更稳妥：--memory-swap=1g（与 --memory 相同），防止交换到磁盘拖慢响应
• 特别注意：Hyperf 的 max_connections 和 pool.size 需按内存反推，例如每连接约占用 2–3MB，1GB 内存不宜配置超过 200 个 MySQL 连接池实例

配合 Hyperf 自身配置做协同优化

Docker 层限制是底座。Hyperf 层配置决定是否真正“守界”。

• 在 config/autoload/server.php 中降低 worker_num（如设为 cpu_count * 2 而非默认的 cpu_count * 4），避免协程数远超 CPU 能力造成上下文切换雪崩
• 关闭开发期无用组件，如 devtool、swagger，减小常驻内存 footprint
• 启用 opcache.enable_cli=1 和合理 opcache.memory_consumption，降低脚本重复加载开销
• 日志级别设为 notice 或 warning，避免 debug 级别高频写入拖慢 IO 并间接抬升 CPU

验证与可观测性不能少

限制不是设完就完事，还要确认它是否生效、是否过紧。

• 实时观察：docker stats hyperf-app 查看 CPU% 和 MEM USAGE，连续 5 分钟 >90% 表示配额偏紧
• 查 OOM 记录：dmesg -T | grep -i "killed process"，若出现 hyperf 相关进程被杀，说明 --memory 设低了
• 压测对比：用 ab 或 hey 对比限制前后 P99 延迟和错误率，确认资源策略未引入明显性能拐点
• 建议接入 cAdvisor + Prometheus，监控 container_cpu_cfs_throttled_periods_total（被限频次数）和 container_memory_oom_events_total，建立告警基线

重点结论

• CPU 用 --cpus 做硬限制，比只配权重更稳妥
• 内存要同时设置 --memory、--memory-reservation、--memory-swap=1g
• Hyperf 参数必须联动调整，尤其是 worker_num、max_connections、pool.size
• 上线后必须通过 docker stats、dmesg、压测和 cAdvisor + Prometheus 做持续验证