什么磁盘慢会导致Linux负载飙升

　　Linu_继承了Uni_以网络为核心的设计思想，是一个性能稳定的多用户网络操作系统。有用户发现磁盘变慢时候会导致Linu_负载飙升，但是不知道什么原因，这篇文章主要介绍了浅谈为什么磁盘慢会导致Linu_负载飙升，小编觉得还是挺不错的，具有一定借鉴价值，需要的朋友可以参考下

　　一、CPU利用率和负载率的区别

　　这里要区别CPU负载和CPU利用率，它们是不同的两个概念，但它们的信息可以在同一个top命令中进行显示。CPU利用率显示的是程序在运行期间实时占用的CPU百分比，这是对一个时间段内CPU使用状况的统计，通过这个指标可以看出在某一个时间段内CPU被占用的情况， 如果被占用时间很高，那么就需要考虑CPU是否已经处于超负荷运作。而CPU负载显示的是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，也就是CPU使用队列的长度的统计信息。

　　CPU利用率高并不意味着负载就一定大，可能这个任务是一个CPU密集型的。一样CPU低利用率的情况下是否会有高Load Average的情况产生呢?理解占有时间和使用时间就可以知道，当CPU分配时间片以后，是否使用完全取决于使用者，因此完全可能出现低利用率高Load Average的情况。另外IO设备也可能导致CPU负载高。

　　由此来看，仅仅从CPU的使用率来判断CPU是否处于一种超负荷的工作状态还是不够的，必须结合Load Average来全局的看CPU的使用情况。网上有个例子来说明两者的区别如下：某公用电话亭，有一个人在打电话，四个人在等待，每人限定使用电话一分钟，若有人一分钟之内没有打完电话，只能挂掉电话去排队，等待下一轮。电话在这里就相当于CPU，而正在或等待打电话的人就相当于任务数。在电话亭使用过程中，肯定会有人打完电话走掉，有人没有打完电话而选择重新排队，更会有新增的人在这儿排队，这个人数的变化就相当于任务数的增减。为了统计平均负载情况，我们5秒钟统计一次人数，并在第1、5、15分钟的时候对统计情况取平均值，从而形成第1、5、15分钟的平均负载。有的人拿起电话就打，一直打完1分钟，而有的人可能前三十秒在找电话号码，或者在犹豫要不要打，后三十秒才真正在打电话。如果把电话看作CPU，人数看作任务，我们就说前一个人(任务)的CPU利用率高，后一个人(任务)的CPU利用率低。当然， CPU并不会在前三十秒工作，后三十秒歇着，CPU是一直在工作。只是说，有的程序涉及到大量的计算，所以CPU利用率就高，而有的程序牵涉到计算的部分很少，CPU利用率自然就低。但无论CPU的利用率是高是低，跟后面有多少任务在排队没有必然关系。

　　CPU数量和CPU核心数(即内核数)都会影响到CPU负载，因为任务最终是要分配到CPU核心去处理的。两块CPU要比一块CPU好，双核要比单核好。因此，我们需要记住，除去CPU性能上的差异，CPU负载是基于内核数来计算的，即“有多少内核，即有多少负载”，如单核最好不要超过100%，也就是负载为1.00，如此类推。

　　Linu_里有一个/proc目录，存放的是当前运行系统的虚拟映射，其中有一个文件为cpuinfo，这个文件里存放着CPU的信息。/proc/cpuinfo文件按逻辑CPU而非真实CPU分段落显示信息，每个逻辑CPU的信息占用一个段落，第一个逻辑CPU标识从0开始。

　　$ cat /proc/cpuinfo

　　processor : 0

　　vendor_id : GenuineIntel

　　cpu family : 6

　　model : 63

　　model name : Intel(R) _eon(R) CPU E5-2630 v3 @ 2.40GHz

　　stepping : 2

　　microcode : 0_36

　　cpu MHz : 2399.998

　　cache size : 20480 KB

　　physical id : 0

　　siblings : 2

　　core id : 0

　　cpu cores : 2

　　apicid : 0

　　initial apicid : 0

　　fpu : yes

　　fpu_e_ception : yes

　　cpuid level : 15

　　wp : yes

　　flags : fpu vme de pse tsc msr pae mce c_8 apic sep mtrr ......

　　bogomips : 4799.99

　　clflush size : 64

　　cache_alignment : 64

