go应用容器内io变慢因blkio.weight对page cache无效，需用cgroup v2的io.weight或io.max；设io.max须避sync、验设备名、测阈值；quota需宿主机文件系统支持且启用对应模块。
Go 应用在容器里读写变慢，cgroup v1 的 blkio.weight 为什么没效果
因为 Go 的 os.File.Read 和 os.File.Write 默认走的是内核缓冲区（page cache），不直接触发块设备 IO；而 blkio.weight 只对直接 IO（O_DIRECT）或同步刷盘路径生效。普通文件操作实际受 cfq（旧）或 mq-deadline/kyber（新）调度器的队列深度和延迟影响更大，不是靠权重能“公平分配”的。
- 确认是否真在走块设备：用
perf record -e block:block_rq_issue -p $(pidof your-go-app)看是否有大量WRITE事件 - 容器若用
cgroup v2，blkio.weight已被废弃，得改用io.weight，且只对 cgroup v2 的 io controller 生效 - Go 进程若开启
sync.Pool复用[]byte，可能放大 page cache 压力，间接加剧 IO 调度抖动
想限制 Go 容器磁盘写入速率，io.max 配置项怎么设才不翻车
io.max 是 cgroup v2 的 IO 限速接口，格式为 "device_path rbps wbps"，但它对 Go 应用有隐藏约束：如果 Go 用了 os.O_SYNC 或 file.Sync()，限速会卡在落盘环节，导致协程阻塞、GOMAXPROCS 闲置，吞吐骤降而非平滑限流。
- 必须用
lsblk -d -o NAME,ROTA,TYPE确认目标设备名（如/dev/sdb），不能写成/dev/sdb1或挂载点路径 - 写入限速建议从
10485760（10MB/s）起步测试，低于 1MB/s 易触发 Go runtime 的 writev 系统调用重试逻辑，反而升高延迟 - 若容器运行时是 containerd，需在
config.toml中显式启用enable_unprivileged_io，否则非 root 容器无法应用io.max
runtime.LockOSThread() 会影响容器内 IO 调度公平性吗
不影响。该函数只绑定 Goroutine 到某个 OS 线程，不改变线程的 cgroup 所属或 IO 调度类。但若你在锁线程后调用 syscall.Read() 或 syscall.Write() 做阻塞 IO，会把整个 P 卡住，间接导致其他 Goroutine 获取不到 M，表现为“看起来 IO 更慢了”——其实是调度器饥饿，不是磁盘不公平。
- 避免在
LockOSThread后做任何阻塞系统调用；如必须，用runtime.UnlockOSThread()临时释放 - Go 1.22+ 默认启用
GOEXPERIMENT=preemptibleloops，但阻塞 IO 仍不可抢占，这点没变 - 用
strace -p $(pid) -e trace=write,read可快速验证是否真有长时阻塞 IO 调用
为什么 golang.org/x/sys/unix 的 Setrlimit 对磁盘配额无效
Setrlimit(RLIMIT_FSIZE) 控制的是单个文件最大大小，不是磁盘总用量；它也不作用于容器根文件系统，只对进程创建的文件生效。真正的磁盘 Quota 需底层支持：XFS 要 uquota 或 pquota 挂载选项，ext4 要 usrquota/grpquota，且容器必须运行在已启用 quota 的宿主机分区上。
立即学习“go语言免费学习笔记（深入）”；
- 检查宿主机：运行
xfs_info /var/lib/containerd或dumpe2fs -h /dev/sda1 | grep -i quota - 容器内无法直接调用
quotactl()，除非以cap_sys_admin启动并挂载带 quota 的 volume - 更可行的替代方案是用
overlay2的overlay.size存储驱动选项限制镜像层大小，或用docker run --storage-opt size=10G
IO 调度公平性和磁盘 Quota 在容器里从来不是单点配置能解决的，cgroup 版本、存储驱动、文件系统特性、Go 运行时行为这四者只要有一处不匹配，限速就变成抽风，Quota 就变成摆设。最容易被忽略的是：容器启动时的 io.weight 或 io.max 设置，如果宿主机内核没加载 blk-cgroup 模块（lsmod | grep blkcg），那所有配置全无效。
