磁盘使用了偏高问题排查思路

序言

双十一即将来临，做电商的大佬们都准备好了各种应急预案了么。。。例如服务降级，流量控制，扩容方案。。。又快到了一年一度的剁手大会了，不过这个时候，应该是运维最繁忙的时候了吧。。。使用率百分百？用流量打爆。。。Emmm，这很酷

一台服务器，最关键的地方无非在于CPU,内存，网络IO，磁盘IO，一个成为瓶颈都是不可以的，当磁盘IO繁忙的时候，我们可以查查是什么进程导致了磁盘IO繁忙。。。当磁盘被打爆了会如何？Emmm，重启了解一下。。。服务器是没有响应的。

磁盘使用率偏高

在虚拟机中模拟测试，使用dd来模拟写入的操作（写入的文件为zero，输出的文件为kel，每次写入的大小为1M，写入次数为12400）：

使用iostat找出哪块磁盘繁忙，主要看的指标一个是cpu的使用率中iowait值很高，另外一个则是磁盘的使用率util，可以看到sdb的磁盘使用了达到了百分百，完美，磁盘写入很饱和（执行的命令iostat -x 1 。参数-x表示更详细的统计信息，1表示每隔一秒显示一次）。

使用iotop找出使用磁盘繁忙的进程pid，可以看到进程的pid为12339（执行的命令为iotop -Po，参数P表示只显示进程，不显示线程，参数o表示只显示正在进行io操作的进程）：

查看到进程的pid为12339，从而可以查看进程：

也可以使用dmesg来进行打印相关磁盘写入写出的内容使用的命令如下（在统计的时候，先清空dmesg的内容，使用命令为dmesg -c，内核参数记得关闭，否则也会产生大量的io）：

可以看到在这个磁盘上进行读写的每个进程的操作次数，例如进程dd的pid为12408，读写的次数为359次。

inode号也会显示，从而可以看到读写哪个文件：

然后呢？找到了磁盘使用率的程序又如何。。。可能使用磁盘的进程有很多，那么就要考虑分散磁盘的压力，可能sdb的压力很大，有mysql进程，有应用程序的日志存放路径。。。那么一种方法就是分散压力，将数据库进行迁移到其他的磁盘，一种方法就是查看应用程序的日志怎么这么多，是不是哪个傻子使用了debug的日志级别。

风言风语

命令的执行者：

很多人认为作为命令的执行者就毫无责任，怎么可能。。。都是不带脑子的么，做什么事儿不能往脑子里面过过么。。。我就误操作了，你看我骄傲了嘛，你看我自豪了嘛。。。简直是美滋滋。。。

如何在容器里面运行容器呢？为什么要在容器里面运行容器呢？。。。这触碰到了我的知识盲区。。。百思不得其解。。。其实在容器里面运行容器，可以造成一种假象，实际情况是，两个容器都运行在一个物理机上，但是。。。在父容器里面的docker命令改掉了，使用一个label进行过滤，从而就可以假装是运行在容器之中的容器。

docker命令只是一个客户端，我倒是不在意这种实现方式。。。我只是在意这种设计的目标是什么？为什么要这种设计方法？资源隔离？不像。。。在容器进行调度的时候，如果要做负载均衡，直接物理机的调度更加合适，而使用一个中间容器，增加了调度的复杂度，那么，为什么会有这种设计？出于一种什么邪恶的动机？