应通过 systemd 精细化防护内存泄漏：设 MemoryLimit 与 PHP_MEMORY_LIMIT 双重限制，OOMScoreAdjust 降低内核干预优先级，Restart=on-failure 实现异常退出自动拉起，配合健康检查、日志追踪和内存告警。

Hyperf 单机部署时若出现内存泄漏，不建议让整个系统自动重启，而应通过 systemd 对服务本身做精细化防护：在内存超限时主动终止进程，并立即拉起新实例，既避免服务中断，又防止泄漏蔓延。

确认泄漏类型再动手

先区分是 PHP 堆内泄漏还是系统级 OOM：

• 日志里出现 Fatal error: Allowed memory size of ... exhausted → 属于 PHP 内存限制问题，调 memory_limit 或修复代码即可
• 容器或系统日志中出现 OOMKilled（尤其是 exit code 137）→ 表明被内核 OOM Killer 杀掉，说明是堆外泄漏（协程、连接池、Swoole 原生内存等），需走 systemd 资源控制+重启策略
• 用 ps aux --sort=-%mem | head -5 或 systemctl status hyperf.service 查看 RSS 内存是否持续上涨，配合 journalctl -u hyperf.service -n 50 看是否有频繁退出记录

systemd 服务单元关键配置项

编辑 /etc/systemd/system/hyperf.service，在 [Service] 段加入以下内容：

Content Management Systems

跨平台内容管理系统构建与修改工作流（WordPress、Shopify、Wix、Squarespace、Drupal、WooCommerce、Joomla、HubSpot CMS Hub、Web…）

下载

• MemoryLimit=1.2G —— 设定硬性内存上限，超限后 systemd 会主动 kill 进程（比内核 OOM Killer 更可控）
• OOMScoreAdjust=-500 —— 降低被内核 OOM Killer 选中的优先级，确保 systemd 先干预
• Restart=on-failure —— 进程非正常退出（含被 kill）时触发重启
• RestartSec=3 —— 重启前等待 3 秒，避免瞬时抖动
• StartLimitIntervalSec=0 —— 关闭启动频率限制，否则默认 10 秒内失败 5 次就停服
• Environment="PHP_MEMORY_LIMIT=512M" —— 同时限制 PHP 层堆内存，与上层 MemoryLimit 形成双保险

配套监控与快速响应

光靠重启不够，要能及时发现问题：

• 加健康检查：在 Hyperf 中暴露 /health 接口，用 ExecStartPre=/usr/bin/curl -sf http://localhost:9501/health || exit 1 做启动前探活
• 启用日志追踪：StandardOutput=journal + StandardError=journal，方便用 journalctl -u hyperf.service -f 实时观察
• 设置内存告警：配合 systemctl show --property=MemoryCurrent hyperf.service 定期采集，超过阈值发通知（如用 shell 脚本 + 钉钉 webhook）

避免重启失效的细节

常见坑点必须避开：

• 修改完 service 文件后，一定要运行 sudo systemctl daemon-reload && sudo systemctl restart hyperf.service
• 不要依赖 Restart=always —— 它会在任何退出时重启，包括你手动 stop，容易掩盖真实问题
• 如果用了 Supervisor 管理 Hyperf，必须停用它，否则和 systemd 冲突，导致重启逻辑混乱
• 检查 php.ini 中的 opcache.enable=1 和 realpath_cache_size，过小会加剧文件扫描开销，间接推高内存