系统load排查思路

1、什么是系统负载？

   WikiPedia: the system load is a measure of the amount of work that a computer system is doing负载指的是一种对计算机系统正在处理的工作的度量指标。简单说就是：进程队列的长度，即多少进程等待被cpu调度。等待的进程少，load低，等待的进程多，load高。

2、什么因素可以造成load的变化？

 load的变化反应的也是系统资源使用情况的变化。 决定因素：      cpu的使用、内存的使用、IO资源的使用      因为一个进程能够被cpu调度，需要有cpu资源、内存资源、IO资源。缺少任何一种资源都能导致进程等待。

注意： 中央处理器的体系架构可以分为：冯·诺依曼结构和哈佛结构

3、如何判断一个系统负载高？

（1）查看系统cpu的个数（2）查看cpu的1、5、15分钟的平均load值与cpu个数比较。平均负载：一段时间来系统的负载情况，一般取1分钟、5分钟、15分钟  

针对单核cpu
load average的含义：

不同load说明问题： 

       1）1分钟Load>1，5分钟Load<1，15分钟Load<1　　　　　　　短期内繁忙，中长期空闲，初步判断是一个抖动或者是拥塞前兆　　　　2）1分钟Load>1，5分钟Load>1，15分钟Load<1　　　　　　短期内繁忙，中期内紧张，很可能是一个拥塞的开始　　　　3）1分钟Load>1，5分钟Load>1，15分钟Load>1　　　　　　短中长期都繁忙，系统正在拥塞　　　　4）1分钟Load<1，5分钟Load>1，15分钟Load>1　　　　　　短期内空闲，中长期繁忙，不用紧张，系统拥塞正在好转

多核CPU分析

    n核cpu时，load<n，系统负载都属于正常情况。

    查看cpu核数量：grep 'process' /proc/cpuinfo | wc -l    关于cpu理解：   # 总核数 = 物理CPU个数 X 每颗物理CPU的核数    # 总逻辑CPU数 = 物理CPU个数 X 每颗物理CPU的核数 X 超线程数   # 查看物理CPU个数    cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l   # 查看每个物理CPU中core的个数(即核数)    cat /proc/cpuinfo| grep "cpu cores"| uniq   # 查看逻辑CPU的个数   cat /proc/cpuinfo| grep "processor"| wc -l

4、如何判断是哪个因素造成系统load过高？工具top、iostat

  先声明系统load高，不代表cpu资源不足。    Load高只是代表需要运行的队列累计过多了。但队列中的任务实际可能是耗Cpu的，也可能是耗i/0及其他因素的

（1）判断cpu使用情况
top中的第三行Cpu(s)行展示了当前CPU的状态:

wa低，us高 ：说明系统缓慢的原因在于进程占用大量CPU，通常还会伴有教低的id，说明CPU空转时间很少；
wa低，id高 ：可以排除CPU资源瓶颈的可能；
wa高 ：说明I/O占用了大量的CPU时间，需要检查交换空间的使用，交换空间位于磁盘上，性能远低于内存，当内存耗尽开始使用交换空间时，将会给性能带来严重影响，所以对于性能要求较高的服务器，一般建议关闭交换空间。另一方面，如果内存充足，但wa很高，说明需要检查哪个进程占用了大量的 I/O资源。

（2）判断内存使用情况，可用free -m
top中的第四五行展示了当前内存的状态:

区分cache和buffer：buffer缓冲、cache缓存

（3）判断IO情况
iostat判断磁盘IO的情况

%util： 采样周期内用于IO操作的时间比率，即IO队列非空的时间比率
如果该参数是100%表示设备已经接近满负荷运行了（当然如果是多磁盘，即使%util是100%，因为磁盘的并发能力，所以磁盘使用未必就到了瓶颈）。

5、判断哪个进程导致的资源使用过度？

 top分析 lsof分析 jstack分析      

参考：
http://dbanotes.net/arch/unix_linux_load.html
http://blog.csdn.net/lxcboke/article/details/52135172
https://www.cnblogs.com/baby123/p/6552537.html
http://heipark.iteye.com/blog/1340384
https://www.cnblogs.com/emanlee/p/3587571.html
https://www.cnblogs.com/ggjucheng/archive/2013/01/13/2858810.html