　　address sizes : 42 bits physical, 48 bits virtual

　　power management:

　　要理解该文件中的CPU信息，有几个相关的概念要知道，如：processor表示逻辑CPU的标识、model name表示真实CPU的型号信息、physical id表示真实CPU和标识、cpu cores表示真实CPU的内核数等等。

　　逻辑CPU的描述：现在的服务器一般都使用了“超线程”(Hyper-Threading，简称HT)技术来提高CPU的性能。超线程技术是在一颗CPU同时执行多个程序而共同分享一颗CPU内的资源，理论上要像两颗CPU一样在同一时间执行两个线程。虽然采用超线程技术能同时执行两个线程，但它并不象两个真正的CPU那样，每各CPU都具有独立的资源。当两个线程都同时需要某一个资源时，其中一个要暂时停止，并让出资源，直到这些资源闲置后才能继续。因此超线程的性能并不等于两颗CPU的性能。具有超线程技术的CPU还有一些其它方面的限制。

　　二、CPU负载率的计算方式

　　Load average的概念源自UNI_系统，虽然各家的公式不尽相同，但都是用于衡量正在使用CPU的进行数量和正在等待CPU的进程数量，一句话就是runable processes的数量。所以Load average可以作为CPU瓶颈的参考指标，如果大于CPU的数量，说明CPU可能不够用了。

　　但是，在Linu_上有点差异!

　　Linu_上的load average除了包括正在使用CPU的进程数量和正在等待CPU的进程数量之外，还包括uninterruptible sleep的进程数量。通常等待IO设备、等待网络的时候，进程会处于uninterruptible sleep状态。Linu_设计者的逻辑是，uninterruptible sleep应该都是很短暂的，很快就会恢复运行，所以被等同于runnable。然而uninterruptible sleep即使再短暂也是sleep，何况现实世界中uninterruptible sleep未必很短暂，大量的、或长时间的uninterruptible sleep通常意味着IO设备遇到了瓶颈。众所周知，sleep状态的进程是不需要CPU的，即使所有的CPU都空闲，正在sleep的进程也是运行不了的，所以sleep进程的数量绝对不适合用作衡量CPU负载的指标，Linu_把uninterruptible sleep进程算进load average的做法直接颠覆了load average的本来意义。所以在Linu_系统上，load average这个指标基本失去了作用，因为你不知道它代表什么意思，当看到load average很高的时候，你不知道是runnable进程太多还是uninterruptible sleep进程太多，也就无法判断是CPU不够用还是IO设备有瓶颈。

　　从另一个方面来说，也就可以解释为什么磁盘慢时(大量磁盘使用时)，CPU负载会飙高了。基本上我碰到CPU负载高的情况就两种情况：CPU本身处理太多任务，再加上软中断和上下文切换太频繁导致负载高;再就是磁盘太慢导致了不可中断睡眠太多导致CPU负载高。

　　补充：Linu_基本命令

　　①ls 意为list 列出当前文件夹中的文件

　　-l 显示文件的属性 可用ll来表示

　　②alias 别名 看看是否有别名的文件

　　③cd dir 跳跃目录 -P选项 将路径中的链接文件替换成链接指向的文件路径

　　④pwd 查看当前工作的文件夹名 使用-P的选项，会直接进入到其中，相当于cd

　　相关阅读：Linu_shell脚本不执行问题实例分析

　　shell脚本不执行问题：某天研发某同事找我说帮他看看他写的shell脚本，死活不执行，报错。我看了下，脚本很简单，也没有常规性的错误，报“:badinterpreter:Nosuchfileordirectory”错。看这错，我就问他是不是在windows下编写的脚本，然后在上传到linu_服务器的……果然。原因：在DOS/windows里，文本文件的换行符为rn，而在_i_系统里则为n，所以DOS/Windows里编辑过的文本文件到了_i_里，每一行都多了个^M。解决：

　　1)重新在linu_下编写脚本;

　　2)vi:%s/r//g:%s/^M//g(^M输入用Ctrl+v,Ctrl+m)附：sh-_脚本文件名，可以单步执行并回显结果，有助于排查复杂脚本问题。

什么磁盘慢会导致Linu_负载飙升相关文章：

1.linu_的进入磁盘命令

2.linu_系统硬盘安装教程

3.Linu_系统管理命令大全

4.linu_如何查看cpu负载

5.Linu_磁盘空间怎么清理