关于服务端的监控分析，
对于不同技术栈，比如操作系统、数据库；了解基本原理其实就可以
一、linux组件
①cpu
cpu可以理解为干活的工人。就是负责计算机的逻辑处理、计算、调度。
cpu的性能主要其实体现在运行程序的速度上，linux是一个多任务的操作系统。将每个cpu的时间划分为很短的时间片。再通过调度器轮流分配给各个任务使用，这样就造成了多任务同时运行的错觉。
cpu使用率反映的是当前cpu的繁忙程度，
②内存
给cpu提供数据，数据是从磁盘进行读取过后在内存中临时存储。因为数据都是保存在磁盘，说到内存想到虚拟内存，虚拟内存很少用，现在内存比较大，虚拟内存比较慢，所以一般不使用虚拟内存，一般服务器都会进行关闭。
③磁盘
磁盘用来存储数据，永久存储
④网络
网卡是发送接收数据包设备，重点关注网卡。
关于这几个性能瓶颈场景可以先介绍一下。
cpu出现性能瓶颈可能是cpu密集型，可能你的cpu会出现瓶颈。
内存如果是内存型应用，内存可能会出现瓶颈，redis是内存型应用，jav\a应用说的是jvm内存，此处说的内存型应用说的是整个物理内存。
磁盘：频繁读写项目磁盘可能出现瓶颈。
网络性能瓶颈是平凡大文件上传下载之类的，网卡是接收和发送的基本数据，如果是单队列网卡，收发压力比较大，会出现瓶颈。
如果要提高性能，可以从这几个组件进行考虑，假设是内网环境，影响性能排序是cpu>内存>磁盘,比如可以增加cpu的核数（即就是增加功能）、也可以提高cpu的工作频率（即就是cpu的切片速度）
关于内存可以进行增加内存，内存不够可能会用到虚拟内存，内存足够大就不需要用虚拟内存，这样可以减少与磁盘的交互频率。
磁盘提升磁盘的读写速度（最好是固态）
实际压测上，服务器配置也不会是无限高，也会是在一定的情况下，这里提高性能只是单纯去考虑服务器性能，可以cpu，内存、磁盘进行提高。
在服务器配置一定情况下，压测提升服务器性能，是去调服务器的配置参数、调应用的配置参数、调代码逻辑。
相互影响：cpu。内存、磁盘是互相影响，比如，cpu使用高，就会有cpu的队列，会导致大量进程等待cpu资源，进程增加会导致内存增加，创建进程是需要内存。内存耗尽又可能会造成虚拟内存的使用，虚拟内存的使用，又会造成磁盘io增加，而申请磁盘io又需要cpu（内核态的cpu），只有内核态可以访问物理内存，所以最终又增加了cpu开销
看一下分别从哪几个维度监控？
1.linux操作系统内核简介:
1）关于内核
与计算机硬件进行交互，实现对硬件部件的编程控制和接口操作，调度对硬件资源的访问。
为计算机上的用户程序提供一个高级的执行环境和对硬件的虚拟接口。
查看内核版:uname -r
uname -r
Linux内核版本由3个数字组成:r.x.yr:目前发布的Kernel主版本x:偶数是稳定版本,奇数是开发中的版本 y:错误修补次数 4.18.0
2）操作系统内核体系结构图
进程有用户态、内核态，用户态调用系统接口，陷入内核态.
proc 是 Processes(进程) 的缩写，/proc 实际上是 Linux 的一个虚拟文件系统，用于内核空间与用户空间之间的通信
cat /proc/cpuinfo
查看一个物理cpu核数: cat /proc/cpuinfo |grep “physical id”
查看多个物理cpu核数:cat /proc/cpuinfo |grep “physical id” |sort |uniq |wc -l
查看逻辑cpu核数: cat /proc/cpuinfo |grep “processor” |wc -l
3）内核功能：按功能模块分为
操作系统功能调用的统一入口:创建进程\读取文件
查看系统调用:strace
如查看whoami的系统调用,用strace whoami
进程管理:对运行中的程序进行生命周期管理
内存管理:对运行中的程序使用的内存进行管理,内存管理只有内核才可以直接访问物理内存
文件管理:对运行中的程序使用的文件进行管理,Linux 里一切皆文件
设备管理:对输入输出设备进行管理,字符设备比如：鼠标块设备比如：硬盘
网络通信（网络接口）:
网络协议模型、业界标准的 TCP/IP 模型：四层模型。
应用层:常见协议：http
传输层:常见协议：tcp
网络层:常见协议：ip
网络接口层:负责网络包在物理网络中的传输
客户端软件想要基于网络发送一条消息给服务端软件
2.系统内核中较重要
1）中断：interrupt
中断发生在内核态.,上下文也是发生在内核态上.
中断是系统用来响应硬件设备请求的一种机制
分类:硬件中断、软中断
硬件中断：硬件产生的,用来快速处理硬件请求（会打断 CPU 正在执行的任务），网卡,数据来了发出中断请求,内核响应,优先级高,cpu优先处理请求,特点是快速执行
软中断：是由软件产生,如网络收发,由内核触发，比如用来异步处理硬件中断未完成的工作，各种类型软中断在不同 CPU 上的累积运行次数。
cat /proc/softirqs
net_tx接收
net_rx发送
rcu锁,Linux常见的锁
timer定时
SCHED 内核调度
压测过程中重点关注net_tx接收\net_rx发送
软中断高,看net_tx接收\net_rx变化数值是否变化大
有的收发能力很差,数值在某一个cpu上,收发的网卡是单队列网卡,压力比较大,一般单队列网卡要调成多队列1网卡.,需要看一下每个cpu都有数据,数量都是一个数量级,这些数据都是累计值,不是当前值.
需要看变化值. watch -d cat /proc/softirqs
常见中断:
有优先级高的进程要执行,就会触发软件中断,正在被执行的进程就会被暂停.,暂停时就会保存各进程的上下文.
对cpu而言,是划分了很多cpu时间片,属于分时服务.
常见性能问题：压测产生大量网络数据、接收数据导致hi高
原因：接收数据能力弱
2）上下文切换：context switch
上下文
cpu上下文：是CPU在运行任务前必须的依赖环境
CPU寄存器：是CPU内置的容量小、但速度极快的内存，储存运算器里的临时数据和指令
程序计数器：程序计数器，存储 CPU 正在执行的指令位置、或者即将执行的下一条指令位置
切换：先把前一个任务的 CPU 上下文保存起来，然后加载新任务的上下文到这些寄存器和程序计数器，最后再跳转到程序计数器所指的新位置，运行新任务
上下文保存在内核里,任务重新调度时重新加进来.
Linux多任务操作系统,可以运行的任务远大于cpu数量.
常见cs： 中断上下文切换
进程上下文切换
线程上下文切换, 比进程间切换消耗资源少
上下文切换过多重点关注:应用配置相关，线程池设置过大,线程频繁切换,导致cs高.
3.linux监控关注的指标
1）cpu：车间工人，干活的，负责计算机的逻辑处理。
所以，一般都先top看监控。cpu使用率反映的是当前cpu的繁忙程度,影响cpu性能的速度逻辑结构\工作频率.
cpu分时服务,切换成很多时间片.,切片次数很多,cpuhz越高.
cpu使用率反应的是繁忙程度.
2）内存：给cpu提供数据，从磁盘读取数据，临时存在内存.
现在内存都很大(几百个g)，所以很少用虚拟内存了，虚拟内存慢。
影响内存的性能因素:内存容量\主频.,
3）磁盘：永久存储数据.
影响他的因素磁盘容量、读写速度。
性能问题出现在频繁读写的项目中，频繁读写需关注磁盘io
4）网络：网卡是发送和接收网络包的，压测中产生大量数据，把数据存到从网卡,产生硬中断(比较快),存到内存里,随后通过软中断把数据传到协议栈中tcp一层一层往上传,传到目标服务端,频繁的上传下载会影响带宽.可以关注网络带宽软中断.
四个相互影响,影响排序是cpu\内存\磁盘
二、监控划分
1.命令监控
常用的是两个命令top和vmstat
A.cpu：影响cpu，逻辑结构，工作频率。cpu切片高，hz高。
(cpu\mem\磁盘\system\swap\io)
cpu主要关注的是cpu的逻辑核数\us\sy\id\wa\si
us用户态进程消耗的cpu
sy内核消耗的cpu百分比,正常情况下：sy越小越好，us越大越好
并不是us高,就需要去优化.
有的时候就是消耗cpu,cpu密集型,cpu高正常,不达标,用户线程在做什么,jstack看栈信息,看执行的任务,在做什么,看逻辑是否合理.,逻辑能优化就优化,不能优化就加资源…
id空闲 cpu没干活,看还剩多少,如果剩的还少的话,看哪个指标占用得cpu最多.
wacpu在读写时产生io的等待,占的cpu
磁盘性能差反应到wa上.
wa会与vmstat中的bo有关系,wa高vmstat中的bo一般也高，与磁盘队列也会有相关
si软中断消耗的cpu百分比,软中断的查看cat /proc/softirqs
软中断重点关注net_tx接收,net_rx发送,其他出现问题的概率比较低,值都是累计值.
需要关注他的变化值:watch -d cat /proc/softirqs,白底很宽,中断很高,累加很多,增量很多,着重关注.要看每个cpu是否都有数据.理想情况,每个cpu均有数据,中断需均衡,若只是一个cpu上有数据,可能就是单队列网卡,压力大.
看是不是多队列网卡,就看每个cpu是否都有中断,看数据是否差不多.
以上这几个都是top重点关注.
cpu高其实还要再具体根据分析,看具体是哪个指标高(us\sy等)
cpu使用率反映的是繁忙程度。
①top:
top可以看到cpu、内存、swap（虚拟内存）、负载
按c可以知道详细执行的命令
②vmstat:
此处也可以看到内存、swap、io（磁盘）、cpu
sysytem对应的是in（中断）和cs（上下文切换）
vmstat中的b可看出等待io的进程数
vmstat 可看cpu\mem\io\system\磁盘\队列
2、监控的目标
2.1、cpu
说服务器几C是说的逻辑cpu个数
2.1.1、查看cpu信息
① 查看CPU信息
cat /proc/cpuinfo
② 查看物理cpu个数
cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l
③查看每个物理cpu的核数
cat /proc/cpuinfo| grep "cpu cores"| uniq
④逻辑cpu个数
cat /proc/cpuinfo| grep "processor"| wc -l
lscpu
2.1.2、top
① us
用户态进程消耗的cpu百分百
如果us高，可能是合理的，也有可能会有性能问题。
cpu范围定在多少范围以内达到压测目标？可能cpu会超过定的目标，cpu是干活的，想要处理更多的请求，就需要一直进行干活，us高是合理的。如果不达标，看一下us是在做什么，需要看线程栈或者看一下oom之类的
后面讲计数器分析思路做总结
通过man可以看到具体信息
②sy
内核消耗的cpu百分百
③ id
空闲的cpu百分百
④wa
IO-wait : time waiting for I/O completion
io等待占cpu的百分比，和磁盘相关
⑥si
软中断消耗的CPU百分比
关于中断：interrupt。中断是系统用来响应硬件设备请求的一种机制
中断比其他进程优先级更高，会打断其他进程的执行。会调用内核里的中断程序，响应设备的请求。打断其他程序，就需要将当前被打断的进程状态保存起来，在中断结束后这个进程就会从原来的状态继续执行。
vmsatat看到的in是包括硬中断和软中断
中断是系统用来响应硬件设备请求的一种机制
分类硬件中断（硬件通过中断控制器进行触发、是用来快速处理硬件请求，特点：速度很快）、软中断（处理硬中断还未完成的工作，cat /proc/softirqs、watch -d cat /proc/softirqs）
重点关注：软中断
可以通过命令关注软中断类型、不同类型中断在不同cpu上积累的运行次数
cat /proc/softirqs这个命令将常见中断罗列出来
比如网络相关的
net-tx网络发送中断
rx网络接收中断
timer：定时
sched：内核调度
中断也是保证linux正常工作的核心功能
一般情况不需要关注，如果中断过多，会将cpu的时间都消耗在处理中断请求上。而用户请求就没有被处理，减少了程序运行的时间。导致性能下降
中断后续要关注的就是这个网络相关的
2.1.3、vmstat、
第一行数据忽略
看中间数据
重点关注r、b、in
r就绪队列的长度（正在运行和等待cpu的进程数，有些进程是没有获取到cpu的运行权限，只要cpu分配给她，就可以执行）
b处于不可中断睡眠状态的进程数（如正在等待io，这种就是不可中断的进程）
in包含：hi和si
2.2、内存
free命令
total总共的
free空闲的
used已使用的，他的计算是total - free - buffers - cache
剩余可用的内存，不仅仅是free，还包括buffer、cacahe：total - used = free + buffers + cache
buffer缓冲，cache缓存
available可用内存，大致就是free + buffers + cache，因为linux通常会把可用内存给cache，不一定会用，看起来free越来越少，而available计算了buffers + cache不用的内存。所以也可以看avaliable，只要它多就表示够用。
进程级别内存
可以通过top进行查看
此时说的内存是物理内存
看res这一列，可以看出哪一个进程占用的物理内存大
针对于java应用，重点是关注jvm内存，如果物理内存不够用了，操作系统就会把消耗多的进程进行kill掉
将这个java进程kill掉了，即就是在物理内存不够了，就会调用oom的kill将消耗资源多的进程kill掉了，这种情况下需要看这个应用为啥会消耗那么多的内存。
2.3、swap
在磁盘上划分的一块空间，映射到物理内存，当物理内存不够用时，就会把物理内存的数据保存到磁盘。
物理内存很少用，会比较慢，一般会关闭，后续一般会进行关闭。
关闭命令swapoff -a
vmstat
2.4、磁盘
磁盘容量 df -h
tmpfs临时文件系统，size都是一样的
看磁盘时，需要将tmpfs过滤掉,命令df -h |grep -v tmpfs
tmpfs用的是内存空间，挂载到内存中的。
iostat
磁盘io相关的
iostat -x -d 1
重点是这个aqu-sz磁盘队列，如果这个比较高的话，会反映到cpu的iowait上，iowait也会高，即wa
iotop -P 是看io高的进程
如果这里执行这个命令，显示无法找到，就需要进行先安装yum -y install iotop
此处就可以看到是哪个进程读写比较高，可以进一步看栈信息
2.5、sysytem
可以通过vmstat看到cs、in
cs关于上下文切换：context switch
上下文，其实就是cpu上下文，即就是cpu的寄存器和程序计数器，因为cpu执行任务，任务是从哪里加载，从哪里运行
切换就是把前一个任务的cpu上下文保存起来，去加载新任务的上下文，到程序寄存器最后跳转到程序计数器的新位置进行运行新任务。保存下来的上下文会存储在系统内核中，下次调度又可以被重新加载进来，继续执行。
关于上下文切换，主要可以分为中断上下文切换、进程上下文切换、线程上下文切换
刚才也讲过，产生中断，把正在执行的程序暂停，需要将上下文保存。
中断会产生cs
线程上下文切换，同一个进程内的线程切换，这个线程上下文切换是要比进程上下文切换资源消耗少。
这也就是多线程的优势。
关于上下文切换，一般是不需要特别关注。
上下文切换也是linux工作的核心功能。
如果上下文切换过多，会把cpu时间消耗在保存数据和恢复数据上，这样也是减少了用户程序时间，也会导致性能下降。
上下文切换最常见的场景是：在压测过程中，应用的线程池如果设置的较大，就会导致大量的上下文切换。
关于上下文切换，也只是一种表象。
此处的cs还可以做进一步分类
cs细分自愿、非自愿
通过命令pidstat -wt看到这两列
第一列自愿，第二列非自愿
自愿是指进程没法获取资源从而导致的上下文切换（比如io、mem不足，就会发生自愿上下文切换，如果是io不足吗，就去排查io，如果是内存不足，就去排查内存）
非自愿上下文切换可能就是时间片到了，就会被系统强制进行调度，这时就会发生上下文切换
in中断
中断肯定会有cs
看top中和sysytem相关的
平均负载
load average: 0.00, 0.00 0.00，表示的是1，5，15分钟时间（可运行状态和不可中断状态的平均进程数和vmstat的前两列有关系，负载的趋势和vmstatb/r 对应
load average和vmstat中的b\r对应的,load average高，b+r也会很大,cpu负载.
即就是load averag=b+r
负载也可以通过uptime进行查看
cpu和负载的关系？负载高，cpu一定高？
cpu和负载没有关系
cpu密集型（计算操作中），负载高、cpu使用率低
io密集型，负载高，cpu使用率低
2.6、网络
网卡
ethtool 网卡名
这里的速度是unkonw，因为这里是云服务器就是不会展示
可以看一下虚拟机
网卡命是ens33
此处就展示了网卡速度。1000/8=125MB/s
如果是内网，就看一下网络传输的数据是否达到了网卡的速度
如果是外网，就看一下供应商提供的速度是多少，看是否达到带宽，
看网络速度是sar -n DEV 1
重点：rx每秒接收多少kb、tx每秒发送多少kb
可以看到每个网卡
如果是内网，可以和网卡进行比较
内网的带宽瓶颈就是频繁上传
说了命令监控，看一下可视化监控
重点关注到:
r是就绪队列长度,包含运行+等待cpu的进程数
b是bork表示进程在等待io,处于不可中断状态的进程
而in这个表示中断,中断表示总,看数值
而在top中,是看到中断占用的cpu,若占用的cpu高si,相对应的vmstat中的in中断的值也比较大.
in的值多大算合理,没有准确说法,in哪怕比较大,tps还是比较高,可以先不管.调优是永无止境,先达到目标,尽可能再去测最大值,目标达不到,肯定需要关注消耗多的指标.,.有的in上万,tps也高.
wa
和top中的wa是一样的
mpstat不存在需安装
mpstat -P ALL 3 ：每隔3秒打印一次，可以更细的看到每个逻辑cpu的消耗
比较关注的指标:
idle
soft 就是top中的si,软中断
iowait就是top中的wa
问题:资源消耗都在一个cpu上,因为没有配线程池,就就只有一个线程池跑,表象就落到一个cpu上.
除了看不同的cpu占用,
pidstat -u -p ALL 3是看不同进程的cpu(us/sy/%wait)
重点注意:
pidstat中的%wait是表示进程等待cpu的时间百分比，表现在就绪队列中.说明在r中
top中的wa、vmstat的wa：表示io等待
若想关注java进程的cpu的(us/sy/%wait))就用:pidstat -u -p ALL |grep java
vmstat 1：一直输出
vmstat 1 3：1表示频率，3表示次数
注意::尽量不要看第一行数据，看中间行的数据
vmstat中的in表示的是hi、si的数量总和
top中的wa、vmstat的wa、pidstat中的%wait区别：
pidstat中的%wait是表示进程等待cpu的时间百分比，表现在r就绪队列中.
top中的wa、vmstat的wa：表示io等待
其他命令：
mpstat、pidstat
mpstat -P ALL 3 ：每隔3秒打印一次，可以看到每个逻辑cpu的消耗
为什么资源只在一个cpu上消耗，其他cpu没有消耗，没有配线程池。
产生中断会有cs，cpu时间片到了也会产生上下文切换。
pidstat -w对上下文切换更详细的说明。
cswch/s ：自愿上下文切换
nvcswch/s ：非自愿上下文切换
pidstat:显示的是每一个进程的sy、cpu各种
pidstat -u -p ALL 3
pidstat -u -p ALL 3|head -10
查看Java进程显示的sy、cpu等：pidstat -u -p ALL 3|grep java
命令综合起来一起用，分析问题更加准确。
B.system
vmstat的system
有in中断就会有cs,保存上下文.,除了中断也会产生cs,时间片到了也会产生cs
在vmstat中看到的cs也是汇总的cs
也可以看进程级别的
pidstat -w对cs做进一步的划分, cswch/s 自愿上下文切换 (进程无法获得资源,数据io等待,就要做上下文切换)
nvcswch/s 非自愿上下文切换,时间片到了,被动放弃cpu,
通过这两,可以大概看到具体是什么原因,具体是什么原因,还需要具体分析判断(到底是等待资源,还是资源不足)
一般进程多时,可以看到具体是哪个线程在做切换.,看的粒度更细.,更有针对性的关注可变的进程.
top中的负载
load average: 0.29, 0.30, 0.31，表示的是1，5，15分钟时间（可运行状态和不可中断状态的平均进程数）
load average和vmstat中的b\r对应的,load average高，b+r也会很大,cpu负载.
即就是load averag=b+r
面试问题:
cpu和负载的关系
cpu和负载没有关系,从两个类型的应用考虑:
虽然两种负载高,但是cpu的使用率是不一样的.
1)cpu密集型,若做复杂的逻辑运算,本身就是消耗cpu,发压时,线程多,负载也高.(因为本身消耗cpu,先去的就先执行,后去的就先等待,正在运行和等待运行就是vmstat中的b/r,刚说到load average=b+r,若是cpu密集型,基本上就是cpu高,负载也会高.
2)对于io密集型,等待io上去,就需要等待,若很多进程都在等待io,等待io多,队列比较大,等待磁盘io是不会去消耗cpu,没有其他进程占用cpu,cpu运行使用低,负载高(有很多等待io的进程)
C.内存：影响内存因素，内存容量、内存主频。
主要是通过free看,但是也可以通过top查看
关注
真正看的是这个avail Mem (可用的)
物理内存都比较大,除了内存型应用比较在意这个,Java应用一般不会关注这个,是关注jvm
若要去关注内存看avail Mem就可
avail Mem (可用的)= free空闲的+buff/cache缓冲缓存
top
倒数第二行
KiB Mem : 1881832 total, 98684 free, 810180 used, 972968 buff/cache
total总的
free空闲的
use使用的
buff/cache缓冲缓存
total总的= free空闲的+ use使用的+buff/cache缓冲缓存
vmstat 中的si全称是 swap in 从物理内存到swap
so 全称是 swap out 从swap到物理内存
一般也不会用这个swap,用这个性能会降低.,物理内存不管用时才用,
关闭:swapoff -a
D.swap
E.磁盘:对磁盘读写比较高的，都是固态磁盘，机械磁盘就很小，对读写要求不严。
磁盘主要关注的是磁盘容量,磁盘读写速度.
磁盘容量:df -h
可能会遇到的问题,压测过程中日志直接写在日志文件里,会占用磁盘…
io
iostat -x -k 1：每一秒输出一次或者iostat -xk 1
若磁盘内存有问题，iowait就高
若磁盘有问题i,用iostat -x这个命令i下的iowait就会高,这里的iowait就是top中的wa以及vmstat的wa
还关注r/s,w/s每秒：每秒读写的次数
r/s+w/s每秒钟io次数
rkB/s+wkB/s每秒钟的读写,若实时写磁盘,一定要先了解磁盘性能情况,每秒支持多少的读写.
还关注r-wait\w-wait读写的wait,其实就是读取平均响应时间,这个值如果大的话,要去考虑%iowait\磁盘队列aqu-s/avgqu-sz(老的版本),磁盘队列会反应到iowait上,iowait上升.
磁盘着重关注r/s,w/s每秒读写的次数、iowait、磁盘队列。
r-wait : time waiting for I/O completionwait高，aqu-sz或者avgqu-sz，磁盘队列反应到cpu的iowait上。
也可通过进程看磁盘：
iotop 这个是看哪一个进程io是最高的
注意第一列:
是tid,这个是线程
进程一般是pid
要想看pid进程,加一个参数iotop -P
iotop -P 这个是看哪一个进程io是最高的
按方向键可以看各列排序,默认就行
若遇到io百分比比较多，可以去看进程在做什么，打栈，jstak，去看栈信息，进一步去分析。
可能遇到的问题：实时写数据，对磁盘性能要求高。
写日志要先确认日志的级别，不要用debug模式，不然会产生大量的磁盘io,一般都是异步模式.
F.网络
关注网卡\发送接收的流量
压测一般都是在内网压测.排除带宽影响，主要考虑网卡（网卡带宽一般现在是万兆网卡，不是供应商提供的带宽）
内网：通过ifconfig先看有什么网卡、看网卡什么级别（ethtool 网卡名）
注意单位是Mb，要除以8换算为MB
千兆网卡实际1000/8=125MB/s，万兆网卡实际是10000/8=125MB/s
外网:
关注供应商提供的网络带宽大小,频繁上传下载需要关注网络带宽。外网带宽占满从前端（图片未压缩、从静态资源以及前端资源部署方式下手）
sar -n DEV 1：可以看到每个网卡发送接收的数据
接收数据：rxkB/s 发送数据 ：txkB/s （内网可以用这两与网卡作比较）
发送接收的流量iftop
iftop也可按进程查看，htop（是增强版）
所有的应用部署到一台服务器上，这些命令皆可使用。
rx接收流量
tx发送流量
total总的
cum是累积，peak是峰值
按p可看到哪个端口数据传输量比较大
看当前的带宽使用情况
sar -n DEV 1
可以看到每一个网卡
重点rxKB/S txKB/S
内网rxKB/S txKB/S各自数据和网卡带宽作比较,如果是外网就和供应商作比较.
以上的命令仅限于linux
其他:
dstat
其它命令dstat、nmon
若没有需安装yum install -y dstat
dstat
dstat c
c指cpu
dstat -cmdrnylst
m指内存
d指磁盘
r指接收
n指网络
y指系统
l指负载
s指swap
t指时间
nmon也可以监控cpu\内存网络
没有就需要安装yum install nmon
按c显示cpu
按m显示内存
按d显示磁盘
按k显示内核
Forks 是进程， ContextSwitch 上下文切换，Interrupts中断
思路
没有特别说明一般是java项目
如果通过时间拆分应用服务器消耗耗时多,下一步就是就是可视化监控方式命令监控方式看服务器的资源情况,一般是先
执行top,一般采取时间拆分肯定是有性能瓶颈,没有达到性能目标,若us高，打栈，看栈信息（具体是什么逻辑）若是cpu
密集型，有压力，cpu高其实是正常,复杂业务逻辑是否合理，若无法优化，只能增加cpu资源。
仅限于java项目
打栈方式
1）打栈：top,按c可看到使用高的用户进程。获取进程id
2）看具体线程id消耗的cpu，top -Hp pid 获取线程id
3）获取16进制:printf “%x\n” 31456
4)jstack 31441 |grep 7ae0 -A 30
其他方式：arthas(方法耗时跟踪比较方便）,strace
对网络进行补充：
协议栈是在内核完成的,涉及到协议栈内容,就涉及到内核参数配置.
建立连接tcp的三次握手,建立三次握手时.内核会维护两个队列(一个是SYN_RCYD半连接队列,一个是ESTABLISHED全连接队列(连接建立成功)
tcp三次握手的过程,:客户端首先发syn,服务端收到客户端syn请求,内核会把连接存储到半连接队列,存后向客户端发送syn\ack,客户端返回ack,服务端会收到第三次握手的ack,内核就会从半连接队列移除,会创建全连接队列…
全连接队列中连接会等待进程,调用accept函数,将连接取出来,开始通信,进行数据传输.
半连接,长连接的长度都是有限制,超过连接的长度限制,内核会将连接丢弃.
压测时线程数设置设置大时,会报连接相关错误.如connection receive,报这种连接错误,就要去看连接队列,连接队列溢出,内核把连接丢弃,返回RAST包,客户端与服务端连接都还没建立,服务端的日志是没有的,请求还没发送到服务端.
全连接队列也叫accept队列,查看方式是要看是listen状态,
连接主要关注两个状态:listen状态.\ESTABLISH状态
全连接看的是listen状态
Recv-q
Send-q
查看全连接队列的大小ss -ltnp
l是listen
t是tcp
n是不解析服务名
p是porcess,可以看到哪个用户进程以及进程号都可以看到
第一列就是状态
全连接队列大小
Recv-Q这个就是完成三次握手,等待服务端调用accpept的连接数.,全连接里没有在等待服务器调用accpet的连接数.
Send-Q 当前全连接的最大长度 ， 配置值，若是129,最大全连接需要调整，后面的请求过慢，连接创建不了，会被内核丢掉。
取决于两个参数：somaxcom,backlog
可以通过这个查看cat /proc/sys/net/core/somaxconn， 每一个端口最大的监听队列的长度
应用最大排队的连接数min(somaxconn,backlog) listen的backlog
修改backlog需要看是什么服务，如nginx是需要修改配置文件nginx.conf
nginx要改backlog的话，在server listen处加default backlog=16384
如：
server{
listen 80 default backlog=16384;
server_name localhost;
}
如果是tomcat的话，spring boot 里加就是加上
accept-count:1000 允许最大的连接数，一般会写配置文件
Send-Q最大排列连接数，显示somaxcom,backlog这两参数的最小一个，而somaxconn内核参数（每一个端口最大的监听队列的长度）、backlog是实际应用到的（nginx、tomcat）
验证 Send-Q显示somaxcom,backlog这两参数的最小一个
ss -ltnp
例如nginx
ss -ltnp |grep nginx send-Q128,nginx默认是511,为啥nginx看到的 send-Q是128，因为看到的somaxcom内核参数是128
这个send --Q可以改，即就是改somaxcom，可以通过配置文件，也可以通过
echo xxx > /proc/sys/net/core/somaxconn
cat /proc/sys/net/core/somaxconn
改完需要重启对应服务
杀进程ps -ef |grep -v grep |grep nginx |awk ‘{print $2}’ |xargs kill -9
重启后需要查看端口是否在 netstat -lntp |grep 80
当前全队列比这个内核的的全连接最大长度要大，中途发请求，连接是建立不了，会被内核丢掉，就要调。
多次监控，Recv-Q比send -Q大，证明全连接满，请求进来，需要将send-Q调大。
调send–Q两种方式：ss -ltnp，nectstat -s
netstat -s |grep overflow
the listen queue of a socket overflowed 监听队列溢出，内核把连接丢弃的次数，这个命令需要执行多次，需要看增量，还可以加时间
date;netstat -s |grep overflow
每隔2s执行：
while true ;do date;netstat -s |grep overflow; sleep 2;done
这个值增加，说明全连接队列满。
全连接队列满，需要改somaxcom，backlog，两个是调一样调到更大
半连接队列服务端处于SYN_RCYD这种状态连接tcp连接数
统计当前nginx进程的半连接队列的长度netstat -antp |grep nginx| grep SYN_RECV |wc -l
cat /proc/sys/net/ipv4//tcp_max_syn_backlog
linux下的/proc/sys/net/ipv4/
https://blog.csdn.net/weixin_43833642/article/details/105206030
https://juejin.cn/post/6993124663878484005
while true ;do date;netstat -s |grep -i “SYN to LISTEN sockets dropped”;sleep 2;done
值不断增加说明，半连接满了，syn包被丢掉，半连接都被丢掉，就走不到全连接
如有半连接丢弃：就需增大半连接队列:
1)增大tcp_max_syn_backlog
2）增大somaxcom
3）backlog
在半连接中将这三个值设置成一样的，调大。
调的方式echo xxx > /proc/sys/net/core/somaxconn或者直接更改配置文件vim /etc/sysctl.conf,改相关参数,改完后执行sysctl -p使其配置文件生效，改完后所对应的backlog服务需重启
连接队列出现的场景就是大并发，压测过程中报的是连接相关问题，看连接队列情况。
网络队列：网络的发送与接收，有多少数据在排队。
分为发送队列与接收队列。
持续有值就存在网络队列。
网络队列看ESTABLISHED 状态，客户端与服务端已经在进行通信，数据传输。
查看网络队列：netstat -antp |grep ESTABLISHED
send-Q/recv-Q 单位都是字节
send-Q/recv-Q瓶颈判断：
发送，接收队列可以判断是那一侧有问题
思路:
看网卡配置ifconfig, mtu 1500,最大的传输单元(包的大小),1500协议栈的头-(tcp+ip的头)=1460以太网传输的真实字节.这个值一般不小于1500,如果看到服务器这个值比较小,并且有点小,需要看这个值mtu 具体是多少.
一般
内网压测,看网卡具体支持多少,ethool 网卡名 单位是Mb/8
外网:看网卡是多少,还需要知道供应商提供的网络带宽是多少.
压测过程中,可能是网络相关问题,可以结合(iftop\可以看到当前的流量和峰值,还可以看对应的端口传输多大,按p,网络带宽也可以通过sar -n DEV 1可看到每秒接收发送多少,还可以看网络是否有异常(套接字丢包)
通过netstat -i,关注到 RX-DRP接收丢包,如果有持续增量就代表有丢包和这个mtu有关.,若mtu比较小就会有持续丢包的情况.
若软中断高,就需要看中断的类型,中断的类型若是网络相关的,那么可能就是网卡问题(中断都集中在一个
cpu上,考虑是不是一个网卡在响应中断请求,单网卡,这种问题,要么是减少数据传输量(不影响业务),不能减
少数据传输量,一般就是多加几个节点或换服务器,处理这种需要多网卡队列.
重点:网络中断\连接\网络队列,缩小排查范围.
linux调优主要就是内核参数\Linux句柄调整
内核参数调整:全连接里有somaxcom,半连接tcp_max_syn_backlog,一般是这两个会影响性能,连接队列溢出,连接丢弃.
文件句柄数:linux下一切且文件,每个文件都有文件描述符.
文件句柄大小可以从三方面调整:
操作系统\用户\进程
查看当前系统支持的tcp连接数: ulimit -n,默认是65535
常见的错误:如连接过多,会报too many open files
更改:ulimit -n2
集群一般是先监控可视化监控看主要指标
cpu一般是sy/us等,系统看负载
2.可视化监控
2.1、看一下可视化监控的计数器
根据思维导图搭建后，效果图
①可以看到cpu使用率
包含内核态、用户态、空闲、iowait，此处没有包含si，可以通过命令方式进行查看
②看一下内存
内存总容量
内存使用率
这里表示物理内存的一个情况
关于内存要看他的内存类型，如果是内存应用型，就会去关注物理内存，如果是非内存型应用，物理内存基本不会成瓶颈，如java应用关注的是jvm内存。
③磁盘
包含磁盘读写速率，磁盘读写容量大小、磁盘io读写时间。和iostat看到是类似的，如果磁盘有瓶颈，还是会表现在磁盘队列上。
重点还是关注是否有磁盘队列
④网络
如果监控数据后此处没有数据，将此处改成对应的网卡名称就行，如此处的网卡名称是ens33
⑤system
sysytem包括负载
三、计数器值分析思路
看到这些计数器有异常，该怎么去分析？
假设我们已经通过时间拆解，定位到应用服务器耗时，并且是java应用
首先看cpu
1.cpu
①us高
1)前提是应用服务器耗时，java项目
如果us高，表示用户进程一直在占用cpu，此处说明，us高不一定有问题。
第一种：cpu密集型
压测过程中us高是正常的，如果公司有图像识别的接口会比较高。如果是
第二种：非cpu密集型应用
排查用户进程的问题
第一步
方式1：
首先看gc的状态，看是否频繁fgc，如果频繁fgc，us高
方式2
进行打栈，看线程栈信息此处涉及到jvm的栈的信息
此处看gc涉及到jvm的堆，看线程栈涉及到jvm栈
②sy高
其实内核进程有性能问题概率较低，大部分是配置问题
比如频繁的上下文切换cs、中断，都会频繁的占用内核态的cpu，所以sy也会高。
vmstat里面cs高，pidstat -wt，可以看到cs更细的视角（自愿上下文切换、非自愿上下文切换）
如果资源不满足，会发生资源上下文切换，有的时候资源充足也会发生资源上下文切换。这个时候就需要看代码的逻辑，这个时候也需要打栈。
cpu时间到了，会发生非自愿上下文切换，如果想让某一个进程一直占用cpu运行的话，可以将进程优先级调大。这也是一种方式。
中断也会导致sy高，可以看中断的类型，还有他的增量，增量很大的需要重点考虑
此命令可以查看常见的软中断watch -d cat /proc/softirqs
**像这种一般重点关注网络相关，一般压测过程中网络传输较大，这个时候会触发软中断，会把操作系统的数据传输到应用，如果看到软中断是不均衡的，可能是集中在某一个cpu上，需要看网络的接收队列。一般像这种集中到一颗cpu上，就是网络队列太少，解决方案就是增加几个队列
top里面si高
看si类型、增量
③wa高
等待完成cpu的时间百分比
这个时候需要找读写多的进程，打栈，看逻辑
④si高
si高会导致sy高，同sy
⑤队列
此处说的队列是指cpu队列
之前讲过cpu队列和负载趋势是一致的
cpu队列长主要是由于资源竞争，比如cpu资源、io资源
此处又可以细分
io密集型
可以通过iostat看是否有磁盘队列
cpu密集型
和以上用户态cpu高类似
如果是cpu密集型，并且逻辑没有可优化空间，消耗cpu是正常的，
如果压测时，线程数比较大就会造成cpu队列
总结：问题来源，配置，代码
以上就是从cpu分析的思路
2.sysytem（内核消耗cpu）
cs（上下文切换）
in（中断）
load average（负载）
cs、in高都会导致sy高，此处和cpu的sy高类似
负载和cpu处的队列类似
system的计数器参考cpu的计数器
1）可能是系统调用：
strace跟踪进程系统调用，strace -p pid，看调用了什么方法，执行了什么,此方法比较复杂,一般不用.
2）一般都是往应用靠：
sy高,vmstat里面cs高(内核在做频繁切换,保存保存,消耗cpu)
常见问题:一般是线程池配置过大,本来只运行100,配置1000,就会存在竞争.
top中里面si软中断高.
常见过程中网络传输大,网卡有数据,触发到硬中断,把数据拷贝到操作系统内存,触发软中断,把内存数据往协议栈发,传到目标服务器,.
传输服务大,可以减少网络传输,对内容进行压缩.
3. 内存
看内存是内存型应用还是非内存型应用
如果是内存型应用需要关注物理内存，物理内存可以看到进程的进程级别的内存占用情况，即就是top的res列，如果是非内存型应用，后续都是java应用，就需要关注jvm内存。非内存型应用物理内存不会成为瓶颈点
①内存型应用
②非内存型应用
等待io完成的使用的百分比.
iotop找到进程，打栈，看逻辑
pidstat -d，看哪个进程每秒读写量大
4.swap
swap一般不会用，会进行关闭
5、磁盘
磁盘第一个关注的是磁盘容量
磁盘容量：df -h
如果有临时文件系统，将其过滤df -h |grep -v tmpfs
磁盘io：磁盘io和cpu的wa对应，参考cpu的wa
6、网络
需要先去看配置
内网ethtool 网卡名，可以看到网卡速度，单位需除8，MB=Mb/8
外网，需去关注供应商提供的网络带宽是多少，如果是外网压测，一定要关注网络带宽情况，频繁上传下载的，就比较消耗带宽
四、linux调优，可能会遇到：
4.1、半连接和全连接的内核参数
4.1.1、现象
压测过程中，请求报错，服务端没有查到日志，报错信息（比如：Connection reset）
遇到这种：就是连接队列的问题
当时是将这个值调大就行
关于连接队列介绍一下
4.1.2、连接队列
连接队列分为半连接、全连接
1）tcp三次握手
tcp三次握手时，内核会维护两个队列（半连接、全连接）
不管是半连接还是全连接，都有最大值，如果超过了最大值就会报错
2）全连接
全连接是在服务端接收到客户端第三次握手发起的ACK请求后，把连接从半连接队列中移除，再进行创建全连接，并且将连接放到全连接中。
全连接需要看listen状态
查看队列大小ss -ltnp
重点关注Recv-Q、Send-Q
Recv-Q当前全连接队列的大小
即就是当前完成三次握手并等待服务端accept的连接个数
Send-Q当前全连接最大队列长度
这个取决于两个参数somaxconn、backlog，它是取这两个参数的最小值,即就是以他们其中一个最小的作为全连接的最大长度
第一个参数somaxconn
linux的内核参数，可以查看一下他的默认值cat /proc/sys/net/core/somaxconn
此处默认值是128（不同服务器的默认值可能不一样）
第二个参数backlog
应用最大排队的连接数，他这个就是listen里的backlog大小
他这个back就是下面sc.listen的值
写socket时
import socket
sc=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
sc.bind('127.0.0.1',8081)
sc.listen(5)
此处可以用nginx演示一下
nginx是有默认的backlog值
先看一下当前nginx服务的全连接队列最大是多少？
先确认nginx是否已经启动，nginx默认端口是80
这个就是nginx进程
此处展示nginx服务的全连接队列最大是128
两个都是128，nginx也是128
表明nginx服务的全连接队列至少是128，因为他是取得是sonmaxcon、backlog其中的最小值，
可以将sonmaxcon值进行改大
直接通过echo将内容重定向到内容中
echo 1024 > /proc/sys/net/core/sonmaxcon
重启nginx服务
先停nginx服务，nginx -s stop
启动nginx
此时nginx的backlock（全连接队列最大）默认是511
因为现在取得是backlog和sonmaxcon的最小值，刚才ngin中的sonmaxcon已经改成1024了,1024和backlog比较小的是511，所以backlog就是511
前提是nginx没有改backlog
这个backlog也可以进行修改，此处需要改ngin的配置文件
如果要进行修改，语法是
listen 80 default backlog=100;
tomcat中也有全连接队列最大
如果是springboot内置的tomcat，需要改springboot配置文件，配置文件需加上accept-count=多少
全连接队列监控
监控：全连接队列溢出
ss -ltnp或者：
ss -lntp | grep port
左边的值比右边值大，超过全连接队列，就会有全连接队列溢出
监控看就是看是否有全连接队列溢出
此处监控并不是说只执行一次这个命令ss -lntp | grep port，而是需要多次执行这个命令，多次执行这个命令发现左边的比右边值大，就说明已经超过全连接队列，如果超过了最大全连接队列，服务器这一侧就会把后进来的全连接队列丢掉，丢掉的这些全连接队列可以通过另一个命令进行查看netstat -s|grep -i overflow
从服务启动到现在全连接被丢掉的次数是7503次，此处需要看他的增量，就不能只看一次，就需要多看几次，就需要多执行几次netstat -s|grep -i overflow`
若这个数字后面一直增大就会有问题，就表示有全连接队列的溢出
此处可以写一个脚本来执行这个命令
每秒执行一次
直接看数字一列就可以
while true;do date;netstat -s|grep -i overflow;sleep 1;done
b90c58c.png)
如果出现了全连接队列溢出，就需要进行调优，调优也是去进行调backlog和sonmaxcon这两个参数，建议就是改成一样大的，当前都是全连接队列最大长度的2-10倍，若当前长度最大是512，改成1024，还是不行，两个就改成2048或者更大，直到不出现全连接队列溢出问题就可
3）半连接
半连接队列就是syn队列
处于 SYN_RECV 状态的 TCP 连接
有半连接溢出看到的半连接才是半连接的最大值
右边是服务端，左侧是客户端
服务端收到客户端第一次握手发起的syn请求后，内核就把这个连接存到半连接中
下一步会向客户端响应syn和ack
查看队列大小
netstat -antp |grep port| grep SYN_RECV |wc -l
监控半连接队列溢出
date的意思是将结果加上时间
也是需要看增量，多次执行此命令，看这个值是否再增加，如果是，就出现了半连接队列溢出
date;netstat -s |grep -i "SYNs to LISTEN sockets dropped"
半连接队列调优涉及到三个参数
调整somaxconn
echo xxx > /proc/sys/net/core/somaxconn
调整backlog
调整tcp_max_syn_backlog
配置文件中vim /etc/sysctl.conf以下这个参数
net.ipv4.tcp_max_syn_backlog
上面3个值，改为一样，大小是半连接最大长度的2-10倍
改完参数后，对应的服务需要进行重启
4.2 、文件句柄大小
因为linux是文件系统，如果出现了**Too many open files**
就说明了出现文件句柄大小，就需要把它进行调大
调大有三个层面
三个层面：操作系统、用户、应用进程
对应的配置文件就是**/etc/security/limits.conf**
5570
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
