2019尚硅谷互联网大厂高频重点面试题（第2季）7 Linux和github常用指令，top，vm mp pid io if 的 stat，free，df，ps -mp，jstack

Linux

9.生产环境服务器变慢，诊断思路和性能评估谈谈?

10.假如生产环境出现cPu占用过高，请谈谈你的分析思路和定位

11.对于JDK自带的vw监控和性能分析工具用过哪些?一般你是怎么用的?

netstat

帮助

man命令也可以查看内部命令。区别man命令是查看的所有内部命令，然后再去一个一个找。
而help命令是单独查看一个内部命令。
info命令的帮助信息是一套完整的资料（相当于一本书）

top --help
top: inappropriate '-help'
Usage:
  top -hv | -bcHiOSs -d secs -n max -u|U user -p pid(s) -o field -w [cols]

基本命令

top

整机: top 看CPU和内存

uptime，系统性能命令的精简版

top H

  * H - Threads mode     Off (summarize as tasks)

#load average 系统的负载均衡。1分钟，5分钟，15分钟。
# 3个值 相加。 /3 * 100% 如果高于60%，说明压力重
# 按键盘上的1，能看到 哪个CPU慢。

top - 04:48:58 up 1 day, 22:32,  4 users,  load average: 0.50, 0.55, 0.82
Tasks: 267 total,   1 running, 266 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.8 us,  1.1 sy,  0.0 ni, 97.9 id,  0.0 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem :  7990288 total,  1680960 free,  2307124 used,  4002204 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  5165392 avail Mem

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 12632 root      20   0 1934760 908940  47524 S   8.6 11.4 304:11.72 kube-apiserver

uptime
 05:03:37 up 1 day, 22:47,  4 users,  load average: 0.33, 0.48, 0.78

cat /proc/cpuinfo |grep "cpu core"|wc -l
2

2.看一下是否开启超线程

cat /proc/cpuinfo | grep "processor" | wc -l
2

显然没有开启超线程,因为cpu线程数和cpu核数相同。

Linux top命令的load average满负荷是cpu核心的个数,实际上应该比满负荷的值要小,不然会影响性能。

**如果负载超过cpu核心数的话,则说明系统超负荷运行。**而负载最大值和并发执行的线程数有关,大小基本和并发执行的线程数一致。有了对load average的大致了解后,就可以判断出系统的性能状况,好做出相应的调整。现在来回答开篇提到的那个问题是否load average大于1(小于2)就是系统负载比较高就非常容易了。首先要看一下cpu的核数和线程数,如果是单核CPU,负载等于1就是满负荷运转了,如果是四核、甚至更多核心的CPU,负载大于1这说明系统当前负载很小,不需要过多关心。

vmstat

CPU: vmstat

查看cPu(包含不限于)

vmstat -n 2 3
一般vmstat工具的使用是通过两个数字参数来完成的，第一个参数是采样的时间间隔数单位是秒，第二个
参数是采样的次数

-procs

r:运行和等待CPU时间片的进程数，原则上1核的CPU的运行队列不要超过2，整个系统的运行队列
不能超过总核数的2倍，
否则代表系统压力过大
b:等待资源的进程数，比如正在等待磁盘I/0、网络I/0等。
- block 阻塞

-cpu

us:用户进程消耗CPU时间百分比，us值高，用户进程消耗CPU时间多，如果长期大于50%，优化程
序;
sy:内核进程消耗的CPU时间百分比;
us + sy参考值为80%，如果us + sy大于80%,说明可能存在CPU不足。
- 下面的是 1+2 = 3，代表是3%

id:处于空闲的CPU百分比. 越高越好。
wa:系统等待IO的CPU时间百分比.
st:来自于一个虚拟机偷取的CPU时间的百分比

vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 1678012   2104 4007628    0    0     3    68   13    1  1  2 97  0  0
 
vmstat -n 2 3 #没2秒采样一次，共计采样3次
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 1667612   2104 4008932    0    0     3    68   14    2  1  2 97  0  0
 0  0      0 1667228   2104 4008936    0    0     0   100 4296 7291  0  1 99  0  0
 0  0      0 1668380   2104 4008928    0    0     0    75 5820 8962  1  1 98  0  0

sysstat的 mpstat

查看所有cpu核信息

