一、理解磁盘IO

二、普通文件IO调度

三、磁盘阵列

四、常用命令

4.1 iostat命令详解

五、综合案例(内存&IO)

一、理解磁盘IO

以超市结账为例，来理解磁盘IO的队列情况(结账付款时间 = 等待时间 + 服务时间)

交款总人数(排队的人数多，处理慢)
- 对应到IO，IO请求数多，我的系统处理能力怎么样？
个人买东西的数量(前面人买的东西多，处理慢)
- 对应到IO，单次写入量大和单次写入量小，处理能力怎么样？
结账人员熟练程度(收营员的处理能力)
- 对应到IO，系统不同的硬盘处理空间不一样，处理能力也不一样
超市队列的有几个(队列越多，处理能力越快)
- 对应到IO，有几个IO队列？
该队列有人在等待服务(一个队等的人多，一个队等的人少)
- 对应到IO，有多少请求在当前等待的？
其他条件影响(活动 [超市促销] ，服务时间波动 [早上9点与晚上9点的区别] )等等...

总结：IO队列越少，处理能力越快。单次写入量少，处理能力越快

二、普通文件IO调度

存储通过网络进行传输。从文件系统开始 ---> 存储 ---> 磁盘文件系统 ---> 设备块层 ---> IO 调度层---> 最终写到磁盘空间
IO操作过程：

首先调用系统函数接口read() 或 write()
生成一次IO 请求
放入具体磁盘的IO队列中

三、磁盘阵列

如图，磁盘阵列情况。描述raid0、raid1、raid10、raid5 他们的一些关系，如下：

两块硬盘组成raid1。磁盘利用率，完全备份冗余，各50%
raid0 只保证了效率，没有备份，没有冗余

针对上面两种情况，出现raid10，raid1 安全性(完全冗余备份)，raid0(随机型，通过两边来提效)，最终raid10 既有容量，也有速度【牺牲容量，来换速度】

上图中的raid5，通过一块磁盘冗余，其他磁盘工作【disk0做冗余，其他3块磁盘都用来写】

四、常用命令

df -h # 显示磁盘和文件信息
du -sh * # 统计当前目录下每个文件或者目录的大小
du -sh * | grep M # 按文件大小排序
mount # 挂载光盘(衍生挂载远端的共享文件)
- mount -t nfs 10.6.157.67:/home/work/ /home/lwan/workspace 【实现远端的挂载】

如果是挂载远端文件会对哪些地方有影响？

首先要读要写， IO有影响
挂载的文件读远端的东西，以及要写，写了之后要同步，牵扯到sync 同步，牵扯到网络资源
分析的时候，要根据不同的情况，分成本地IO和网络IO来进行分析

什么时候用挂载，挂载能解决什么问题？

文件共享
- 文件资源上的问题
- 镜像文件【rpm包，代码，日志，系统应用】
磁盘不足
- 硬盘空间只有2个G，挂一个1T的硬盘，可以往1T的硬盘随便写

找到大文件(500MBfile文件)，如果磁盘已经100%了，应该怎么删除？

rm -rf 500MBfile是否正确？如果这样删，会发现空间还是没有释放。节点映射的文件并没有真正的删除(软硬连接)

正确的删除方法是：> 500MBfile # 用覆盖的方法把文件给删除，磁盘文件清除掉

4.1 iostat命令详解

-x 显示扩展的统计信息 -k 显示统计数据字节每秒 -d 显示设备利用率报告

rkB/s 和 wkB/s 读和写的速率
- 与IO超市模型哪个条件关联上？ --->与个人买东西的数量(单次写入量的大小)有关
r/s 和 w/s 每秒向该设备发出的读和写请求数
- 与IO超市模型哪个条件关联上？ --->与交款总人数(发了多少次请求)有关
avgqu-sz 该设备的请求队列的平均长度，avgrq-sz 读请求的平均大小(单位是扇区)
- 与IO超市模型哪个条件关联上？ --->超市队列有几个队列
svctm 设备的平均服务时间(毫秒为单位)
- 与IO超市模型哪个条件关联上？ --->结账人员熟练程度(系统不同的硬盘处理空间不一样，处理能力也不一样)
await 设备发出I/O请求经过的平均时间(毫秒为单位)【这里是服务时间与队列中的等待时间的总和】
%util 在I/O请求发送到设备期间，占用CPU时间的百分比。用于显示设备的带宽利用率。当这个值接近100%时，表示设备带宽已经占满

根据上面各字段的解释，可以得出以下几个问题的思考：

