Hyperf高并发下磁盘IO卡住，是因为fopen等同步文件操作不被Swoole协程接管，仍走libc阻塞路径，直接阻塞Worker进程；必须启用Swoole aio并改用System::readFile/writeFile等协程API，同时禁用opcache.file_cache等隐性IO源。

Hyperf高并发下磁盘IO为什么卡住？

不是PHP代码慢，是 fopen、file_get_contents、file_put_contents 这类同步文件操作在协程中会直接阻塞整个 worker 进程。Swoole 默认不接管这些系统调用，它们走的是标准 libc 阻塞路径，哪怕你开了 enable_coroutine => true，也照卡不误。

典型现象：QPS 上不去，swoole_server->stats() 显示 request_count 增长缓慢，但 worker_request_count 差距大；strace -p [worker_pid] -e trace=open,read,write 能看到大量阻塞的 read() 系统调用。

必须开启 Swoole 的 aio 并重写文件操作逻辑

Swoole 的 aio（异步 I/O）模块基于 Linux 的 io_uring（5.1+）或线程池模拟，能把文件读写转为非阻塞协程友好的调用。但它不会自动替换 PHP 原生函数——你得主动用 Swoole\Coroutine\System::readFile 和 Swoole\Coroutine\System::writeFile。

确保 Swoole 编译时启用了 --enable-async-redis --enable-swoole-aio（检查 php --ri swoole 输出含 aio => enabled）

Hyperf 3.x 默认未启用 aio，需在 config/autoload/server.php 中显式开启：'aio' => true

禁用所有 fopen/file_get_contents，改用：

1. use Swoole\Coroutine\System; 
2.  
3. $content = System::readFile('/path/to/log.txt'); // 返回 string 或 null 
4.  
5. System::writeFile('/path/to/cache.bin', $data); // 返回 bool 

注意：System::readFile 不支持流式读取大文件，超 2MB 容易 OOM；大文件请用 Swoole\Coroutine\Stream + 分块读

日志、缓存、临时文件这三类最容易踩坑

Hyperf 默认日志驱动（Monolog/Handler/StreamHandler）底层仍是 fopen，必须替换成协程安全方案：

用 Hyperf\Logger\Handler\StdoutHandler + 日志采集器（如 Loki/Fluent Bit），绕过本地磁盘

若必须落盘，改用 Swoole\Coroutine\Channel 做缓冲，由 task_worker 统一刷盘（避免协程间竞争）

Redis 缓存比 file 驱动快一个数量级，hyperf/cache 默认已支持 redis，别用 file 驱动存 session 或高频 key

上传临时文件（$_FILES）默认存在 /tmp，且 move_uploaded_file 是阻塞的——应立刻用 Swoole\Http\Request->getUploadedFiles() 获取句柄，再用 System::writeFile 写目标路径

为什么只开 aio 还不够？

因为 aio 只解决「文件读写」，但真实瓶颈常藏在更上游：比如你用 file_put_contents('log.txt', $msg, FILE_APPEND)，即使改成 System::writeFile，频繁小写仍触发大量磁盘 seek；又比如 opcache.file_cache 指向 SSD 目录，但 PHP-FPM 时代遗留的 opcache.revalidate_freq=2 在常驻进程中会导致每两秒扫一次目录，产生隐性 IO。

真正要动的配置不止一处：opcache.file_cache 必须关掉（Hyperf 不依赖它），realpath_cache_size 设为 4M 以上，apc.enable_cli 关闭（CLI 模式下 APC 无效还抢资源）。这些细节不处理，aio 开了也白开。

Tags: Hyperf高并发 开启Swoole的aio异步化

分享到：