Stress-ng项目中的io-uring压力测试在AWS特定实例上的挂起问题分析

问题背景

在AWS云环境的特定实例类型上，使用stress-ng工具进行io-uring压力测试时会出现系统挂起现象。这个问题主要出现在AWS的c3.xlarge和c4.large实例上，操作系统为Ubuntu Jammy、Mantic或Noble版本。

受影响环境特征

经过测试验证，该问题具有以下特征：

1. 硬件平台：仅影响基于Intel Xeon E5-2666 v3(Haswell)的c4.large和基于Intel Xeon E5-2680 v2(Ivy Bridge)的c3.xlarge实例
2. 操作系统：Ubuntu Jammy(5.15.0-112-generic内核)、Mantic和Noble版本
3. 其他AWS实例类型(包括c5n.large、i3.metal、m5a.large等)均不受影响

问题现象

当在受影响环境中执行io-uring压力测试时，系统会出现以下症状：

1. 测试进程无法正常终止，最终因超时被强制结束
2. 系统日志中出现大量任务阻塞超过120秒的警告信息
3. 系统虽然未完全冻结，但变得无响应，无法执行任何命令
4. 必须重启实例才能恢复正常运行

技术分析

从系统日志和测试数据来看，问题主要涉及以下技术层面：

1. I/O子系统阻塞：日志显示多个关键系统进程(jbd2、ext4相关进程、writeback工作队列等)都进入了不可中断的睡眠状态(D状态)，表明存在I/O子系统层面的阻塞。

2. 锁竞争问题：调用栈中频繁出现rwsem_down_write_slowpath和down_write等锁操作，暗示可能存在锁竞争导致的死锁情况。

3. 文件系统交互：大量ext4文件系统相关操作(如ext4_mkdir、ext4_truncate等)被阻塞，说明问题与ext4文件系统的I/O处理流程密切相关。

4. io-uring特性：io-uring作为Linux的高性能异步I/O接口，其工作线程(iou-wrk)也陷入了等待提交队列完成的状态。

解决方案

项目维护者通过代码分析定位到问题根源，并提交了修复方案：

1. 修复措施：在io-uring压力测试模块中增加了对直接I/O(direct I/O)的支持，避免了缓存层可能带来的阻塞问题。

2. 验证结果：修复后的版本在原先出现问题的c3.xlarge和c4.large实例上测试通过，不再出现挂起现象。

经验总结

这个案例为我们提供了几个重要的技术经验：

1. 硬件平台特性可能对I/O性能测试产生意想不到的影响，特别是在虚拟化环境中。

2. 文件系统缓存层在高压力场景下可能成为性能瓶颈，直接I/O在某些情况下是更可靠的选择。

3. 系统监控工具(如vmstat)对于诊断I/O相关问题非常有价值。

4. 压力测试工具需要针对不同硬件平台和内核版本进行充分验证。

这个问题也提醒我们，在云环境中进行系统级测试时，需要特别关注实例类型和内核版本的组合可能带来的特殊行为。