该队列等了多久(有多少请求在当前等待的)？【await-svctm 请求经过的平均时间 - 平均服务时长】

await 越小越好
await = svctm # 说明系统在处理数据的时候，没有等待过，最好

根据上图，可以得出队列的等待时间，为 4.17ms - 1.14ms =3.03ms。3.03ms的值越大越好，还是越小越好？结论是，越小越好，说明请求快，处理能力也同样快

举例理解上述结论：如果写10M数据，希望await - svctm 是1ms处理完好，还是1000ms处理完好？结论当然是1ms处理完好，说明处理数据快。

五、综合案例(内存&IO)

案例1：top 命令中的RES + Swap 是进程实际使用的内存，VIRT（对应的是虚拟地址空间），VIRT如何理解与分析？

举例说明(买房子，总价100W)，可选方案：

首付3成 30W
- 现金20W(free +buff/cache)，借同事10W(swap)
- 现金25W，借同事5W
首付6成 60W
全款 100W

cat /proc/1/status【该命令下，有以下重要信息】

结合上面举例说明的故事(买房)，VIRT反应的是总帐。比如程序在申请进程的时候，申请了300M，实际用了1个G，VIRT对应的是总账。

VmPeak 峰值，反应进程最终占用峰值的内存(类似于买房需要缴税)
Vmsize 反应进程需要用到的总内存数(类似于房子的总价)
VmRSS与VmSwap 反应的是系统怎么组合来满足进程实际需要用到的内存(类似于买房你是首付，还是全款)

VIRT的作用：
通过举例，比如买房，买车，日常开支。可以得出，我们最大能用到的钱(内存)都是 mem.total +swap.total(最大200W)，需要一个整体预估的值(如买房预估210W，实际只花了100W)

系统参数需要设置，允许超过设置申请内存 swap + mem 【sar -r 1】%commit

vm.overcommit_memory =0【默认是0】【2 是永远不可以overcommit】

案例2：根据下图，我们可以对IO进行分析并得出哪些结论

在同等情况下，await 等待时间越短越好，处理能力越好
请求多相同的情况下，还要衡量他们的差异(如svctm服务时长，为什么相差2.5Ms)，需要去分析原因：
- 有可能是IO完成以后唤醒CPU等待时间太长
- await 相同说明任务队列长度
- svctm有可能是"叫号"的时间，2.5svctm有可能是正在处理的服务时间(具体问题具体分析)

根据上述原因，去分析和优化，因为等待和处理是一个完整的请求。

两组对比出来，下面一组IO块设备处理能力强，但CPU能力弱。上面一组，IO块设备处理能力弱(主要留意svctm上下组之间的差异，比如相差5，10倍等就比较明显异常)
也不是绝对的说，await接近或等于svctm就一定好(相同的情况下，有些可能花在流程上的时间比较长，有些可能从队列到服务池所花费的时间比较长)，这些场景都需要去优化

案例3：对于超市(IO)队列的理解

队列越多越好，还是越少越好？队列长度(avgqu-sz) --->越少越好
- 0等待最好，队列少好，说明处理能力强
- 同等情况下，avgqu-sz等的越多，表示排的越长，说明处理能力差
平均的请求队列(avgrq-sz)

同样是排两个队，第一个来了1380人，而第二个来了380，服务时间和等待时间都一样，所以说明，第一个处理能力最好

IO监控时，首先当%util 比较大时，需要去关注，再去详细的分析命令下的其他细分指标
top中的wa指标与iostat %util的区别
- 都反应了IO的实时情况，但在做IO分析时，iostat的实时数据，信号会更强烈一些
IO最终反应到程序上面，甚至反应到文件上
- 跟处理能力有关系(是持续性的，还是波动性的)

当观察IO系统很忙时，如何下一步分析(找进程、找文件)：

找进程【dstat --top -io 、 iotop】
- 也可以通过isof 命令找文件变化最大的，在找进程
找文件【两个方法】
- 方法一：
  - echo 1 > /proc/sys/vm/block_dump 【改内核，dump下设备块的写入信息】
  - dmesg -c > diskio.log 【执行内核命令，把内核的数据写到一个文件中去】
- 方法二
  - 找到进程后，通过shell脚本模拟IO写数据
    - for((i =1; i<100000;i++))；do echo $i >>log.txt sleep 1; done
  - px aux |grep 进程
  - strace -ttt -f -p 进程号

关键字 open write read 等，就能知道该进程下在对文件进行什么样的操作，获得文件
通过上述命令，就可以对IO进行监控分析。