基于html的个人网站的设计与实现论文,php网站开发源码,服务好的常州网站建设,网站开发工程师工作职责前言#xff1a;日常工作中#xff0c;线上服务会出现各种奇奇怪怪的问题#xff0c;每次出现问题都是根据现象猜测出现问题的原因#xff0c;比如请求响应慢了#xff0c;就排查整个请求的逻辑#xff0c;每一步花了多少时间#xff0c;分析半天终于发现是某一步慢了以…前言 日常工作中线上服务会出现各种奇奇怪怪的问题每次出现问题都是根据现象猜测出现问题的原因比如请求响应慢了就排查整个请求的逻辑每一步花了多少时间分析半天终于发现是某一步慢了以后在分析为什么慢。用这样的方式排查问题效率很低而且很容易查错方向导致不能及时解决问题。直到有一天一位前辈指点道出现问题不知道怎么回事查看系统监控啊。。。这才恍然大悟。 于是我就想整理一下有哪些值得关注的系统监控可以查看。这个帖子linux系统监控命令汇总给了我思路可以从内存、cpu、硬盘、网络四个方面对系统进行监控。于是我开始整理相关的命令然后到了磁盘io的时候查到了iostat命令。在这个帖子IO实时监控命令iostat详解中介绍iostat -x 输出的内容里有一个avgqu-sz 是平均请求队列的长度。并且说队列长度越短越好。然后我就不禁好奇这个队列是什么呢操作系统处理磁盘io的模型是什么呢于是展开了这次学习之旅。 正文 这次学习首先发现了之前的一些理解上的偏差就是用户态和内核态和阻塞的关系 用户态中进程执行read()方法因为cpu的运算速度远大于磁盘的寻址速度所以这个操作是阻塞的。之前我错误的理解是用户进程执行read()方法会导致进程阻塞所以接下来会进入另一个进程同时因为是系统调用所以会进入内核态所以我理所当然的认为内核态也是一个进程比如有n个进程都调用read方法这个时候内核进程就会把这些io请求放到一个队列里去调度。正好跟iostat中的队列相对应。 然鹅这个观点是及其错误的用户态和内核态是一个进程的两种状态两种状态的区别是权限级别不一样所以用户态进程执行read()方法并不会发生上下文切换只是改变了进程的特权等级。 那么问题就来了进程什么时候阻塞的队列又在哪里呢后来就看到了这个帖子read系统调用深度剖析里边讲到read内核态的操作是在不同层上处理的比如我们要reada.txt,表面上看这是读取一个文件算一个read请求但是实际上这个a.txt只是vfs的抽象出的概念底层具体文件系统一直到设备驱动层有可能就变成了对多个扇区的访问。所以iostat监控的请求数量并不是我们进程中执行read的数量而是具体对磁盘扇区操作请求的数量。 接下来的问题就是队列在哪里呢比如有n个进程都要读写磁盘这些进程会在一个队列里边排队一个一个执行吗这个逻辑明显是有漏洞的如果一个进程读很大的文件岂不是要把其他进程饿死。还好发现了这个帖子CFQ完全公平队列,里边讲到目前内核中默认的调度算法应该是cfq叫做完全公平队列调度。这个调度算法人如其名它试图给所有进程提供一个完全公平的IO操作环境。它为每个进程创建一个同步IO调度队列并默认以时间片和请求数限定的方式分配IO资源。也就是说对于每个进程的多个io操作都会放到一个队列中。io调度层根据时间片调度这些请求。当某一个时间片该进程的数据读取完成了方法返回如果时间片内没有读取完进程进入阻塞。 所以所谓的阻塞的系统调用并不是调用后立刻就进入阻塞状态而是进入内核态以后在特定的条件下把进程阻塞掉。所以也就有了非阻塞的io调用在自己的时间片内执行不完io操作不进入阻塞而是直接返回失败。下次再调用的时候再执行一部分io操作直到某一次调用把数据读取完了返回成功。 另一个疑问是文章提到当设备完成了 IO 请求之后通过中断的方式通知 cpu比如某个进程将请求加入自己的队列以后把队列中相邻的请求优化掉然后对磁盘发起读请求这个时候后续的读操作到底需不需要cpu参与呢如果需要的话感觉就不需要中断通知了。如果不需要的话磁盘自己能把数据写入内存吗 然后就查到了这个硬盘属于外储存器CPU只能直接读取内储存器如果cpu只能读取内存的话队列中对于磁盘扇区到读写操作就不会占用cpu资源。但是数据到达内存以后复制到用户空间需要cpu参与所以大量文件到读写还是会占用cpu资源。 总结一下iostat有两个数据监控一个是cpu一个是硬盘之所以这么设计我的理解是把io操作分为了需要cpu和不需要cpu的两个阶段可以针对两个阶段的监控信息分别分析问题比如如果硬盘监控的%util接近100%说明磁盘一直在读写扇区这个时候硬盘是瓶颈。如果硬盘正常cpu彪高说明大量内存的读写占用了大量cpu这时cpu是瓶颈。 另外因为cfq队列对每个进程都维护一个队列所以iostat中avgqu-sz 是平均请求队列的长度是所有队列的平均值。 补充一点的话还看到这么个说法传统磁盘本质上一种机械装置如FC,SAS,SATA磁盘转速通常为5400/7200/10K/15K rpm不等。影响磁盘的关键因素是磁盘服务时间即磁盘完成一个I/O请求所花费的时间它由寻道时间、旋转延迟和数据传输时间三部分构成。寻道时间Tseek是指将读写磁头移动至正确的磁道上所需要的时间。寻道时间越短I/O操作越快目前磁盘的平均寻道时间一般在3-15ms。旋转延迟Trotation是指盘片旋转将请求数据所在扇区移至读写磁头下方所需要的时间。旋转延迟取决于磁盘转速通常使用磁盘旋转一周所需时间的1/2表示。比如7200 rpm的磁盘平均旋转延迟大约为60*1000/7200/2 4.17ms而转速为15000 rpm的磁盘其平均旋转延迟约为2ms。数据传输时间Ttransfer是指完成传输所请求的数据所需要的时间它取决于数据传输率其值等于数据大小除以数据传输率。目前IDE/ATA能达到133MB/sSATA II可达到300MB/s的接口数据传输率数据传输时间通常远小于前两部分时间。因此理论上可以计算出磁盘的最大IOPS即IOPS 1000 ms/ (Tseek Troatation)忽略数据传输时间。假设磁盘平均物理寻道时间为3ms, 磁盘转速为7200,10K,15K rpm则磁盘IOPS理论最大值分别为IOPS 1000 / (3 60000/7200/2) 140IOPS 1000 / (3 60000/10000/2) 167IOPS 1000 / (3 60000/15000/2) 200也就是说磁盘瓶颈的本质是转速10K的硬盘每秒最多处理167个请求如果iostat监控发现r/s超过了167肯定会导致%util 100%以及很高的await所以硬盘的瓶颈是请求次数。而cpu的瓶颈是访问的数据量因为越大的数据量就需要越多的指令去复制拷贝。总结 最开始分析内存监控的时候发现了cache和buffer区的概念对磁盘的操作会把磁盘数据缓存到cache中也就是说如果写一个测试用例不停的读写同一个文件看监控并不会发现%util有变化因为都是对内存的操作。附录 linux磁盘io调度算法linux IO调度算法最后让我们保持独立思考不卑不亢。长成自己想要的样子 (引用自 我非常喜欢的B站up主 ”独立菌儿“的口头禅哔哩哔哩 ( ゜- ゜)つロ 乾杯~ Bilibili)
