hyperf 不建议配置 swap，因其常驻内存特性导致 swap 会引发延迟抖动、gc 加剧及 oom 风险；物理内存不足时，swap-in 阻塞可达百毫秒，拉高 p99 响应时间，且破坏协程内存局部性与 cpu 缓存命中率。
Hyperf 是基于 Swoole 的常驻内存型 PHP 框架，本身不依赖传统 PHP-FPM 的“每次请求重启”模型，因此对系统内存管理更敏感。单台服务器部署 Hyperf 时，不建议主动配置 swap 内存用于性能优化，尤其在生产环境——swap 可能引发延迟抖动、GC 延迟加剧、甚至进程被 OOM killer 强制终止。
为什么 swap 对 Hyperf 不友好？
Hyperf Worker 进程长期运行，持续分配对象、缓存数据、维持协程栈和连接池（如 Redis、MySQL）。当物理内存不足时，Linux 内核可能将部分匿名页（如 PHP 对象堆、Swoole 共享内存）换出到 swap。而 Hyperf 在高并发下频繁访问这些内存区域，一旦触发 swap-in，会造成毫秒级甚至百毫秒级的阻塞，直接拉高 P99 响应时间，且无法通过框架层规避。
- Hyperf 默认启用协程调度器，其底层依赖高效的内存局部性；swap 破坏局部性，降低 CPU 缓存命中率
- Swoole 的共享内存段（如 channel、table）和 PHP 的 opcache JIT 缓冲区通常被标记为
mlock()或MAP_LOCKED，但 swap 仍可能影响关联的匿名映射页 - CentOS 8 默认 swappiness=60，对常驻服务过于激进；Hyperf 类应用应设为 swappiness=1 或 0
真正有效的内存优化方向
与其依赖 swap，不如从资源分配与使用效率入手：
-
限制 Worker 进程数：避免超发。4 核 CPU 建议
worker_num = 4~6（非严格等于 CPU 数），配合max_request = 10000防止内存缓慢泄漏累积 -
调低协程栈大小：默认 2MB/协程，高并发下极易耗尽内存。可在
config/autoload/server.php中设'coroutine' => ['stack_size' => 524288]（512KB） -
关闭未用组件：禁用
Hyperf\Tracer（OpenTracing）、Hyperf\Metric（Prometheus）等重量级中间件，或仅在 debug 环境启用 -
合理配置连接池：Redis/MySQL 连接池
max_connections总和不宜超过物理内存可支撑的连接数（例如 8GB 内存下，Redis 连接池建议 ≤ 200，每个连接约 10–30KB）
若必须保留 swap，仅作安全兜底
仅在测试或低负载边缘场景下，为防突发 OOM 导致服务崩溃，可保留小容量 swap，但需严格约束：
- 创建固定大小 swapfile（非分区），例如
dd if=/dev/zero of=/swapfile bs=1G count=1，然后mkswap /swapfile && swapon /swapfile - 执行
sysctl vm.swappiness=1并写入/etc/sysctl.conf，确保内核极少使用 swap - 监控
cat /proc/swaps和swapon --show，确认 swap 使用量长期为 0；一旦非零，说明内存已严重不足，应扩容或优化代码
swap 不是内存不足的解决方案，而是最后防线。Hyperf 的稳定性与响应时间，取决于你能否让所有关键数据留在 RAM 中——这比任何 swap 参数都重要。