比 top更细
mpstat，全称为Multiprocessor Statistics。是实时系统监控工具

yum install -y sysstat
mpstat -P ALL 2 #每2秒采样一次


mpstat -P ALL 4
Linux 3.10.0-957.el7.x86_64 (master01)  01/22/2023      _x86_64_        (8 CPU)

05:19:37 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
05:19:41 AM  all    0.89    0.00    1.08    0.00    0.00    0.16    0.00    0.00    0.00   97.88

pidstat

每个进程使用cpu的用量分解信息

ps -ef | grep java

pidstat  -u 1 -p 进程编号。  #每秒采样一次
pidstat -p 进程号 -r 采样间隔秒数 #也能看内存

pidstat  -u 3
Linux 3.10.0-957.el7.x86_64 (master01)  01/22/2023      _x86_64_        (8 CPU)

05:21:55 AM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
05:21:58 AM     0         1    0.33    0.00    0.00    0.33     0  systemd
05:21:58 AM     0         9    0.00    0.66    0.00    0.66     5  rcu_sched
05:21:58 AM     0      9335    1.66    1.99    0.00    3.64     7  kubelet

** vm sys的mp pid 的 stat

free -m

内存: free

free -g #单位是g没用
free -m #内存为8G
              total        used        free      shared  buff/cache   available
Mem:           7803        2288        1564           8        3950        5009
Swap:             0           0           0

[root@master01 ~]# free 单位为字节
              total        used        free      shared  buff/cache   available
Mem:        7990288     2332304     1612976        8408     4045008     5140836
Swap:             0           0           0

–经验值
·应用程序可用内存/系统物理内存>70%内存充足
·应用程序可用内存/系统物理内存<20%内存不足，需要增加内存·20%<应用程序可用内存/系统物理内存<70%内存基本够用

pidstat

pidstat -p 进程号 -r 采样间隔秒数 #也能看内存

df

硬盘: df

查看磁盘剩余空间数

df -h #disk free。human人类看得懂的方式

iostat -xdk

磁盘lo: iostat

mysql 大表存储查询

磁盘l/o性能评估

iostat -xdk 2 3 #查询3次，没2秒执行1次。

Linux 3.10.0-957.el7.x86_64 (master01)  01/22/2023      _x86_64_        (8 CPU)

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.43    0.20   57.28    22.60   527.31    19.13     0.01    0.25    2.43    0.25   0.18   1.05
dm-0              0.00     0.00    0.20   57.71    22.41   527.22    18.98     0.02    0.26    2.47    0.26   0.18   1.05
dm-1              0.00     0.00    0.00    0.00     0.01     0.00    52.91     0.00    0.17    0.17    0.00   0.09   0.00

磁盘块设备分布
rkB/s每秒读取数据量kB;
wkB/s每秒写入数据量kB;
svctm l/O请求的平均服务时间，单位毫秒;

await l/O请求的平均等待时间，单位毫秒;值越小，性能越好;
util一秒中有百分几的时间用于IO操作。接近100%时，表示磁盘带宽跑满，需要优化程序或者增加磁盘;
rkB/s、wkB/s根据系统应用不同会有不同的值，但有规律遵循:长期、超大数据读写，肯定不正常，需要
优化程序读取。
svctm的值与await的值很接近，表示几乎没有IIO等待，磁盘性能好，
如果await的值远高于svctm的值，则表示I/O队列等待太长，需要优化程序或更换更快磁盘。

pidstat

pidstat -d 采样间隔秒数 -p 进程号

ifstat

网络lo: ifstat

ifstat(英文全拼:network interfaces status)

ipconfig #windows 查看IP

默认本地没有，下载ifstat

wget http://gael.roualland.free.fr/ifstat/ifstat-1.1.tar.gz
#需要连接外网

tar -zxvf ifstat-1.1.tar.gz

cd /ifstat-1.1

./configure

make && make install

ifstat 1 #每秒看一次

各个网卡的in、out

观察网络负载情况

程序网络读写是否正常

一程序网络lO优化

一增加网络I/O带宽

生产环境CPU占用高

结合Linux和JDK命令一块分析案例步骤

top

1.先用top命令找出CPu占比最高的

ps -ef 或 jsp -l

2.ps -ef或者jps进一步定位，得知是一个怎么样的一个后台程序

