之前的学习过程中, 对Linux的top命令老是一知半解,然后也不能很清楚的知道各项参数的含义,特地去学习一下然后记录;
Top命令
我们平时会部署一些应用到Linux服务器,所以经常需要了解服务器的运行状态,top
命令就是帮助我们了解服务器当前状态的非常实用的工具。
你可以全面了解当前CPU、内存、进程等一系列当前服务器状态。
在linux终端中,输入top
按下Enter
,立即进入top
界面。
让我们来分析一下,上面显示的内容代表什么意义,以及各块的内容的含义。
|
|
基本参数含义
字段说明
第一行: 基本信息
第二行:任务信息
第三行: 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 性能下降(阿里服务器默认不开)。
第六行: 进程详细信息
实际操作
首行:系统的整体情况概览
|
|
第2行:进程状态
|
|
第3行:CPU状态
|
|
第3-4行: 内存和Swap交换区状态
|
|
最后需要了解的
|
|
NI 负值表示高优先级,正值表示低优先级
常用快捷键操作
shift+e
切换内存显示模式(可重复按键切换)z
切换是否彩色显示(可重复按键切换)m
切换内存显示模式(可重复按键切换)e
切换底部进程中单位的显示模式(可重复按键切换)b
切换高亮选中(可重复按键切换)W
把当前配置保存到文件中,下次启动top会使用当前的配置h
进入帮助菜单 (进入菜单后,可按ESC或q退出帮助菜单)q
退出top
命令
排序字段
底部的进程排序,是可以选择按指定列进行排序的。
- 先按
f
进入字段选择界面, - 然后按
上下键
选择要排序的字段,界面会高亮显示,选中合适的内容 - 确定选中操作后,按下
s
键,激活这个选择。 - 最后按
q
键退出排序字段选择界面。
你会看到不同的排序界面
问题排查模拟
一般,排查问题会用到的top参数, 比如说出现死循环或者死锁了;
先介绍一下使用到的top参数;
top -p 2624 -H
排查问题的思路
**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