相信很多同学都遇到过服务器卡的情况，比如SSH登录慢、敲击命令延迟大、web服务响应超时等。遇到这种情况该怎么办？当然是顶级的。在大多数情况下，你会很高兴地发现CPU利用率真的很高，然后通过ps命令最终找到导致这种延迟的xndfj。恭喜，您已经掌握了定位高负载的常用方法。
然而，你发现你并不是每次都那么幸运。偶尔，当你错过时，top会发现cpu利用率很低，甚至不到10%。这时，你可能会再次陷入绝望。这是怎么回事？为什么CPU这么闲还这么卡？这个时候，你有空，看一看，还剩下相当多的记忆，这让你更加绝望。别急，让我们慢慢揭开系统堵塞背后的弱耳机。
其实你漏掉的线索在顶层命令的第一行。可能是顶层输出的信息太多，看起来头大。现在，我将告诉您一个特别简洁的命令来检查负载情况：正常运行时间，您会发现正常运行时间命令的输出是top的第一行输出。但这难道不令人耳目一新吗？
正常运行时间
20:23pm上涨78天3:37，1用户，负载平均： 0.10，0.04，0.05
虽然命令简单，输出信息少，但是你真的理解输出的每一列的含义吗？
当我们不知道这个命令的含义时，我们该怎么办？相信大部分同学都会知道百度，这是一个很好的习惯，但是我建议你不要百度，可以先讲顺序。
正常运行时间显示以下信息。当前时间、系统已运行多长时间、当前有多少用户登录以及过去1分钟、5分钟和15分钟的平均系统负载。
从man正常运行时间的描述中，我们可以看到前三列是当前时间、系统运行时间和登录用户数。但是过去1分钟、5分钟和15分钟的平均负荷意味着什么？
这就是今天写这篇文章的原因。你可能经常在工作中听到“平均负荷”这个词，但你可能不知道它的真正含义。实际上，命令正常运行时间是从文件/proc/loadavg中读取的。当man proc再次进行时，Mndbg将找到文件/proc/loadavg的描述。以下是对平均负载的进一步解释。
该文件中的前三个字段是负载平均数字，给出了在1、5和15分钟内运行队列(状态R)或等待磁盘I/O(状态D)的作业数量的平均值
后三列的含义解释为系统在1分钟、5分钟和15分钟内处于运行队列(R状态)和等待磁盘I/O(D状态)的平均进程数，即平均活动进程数。
什么是R态和D态？运行队列或可运行状态包括正在运行并准备等待中央处理器的进程数。所有进程都必须切换到这种状态，然后才能在CPU上运行。等待磁盘I/O(磁盘睡眠)，也叫不间断睡眠，是指进程处于睡眠状态，但进程是不间断的，也就是不会响应来自系统的信号，比如kill命令。你会发现即使是这种状态下的kill -9进程也不会杀死它。这种状态的意义在于内核的一些处理流程不会被中断。比如读写磁盘时为了保护数据一致性，进程不能中断，除非已经处理完毕，否则会自动退出这种状态。当然还有其他状态，比如S状态。处于这种状态的进程被挂起，因为它们正在等待一个事件(例如等待套接字连接、等待信号量等)。).如果使用ps命令，我们会发现，一般来说，进程列表中的大部分进程都处于S状态(除非机器的负载很高)。毕竟CPU只有几个，进程有几十个几百个。如果大部分进程都没有休眠，CPU如何响应？Z状态是僵尸进程，Z进程不能被杀死，因为是死的，所以叫僵尸进程。我们知道每个进程(pid)都有一个父进程(ppid)。当子进程退出时，它所占用的资源，如内存和一些系统表，将被父进程回收。如果此时子进程异常退出，父进程感知不到子进程的退出，子进程就会变成僵尸进程。男性
CPU负载主要与研发状态有关。您可以使用ps aux命令查看它。
用户PID %中央处理器%MEM VSZ RSS TTY统计开始时间命令
root 6982 0.0 0.0 815668 4792 pts/2 R 21:44 0:00 PS-aux
root 8059 0.0 0.0 0 0？s 2018 1:43[kworker/0:1H]
root 8109 0.0 0.0 0 0？S 2018 3:16 [jbd2/vdb-8]
根
8934 0.0 0.2 258060 16416 ? Sl 2018 1:36 /s糟糕的银耳汤/rsyslogd -i /var/run/syslogd.pid -c 5root 9078 0.0 0.0 0 0 ? S< 2018 0:54 [kworker/1:1H]
root 9201 0.0 0.0 64116 1200 ? Ss 2018 6:22 /usr/s糟糕的银耳汤/sshd
ntp 9612 0.0 0.0 727736 5160 ? Ss 2018 0:17 ntpd -u ntp:ntp -p /var/run/ntpd.pid -g
root 9800 0.0 0.0 78720 3268 ? Ss 2018 1:02 /usr/libexec/postfix/master
root 106222 0.1 0.0 137484 3748 ? Ssl Jan03 22:12 ./糟糕的银耳汤/redis-server *:8000 [cluster]
。。。。。。。
其中stat列的含义是
R 正在运行，或在队列中的进程
S 处于休眠状态
T 停止或被追踪
Z 僵尸进程
W 进入内存交换（从内核2.6开始无效）
X 死掉的进程
< 高优先级
N 低优先级
L 有些页被锁进内存
s 包含子进程
+ 位于后台的进程组；
l 多线程，克隆线程 multi-threaded (using CLONE_THREAD, like NPTL pthreads do)
啰啰嗦嗦了这么多，CPU平均负载简单说就是单位时间内处于R状态和D状态的平均进程数，所以CPU使用率高，平均负载会升高，但是平均负载升高并不一定是CPU使用率高，也可能是IO达到了瓶颈，此时你可以通过iostat观察系统的io情况。
但是CPU负载多少合适呢？有人说肯定越小越好，回答正确，确实是这样的。但是多少会引起瓶颈呢？我们上篇文章Linux篇(1) CPU之基础知识提到，一个CPU在某一个时刻只能处理一个线程，所以对于单核CPU来说，CPU平均负载等于1说明正好有一个进程在运行，平均负载等于0.5说明CPU有50%的时间是空闲的，CPU平均负载等于2说明有一半的进程在排队。但是对于双核CPU来说，平均负载等于1说明有50%的时间是空闲的，平均负载等于2说明刚好进程占满CPU时间。但是为了留有buffer，一般认为平均（负载/cpu核数>0.7）就要关注系统性能问题了。
问题又来了？是看1分钟负载、5分钟负载还是15分钟负载呢？答案是都要看，这三个指标横向对比可以反映系统的性能变化趋势，比如1分钟负载>5分钟负载>15分钟负载说明系统性能问题正在恶化，1分钟负载<5分钟负载<15分钟负载说明系统性能问题正在好转，如果三个指标差不多，说明系统问题很稳定。
小编前段时间就遇到了一种现象，晚上刚吃过饭就收到线上大量报警短信，kubernetes集群的一台主机CPU负载居然高达300左右，此时小编赶紧登陆服务器（24核CPU）查询发现1分钟、5分钟、15分钟系统负载稳定在300左右。通过top查看CPU使用率很低，那应该是磁盘IO问题了，通过iostat命令也没有发现IO存在瓶颈。真是奇怪，小编就想到了是不是D状态的线程比较多呢，通过ps命令发现处于D状态的线程289个，加上一个R状态的线程刚好300左右。我们知道D状态是不可中断状态，怎么解决呢？当然是重启了！