Swoole性能瓶颈排查与优化指南

本文深入剖析了Swoole高性能服务器在实际生产中常见的几大隐性性能瓶颈——从日志级别过低导致关键错误“静默丢失”，到stats()快照精准捕获瞬态连接异常；从协程被同步I/O卡住引发的“假空闲”CPU飙升，到OPcache在CLI常驻进程中的内存缓慢吞噬；再到协程泄漏的隐蔽源头与实时诊断的黄金窗口期。每一步都直击排查盲区，提供可立即落地的命令、配置和代码级优化动作，帮你告别玄学调优，在服务崩溃前就揪出真正的性能杀手。

看日志前先确认 swoole.log_level 是否够细

很多问题根本没进日志，是因为默认日志级别太低——SWOOLE_LOG_INFO 会过滤掉协程调度异常、超时警告、内存分配失败等关键信息。不调高它，等于蒙眼排障。

• 线上环境建议设为 SWOOLE_LOG_WARNING；排查时临时切到 SWOOLE_LOG_DEBUG
• 务必检查 swoole.log_file 路径是否可写，且磁盘没满（常见坑：日志写入失败但无报错，strace 才能发现）
• worker_num 和 task_worker_num 过大时，日志会爆炸式增长，需配合 log_rotation 或外部日志轮转工具

用 swoole_server->stats() 快速定位连接/请求卡点

这个内置方法返回的不是“平均值”，而是实时快照，比监控图表更准——尤其适合抓瞬态瓶颈。比如 connection_count 突增但 request_count 滞涨，基本就是客户端在疯狂重连，而非服务端处理不过来。

• 高频调用 $server->stats() 本身有开销，别放在 onRequest 里每请求查一次
• 重点盯三个字段：start_time（确认是否进程重启过）、accept_count vs close_count（连接泄漏信号）、tasking_num（任务队列是否持续积压）
• 注意：协程内调用需用 Swoole\Coroutine::stats()，和 Server 实例的 stats 是两套数据

CPU 飙高但 top 显示 PHP 进程不占 CPU？查协程阻塞点

这是 Swoole 最典型的“假空闲”现象：协程被同步 I/O 或死循环卡住，Worker 进程实际在忙，但系统级工具看不到——因为没进入内核态，只是 PHP 层面的忙等。

• 用 swoole_coroutine::listCoroutines() 查当前所有协程 ID，再用 swoole_coroutine::getBackTrace($cid) 抓堆栈，90% 的卡点藏在 file_get_contents、curl_exec、未加 timeout 的 Redis 查询里
• 别信 strace -p 的 syscall 统计——协程切换不触发 syscall，它显示“空闲”很正常
• 如果堆栈里反复出现 co::sleep 或 co::wait，说明你在协程里用了同步等待，该换 co::sleep(0.1) 或直接上 co::readFile

内存缓慢上涨却查不到泄漏？关掉 opcache.enable_cli

PHP CLI 模式下开启 OPcache，会导致常量/函数表在进程生命周期内永不释放，Swoole 常驻进程一跑几天，内存就稳涨不跌。这不是代码泄漏，是 PHP 自身机制。

• 检查 php --ini 加载的配置文件，在 php.ini 或 swoole 启动脚本所在目录的 conf.d/ 下，确认 opcache.enable_cli=0
• 用 memory_get_usage(true) 对比 memory_get_usage(false)，若差值巨大（如几百 MB），大概率是 OPcache 占用
• 协程内 new 对象不 unset 不一定泄漏，但 static 变量、全局数组、闭包引用外层变量，才是真·泄漏高发区

理论要掌握，实操不能落！以上关于《Swoole性能瓶颈排查与优化指南》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！