top命令是看当前进程的cpu和内存等的占用情况

参数解析

top - 20:54:37 up 228 days, 11:03, 3 users, load average: 0.54, 0.33, 0.32

Tasks: 266 total, 1 running, 265 sleeping, 0 stopped, 0 zombie

%Cpu(s): 0.3 us, 0.3 sy, 0.0 ni, 99.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st

KiB Mem : 65806688 total, 3267880 free, 51877252 used, 10661556 buff/cache

KiB Swap: 0 total, 0 free, 0 used. 12528752 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

4048 hadoop 20 0 24.9g 1.5g 11372 S 2.7 2.4 1168:24 java

10359 root 20 0 122712 19332 2612 S 2.3 0.0 12:48.32 flux_app

6006 hadoop 20 0 14.7g 1.8g 10964 S 2.0 2.8 5915:47 presto-server

5735 root 20 0 2767844 621184 9808 S 0.7 0.9 3197:27 360entclient

对上面第三行的解释：

us(user cpu time)：用户态使用的cpu时间比。该值较高时，说明用户进程消耗的 CPU 时间比较多，比如，如果该值长期超过 50%，则需要对程序算法或代码等进行优化。

sy(system cpu time)：系统态使用的cpu时间比。

ni(user nice cpu time)：用做nice加权的进程分配的用户态cpu时间比

id(idle cpu time)：空闲的cpu时间比。如果该值持续为0，同时sy是us的两倍，则通常说明系统则面临着 CPU 资源的短缺。

wa(io wait cpu time)：cpu等待磁盘写入完成时间。该值较高时，说明IO等待比较严重，这可能磁盘大量作随机访问造成的，也可能是磁盘性能出现了瓶颈。

hi(hardware irq)：硬中断消耗时间

si(software irq)：软中断消耗时间

st(steal time)：虚拟机偷取时间

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

4048 hadoop 20 0 24.9g 1.5g 11372 S 2.7 2.4 1168:24 java

10359 root 20 0 122712 19332 2612 S 2.3 0.0 12:48.32 flux_app

6006 hadoop 20 0 14.7g 1.8g 10964 S 2.0 2.8 5915:47 presto-server

5735 root 20 0 2767844 621184 9808 S 0.7 0.9 3197:27 360entclient

以上图来说几个重要的参数情况

PID 进程号

USER 运行用户

VIRT 进程使用的虚拟内存总量

RES 物理内存用量

SHR 共享内存用量

%CPU 该进程自最近一次刷新以来所占用的CPU时间和总时间的百分比

%CPU显示的是进程占用一个核的百分比，而不是整个cpu(12核)的百分比，有时候可能大于100，那是因为该进程启用了多线程占用了多个核心，所以有时候我们看该值得时候会超过100%，但不会超过总核数*100

(%CPU>100的情况 这里显示的所有的cpu加起来的使用率，说明你的CPU是多核 你运行top后按大键盘1看看，可以显示每个cpu的使用率，top里显示的是把所有使用率加起来。 )

%MEM 该进程占用的物理内存占总内存的百分比

COMMAND 该进程的命令名称，如果一行显示不下，则会进行截取。内存中的进程会有一个完整的命令行

load average 浅析

上述top命令中的load average: 0.54, 0.33, 0.32 表示了load average的一分钟，五分钟，十五分钟的平均CPU负载

所谓的CPU负载指的是一段时间内任务队列的长度，通俗的讲，就是一段时间内一共有多少任务在使用或等待使用CPU。(当前的"负载值除以cpu核数"就是cpu的利用率)

当CPU完全空闲的时候，平均负荷为0(即load average的值为0)；当CPU工作量饱和的时候，平均负荷为1。

这里需要注意的是：

load average这个输出值，这三个值的大小一般不能大于系统逻辑CPU的个数

比如一台服务器有4个逻辑CPU，如果load average的三个值长期大于4时，说明CPU很繁忙，负载很高，可能会影响系统性能；

但是偶尔大于4时，倒不用担心，一般不会影响系统性能。

load average举例理解

判断系统负荷是否过重，必须理解load average的真正含义。假设当前我的一台服务器只有一个CPU，所有的运算都必须由这个CPU来完成。

不妨把这个CPU想象成一座大桥，桥上只有一根车道，所有车辆都必须从这根车道上通过(很显然，这座桥只能单向通行)。

1)系统负荷为0，意味着大桥上一辆车也没有。

2)系统负荷为0.5，意味着大桥一半的路段有车。

3)系统负荷为1.0，意味着大桥的所有路段都有车，也就是说大桥已经"满"了。但是必须注意的是，直到此时大桥还是能顺畅通行的。

4)系统负荷为1.7，意味着车辆太多了，大桥已经被占满了(100%)，后面等着上桥的车辆为桥面车辆的70%。

以此类推，系统负荷2.0，意味着等待上桥的车辆与桥面的车辆一样多；

系统负荷3.0，意味着等待上桥的车辆是桥面车辆的2倍。

总之，当系统负荷大于1，后面的车辆就必须等待了；系统负荷越大，过桥就必须等得越久。

CPU的系统负荷，基本上等同于上面的类比。大桥的通行能力，就是CPU的最大工作量；桥梁上的车辆，就是一个个等待CPU处理的进程(process)。

如果CPU每分钟最多处理100个进程，那么：

系统负荷0.2，意味着CPU在这1分钟里只处理20个进程；

系统负荷1.0，意味着CPU在这1分钟 里正好处理100个进程；

系统负荷1.7，意味着除了CPU正在处理的100个进程以外，还有70个进程正排队等着CPU处理。

上面，假设我的这台服务器只有1个CPU。如果它装了2个CPU，就意味着服务器的处理能力翻了一倍，能够同时处理的进程数量也翻了一倍。

还是用大桥来类比，两个CPU就意味着大桥有两根车道了，通车能力翻倍了。

所以，2个CPU表明系统负荷可以达到2.0，此时每个CPU都达到100%的工作量。推广开来，n个CPU的服务器，可接受的系统负荷最大为n。

至于load average是多少才算理想，这个有争议，各有各的说法

个人比较赞同CPU负载小于等于"内核数乘以0.5-0.7"算是一种理想状态。

load average返回三个平均值应该参考哪个值

如果只有1分钟的系统负荷大于1.0，其他两个时间段都小于1.0，这表明只是暂时现象，问题不大。

如果15分钟内，平均系统负荷大于1.0(调整CPU核心数之后)，表明问题持续存在，不是暂时现象。

所以应该主要观察"15分钟系统负荷"，将它作为服务器正常运行的指标。

除去CPU性能上的差异，CPU负载是基于内核数来计算的。有一个说法是"有多少内核，即有多少负载"。