linux系统资源分析 - 磁盘IO篇
目录
一、理解磁盘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 进程号
- 找到进程后,通过shell脚本模拟IO写数据
- 方法一:
关键字 open write read 等,就能知道该进程下在对文件进行什么样的操作,获得文件
通过上述命令,就可以对IO进行监控分析。
linux系统资源分析 - 磁盘IO篇相关推荐
- Linux性能分析之IO篇
硬盘IO篇 这里用到iostat用于分析磁盘IO的利器 iostat 3 10 的意思是每3秒检测一次,一共检测10次 %iowait 值得注意的一个地方,表示理论上越低表示磁盘越不繁忙. tps:每 ...
- 【转】一文掌握 Linux 性能分析之网络篇(续)
[转]一文掌握 Linux 性能分析之网络篇(续) 在上篇网络篇中,我们已经介绍了几个 Linux 网络方向的性能分析工具,本文再补充几个.总结下来,余下的工具包括但不限于以下几个: sar:统计信息 ...
- 利用 BLKTRACE 和 BTT 分析磁盘 IO 性能
本文永久链接: 利用 BLKTRACE 和 BTT 分析磁盘 IO 性能 | IT老男孩 平时我们在 Linux 上查看磁盘 I/O 性能,可能我们首先就会想到 iostat 命令(包含于 sysst ...
- cacti监控linux和windows磁盘IO
cacti监控linux和windows磁盘IO 标签:cacti linux磁盘IO windows磁盘IO 原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 .作者信息和本声明.否则 ...
- linux系统资源分析 - 内存篇
目录 一.早期的内存使用与内存管理技术演变 二.free命令详解 2.1 基本名词解析 2.2 buffer 与 cache 的区别? 2.3 内存计算公式 2.4 物理内存使用公式 2.4.1 只有 ...
- linux内核分析--异步io(二)
该分析sys_io_submit函数了,这个函数有点复杂,但是条理很清晰,先说一句就是提交异步io,具体怎么提交呢?我们知道,对于异步io,一次性可以提交多个请求,那么可以想象的就是在sys_io_s ...
- (一文了解)linux性能分析之CPU篇
目录 前言 一.CPU 性能指标 1.CPU使用率 2.负载均衡 3.上下文切换 4.CPU缓存命中率 二.常用工具 1.uptime 2.vmstat 3.mpstat 4.top 5.sar 6. ...
- cacti监控linux和windows磁盘io,cacti监控下添加对磁盘io的监控方法(Linux主机和Windows主机)...
添加对磁盘io的监控方法 下述所用的安装包请到我的下载中去下载 一.Linux下 1.下载snmpdiskio-0.9.6 将snmpdiskio 放到 /usr/local/bin/snmpdisk ...
- linux系统解决磁盘IO使用率很高
1.查询 1.1,top 命令 查看wa 指标 top 命令通过查看 CPU 的 wa% 值来判断当前磁盘 IO 性能.如果这个数值过大,很可能是磁盘 IO 过高. 注意:如果 cpu 当前使用率已经 ...
最新文章
- 浅析C语言的一个关键字——register
- Python-----多线程threading用法
- Michael Jordan获2020IEEE冯诺依曼奖,曾培养吴恩达、Bengio
- HDU - 5769 Substring(后缀数组)
- R语言与非参数检验之两独立样本中位数检验
- Jmeter(四十八)_动态线程分析HTML测试报告
- SimpleDateFormat 类的总结
- 流程机器人 RPA:AI落地的接盘侠 | 甲子光年
- HTML和CSS中电子字体的显示与制作
- pano2vr怎么制作漫游_如何制作全景图?Pano2VR制作FLASH全景图教程
- Leo:一个outlining editor
- Windows Server 2016 实现跨域、跨林之间的访问
- Win10+Android+夜神安卓模拟器 搭建ReactNative开发环境
- python 获取路由器中设备ip地址_Python中如何获取当前机器的IP地址
- word嵌入对象依损坏_出错提示“Word 未能写某些嵌入对象,因为内容或磁盘空间不足”...
- react-navigation goBack()传值
- 全球域名后缀注册量排行榜!
- JAVA实现资源文件映射
- 爬取智联招聘网站的手段(scrapy)
- 洛谷P4961 小埋与扫雷
热门文章
- MongoDB中的聚合管道($lookup多表关联查询、$unwind、$match、$project)
- URL中关于空格的编码转换成+或转换成%20的问题
- 华为od统一考试B卷【阿里巴巴找黄金宝箱(IV)】C++ 实现
- php的libxml函数
- 老ipad不能下载和更新app store中的app解决方法
- Zxing与 Zbar生成二维码最简单的实现方式
- 如何针对Grpc接口进行测试之三种方式
- QT实现TCP网络通信
- 考研二战日记——第133+134天小结
- 小孔成像实验探究的软件_小孔成像、凸透镜成像及全部光学内容梳理,超详细!(打印)...