应通过 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，过小会加剧文件扫描开销，间接推高内存