ps -ef | grep 12632 | grep -v grep
jps -l | grep atguigu

 ps的意思是process status,
 
 -e       //显示所有程序
 -f       //显示UID,PPIP,C与STIME栏位
 
显示UID PID PPID C STIME TTY TIME CMD这几个选项
UID：用户ID
PID：进程ID
PPID：父进程ID
C：CPU用于计算执行优先级的因子。数值越大，表明进程是CPU密集型运算，执行优先级会降低；数值越小，表明进程是I/O密集型运算，执行优先级会提高
STIME：进程启动的时间
TTY：完整的终端名称
TIME：CPU时间
CMD：完整的启动进程所用的命令和参数

ps -mp 进程 -o tid

3.定位到具体线程或者代码

找到这个线程，CPU占用最高的

ps -mp 进程 -o THREAD,tid,time #tid就是线程

-m显示所有的线程
-p pid进程使用cpu的时间
-o该参数后是用户自定义格式

printf “%x”

4.将需要的线程Io转换为16进制格式(英文小写格式)

假如 5102 进程，转换成16进制为：13ee

printf "%x\n" 有问题的线程ID 。这是转换16进制

printf "%x\n" 5102
13ee

jstack 进程 | grep tid

5.jstack 进程ID | grep tid(16进制线程ID小写英文)-A60

jstack 看死锁也用过
假如进程是5101

jstack 5101 | grep 13ee -A60 #打印出前60行

找出 公司的名字，如：atguigu.JavaDemo02.main(JavaDemo02.java:10)
第10行代码造成的
类似这儿样的
 at Demo2.main(Demo2.java:8)

javap.exe
jconsole.exe
jinfo.exe jinfo(Java配置信息工具)
jmap.exe jmap(内存映像工具)
- 映射堆快照 jmap -heap 进程ID
- 抓取堆内存
  - 生成hprof文件并下载到本地
  - +MAT分析插件工具
jps.exe
jstack.exe
jstat.exe jstat(统计信息监视工具)
- 垃圾回收统计

github

in

in关键词限制搜索范围

seckill
英
/ˈsekɪl/
v.
秒杀

公式
xxx关键词 in:name 或 description 或 readme

XXx in:name项目名包含xxx的
xxx in:description项目描述包含xxx的

xxx in:readme项目的readme文件中包含xxx的

组合使用

搜索项目名或者readme中包含秒杀的项目

seckill in:name #名称里面要有的
seckill in:name,readme,description

stars forks

star
n.
星，恒星；演艺界明星，体坛名将；（电影、戏剧中的）主角，主演；重要人物，
v.
主演，使主演；给……加上星号；表现杰出；用星形物装饰（或覆盖）
adj.
最好的，最出色的

fork
n.
餐叉，叉子；耙，叉；岔路，支流；叉状部件，叉状物；（棋）一捉两，一捉多
v.
（道路、河流等）分岔，岔开；（用餐叉）叉起；耙地，叉掘；

xxx关键词stars通配符

:> 或者 :>=

区间范围数字

数字1…数字2

查找stars数大于等于5o0o的springboot项目

springboot stars:>=5000

查找forks数大于500的springcloud项目

springcloud forks:>=500

组合使用

查找fork在100到200之间并且stars数在80到1oo之间的springboot项目

springboot forks:100..200 stars:80..100
springboot forks:2000..4000 stars:6000..8000

stars或fork数量关键词去查找

awesome

awesome加强搜索

awesome系列
一般是用来收集学习、工具、
书籍类相关的项目

awesome
英
/ˈɔːsəm/
adj.
让人惊叹的，令人敬畏的；非常棒的，极佳的

搜索优秀的redis相关的项目，
包括框架、教程等

awesome redis

#出现
Awesome Lists
很棒的列表是由社区策划的很棒的东西的列表。从CLI 应用程序到奇幻书籍，都有很棒的列表。主存储库用作精选列表。

高亮显示#L

1行
地址后面紧跟#L数字

多行
地址后面紧跟#L数字-L数字2

高亮显示某一行代码

第13行就会高亮

地址#L13

13行 到 120行 高亮
地址#L13-L120


https://github.com/527515025/springBoot/blob/master/springboot-Cache/src/main/java/com/us/example/Application.java