hyperf 容器需通过 docker cgroups 严格限制 cpu 和内存：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 将限制落地，关键在于用对参数、配准阈值、留出缓冲。
CPU 限制：按实际负载选配额或权重
Hyperf 默认启用多协程 Worker，CPU 密集型操作（如 JSON 解析、加密计算）会显著拉升 CPU 使用率。推荐优先使用 --cpus 做硬性限制：
- 轻量 API 服务（QPS --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，建立告警基线
