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 浅析
参考资料:https://www.cnblogs.com/kevingrace/p/6668149.html
上述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负载是基于内核数来计算的。有一个说法是"有多少内核，即有多少负载"。