一次IO性能问题的发现过程
背景
计划搭建两套完全的系统进行压测.
但是发现自己给自己挖了一个坑, 没注意到一个区别.
邮件在三点钟发出去了, 但是问题是我在四点钟发现的.
问题现象
阿里云上面高一个虚拟机 的CPU出现异常的 CPU用量上升的问题.
Busy IOwait 比较高. 有 60%
感觉非常奇怪.
我这边我一开始认为只跑了一个MySQL数据库, 理论上不应该如此.
然后开始问题发现和解决的过程
故障图
问题确认
输入 top 进行确认.
发现的确idle 只有 30% 是存在IO的瓶颈.
立即使用 iostat 进行查看
发现了很诡异的问题
iostat 的结果
问题不对劲
iostat 里面看到很多的磁盘读取, 但是看不到具体的进程
所以机器有卡顿, 并且一号跑的内容可能存在有差池的情况.
立马就很诡异. 我理解iostat 应该能看到所有进程的相关信息
显然, 没有
立即给阿里云提工单.
提工单的工程中, 突然灵机一闪
docker ps 了下
果然发现有之前自己验证 telemetry的容器再跑
立马 systemctl stop docker
在进行 iostat 的查看
大量的读取没有了.
问题反思
1. 虚拟机是我直接clone的. clone之前执行了 systemctl stop docker的处理
但是没有关闭开机自启动.
2. 早上检查机器没有发现异常, 就可以了压测. 并且系统表面上也没有问题.
3. 因为测试结果与自己的预期非常相仿, 加深了自己的主观认识.
当然了最大的收获是 iostat 竟然无法看到 容器内的读写.
后续再进行相关工作时 必须要进行全方面的检查
容器没怎么占内存, 但是没想到占用了那么多的IO
是一个很大的教训.
标签:发现,一次,性能,iostat,问题,IO,docker,虚拟机
From: https://www.cnblogs.com/jinanxiaolaohu/p/18169447