之前的学习过程中, 对Linux的top命令老是一知半解,然后也不能很清楚的知道各项参数的含义,特地去学习一下然后记录;

Top命令

我们平时会部署一些应用到Linux服务器,所以经常需要了解服务器的运行状态,top命令就是帮助我们了解服务器当前状态的非常实用的工具。

你可以全面了解当前CPU、内存、进程等一系列当前服务器状态。

在linux终端中,输入top 按下Enter,立即进入top界面。

1628136486740

让我们来分析一下,上面显示的内容代表什么意义,以及各块的内容的含义。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
top - 12:03:11 up  1:49,  2 users,  load average: 0.00, 0.00, 0.00
Tasks: 319 total,   1 running, 221 sleeping,   0 stopped,   0 zombie
top - 12:12:05 up  1:58,  2 users,  load average: 0.00, 0.00, 0.00
Tasks: 317 total,   1 running, 221 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  4292528 total,  1665160 free,  1373796 used,  1253572 buff/cache
KiB Swap:  3999740 total,  3999740 free,        0 used.  2632412 avail Mem 

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                 
    11 root      20   0       0      0      0 I   0.3  0.0   0:10.95 rcu_sched                                             

基本参数含义

字段说明

第一行: 基本信息

第二行:任务信息

第三行: CPU使用情况

第四行: 物理内存使用情况

buff/cache:

buffers 和 cache 都是内存中存放的数据,不同的是,buffers 存放的是准备写入磁盘的数据,而 cache 存放的是从磁盘中读取的数据

在Linux系统中,有一个守护进程(daemon)会定期把buffers中的数据写入的磁盘,也可以使用 sync 命令手动把buffers中的数据写入磁盘。使用buffers可以把分散的 I/O 操作集中起来,减少了磁盘寻道的时间和磁盘碎片。 cache是Linux把读取频率高的数据,放到内存中,减少I/O。Linux中cache没有固定大小,根据使用情况自动增加或删除。

第五行:交换区使用情况

Swap(内存交换区):

是硬盘上的一块空间。在内存不足的情况下,操作系统把内存中不用的数据存到硬盘的交换区,腾出内存来让别的程序运行。因此,开启swap会一定程度的引起 I/O 性能下降(阿里服务器默认不开)。

第六行: 进程详细信息

实际操作

首行:系统的整体情况概览

1
2
3
名称            系统运行3时:46分            系统负载:1分钟/5分钟/15分钟级
top - 19:25:37 up  3:46,  2 users,  load average: 0.00, 0.05, 0.10
     系统当前时间         当前登录用户数2人       对于单核CPU 1.0表示满负载

第2行:进程状态

1
2
进程总任务数:97个     运行进程1个  96个当前睡眠状态  停止进程0个    僵尸进程0个
Tasks:  97 total,   1 running,  96 sleeping,   0 stopped,   0 zombie

第3行:CPU状态

1
2
Cpu占用比: 用户空间  内核空间  用户定义优先级  空闲   等待IO   硬中断    软中断     虚拟机
%Cpu(s):  1.0 us,  1.0 sy,  0.0 ni, 98.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

第3-4行: 内存和Swap交换区状态

1
2
3
4
单位 物理内存         总量            空闲           已使用           内核缓存用量
KiB Mem :  1014720 total,   207632 free,   313624 used,   493464 buff/cache
    交换区           总量            空闲           已使用              可用内存
KiB Swap:  4095996 total,  3379452 free,   716544 used.   534020 avail Mem

最后需要了解的

1
2
3
4
进程ID      优先级 Nice值 虚拟内存 物理内存 共享内存 CPU  内存    CPU总时间 命令
  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 3548 mysql     20   0  985096   5548   1560 S  0.3  0.5   0:06.74 mysql
                                          进程状态

NI 负值表示高优先级,正值表示低优先级

常用快捷键操作

  • shift+e 切换内存显示模式(可重复按键切换)
  • z 切换是否彩色显示(可重复按键切换)
  • m 切换内存显示模式(可重复按键切换)
  • e 切换底部进程中单位的显示模式(可重复按键切换)
  • b 切换高亮选中(可重复按键切换)
  • W 把当前配置保存到文件中,下次启动top会使用当前的配置
  • h 进入帮助菜单 (进入菜单后,可按ESC或q退出帮助菜单)
  • q 退出top命令

1628136959977

排序字段

底部的进程排序,是可以选择按指定列进行排序的。

  • 先按f进入字段选择界面,
  • 然后按上下键选择要排序的字段,界面会高亮显示,选中合适的内容
  • 确定选中操作后,按下s键,激活这个选择。
  • 最后按q键退出排序字段选择界面。

1628137080774

你会看到不同的排序界面

1628137234657

问题排查模拟

一般,排查问题会用到的top参数, 比如说出现死循环或者死锁了;

先介绍一下使用到的top参数;

top -p 2624 -H

1628138166262

排查问题的思路

**Review代码。**首先想,是否是本身的代码有问题,将代码发给有压测经验的同事帮忙review,并本身对代码review。同事依据经验判断,4核8G的机器不该该会这么慢。

**CPU占用率较高。**因为本身代码中用户ID在首次请求到接口会走一个INSERT或UPDATE分支不然只走查询分支,INSERT或UPDATE分支都有生成惟一键的需求,这部分参考了美团的leaf分布式ID生成算法,即号段思想,获取一个号段后,在本地利用 AtomicLong 进行自增(我把获取号段这部分由数据库改为了redis,并简化了算法,只参照了思路)。AtomicLong 底层是采用CAS的,也就是在并发状况下会进行自旋,致使CPU资源的占用。

**验证CPU占用率的猜测。**将生成惟一Key的方法替换为redis自增。让测试从新再次压测,并无太多变化,排除该问题。

**接口请求速度过慢。**没什么思路,请教了技术经理。技术经理review代码后,以为多是插入和更新等操做影响了,建议给测试一些只会走查询分支的再看看,因而导出一份只走查询分支的数据,让测试从新压测,TPS仍是在180左右,且CPU占用率仍是十分异常,且测试说以前压测的数据库没什么压力,应该不是这个问题。

**排查具体哪一部分调用占时太高。**技术经理建议将代码中调用到ms层(即数据库层到返回到接口层)的部分,都打上调用时间日志,并在ms层底层也打上调用时间日志。打印日志后,再次进行压测,排查日志,发现ms查询数据库只须要3ms,可是从请求ms层到返回接口层耗时高达100+ms,怀疑是平台组框架问题。因而尝试单压接口层check接口,即无逻辑接口,请求后调用ms层check直接返回。本身尝试单压了下check接口,结果tps在280+,技术经理表示这种接口至少得有几千以上的TPS,多是平台组框架问题。可是组长表示以前到这次压测并无升级过平台组框架。

类似的,找到CPU占用高的pid;

查看该pid的进程中线程的具体情况, 利用命令工具获取进程的详细堆栈信息, 通过堆栈信息定位到代码中出问题的位置;

参考资料

https://blog.csdn.net/cdw_sunshine/article/details/84024731

https://www.shangmayuan.com/a/8c6412dfba4f4ff8827d62f3.html

https://www.cnblogs.com/zjfjava/p/10448002.html