1、CPU性能监控

1.2、平均负载基础

平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，它和 CPU 使用率并没有直接关系。平均负载其实就是平均活跃进程数。平均活跃进程数，直观上的理解就是单位时间内的活跃进程数。

查看cpu个数：

grep 'model name' /proc/cpuinfo | wc -l

负载说明（现针对单核情况，不是单核时则乘以核数）

uptime
load<1：没有等待
load==1：系统已无额外的资源跑更多的进程了
load>1：进程都堵着等待资源

不同load值说明的问题　　　　　
　　　　1）1分钟 load >5，5分钟 load ❤️，15分钟 load <1
　　　　　　　短期内繁忙，中长期空闲，初步判断是一个抖动或者是拥塞前兆
　　　　2）1分钟 load >5，5分钟 load >3，15分钟 load <1
　　　　　　短期内繁忙，中期内紧张，很可能是一个拥塞的开始
　　　　3）1分钟 load >5，5分钟 load >5，15分钟 load >5
　　　　　　短中长期都繁忙，系统正在拥塞
　　　　4）1分钟 load <1，5分钟Load>3，15分钟 load >5
　　　　　　短期内空闲，中长期繁忙，不用紧张，系统拥塞正在好转

举个例子，假设我们在一个单 CPU 系统上看到平均负载为 1.73（1分钟），0.60（5分钟），7.98（15分钟），那么说明在过去 1 分钟内，系统有 73% 的超载，而在 15 分钟内，有 698% 的超载，从整体趋
势来看，系统的负载在降低。
当平均负载高于 CPU 数量 70% 的时候，我们就该考虑分析排查负载高的问题了。一旦负载过高，就可
能导致进程响应变慢，进而影响服务的正常功能。

1.3、平均负载与 CPU 使用率

平均负载是指单位时间内，处于可运行状态和不可中断状态的进程数。所以，它不仅包括了正在使用CPU 的进程，还包括等待 CPU 和等待 I/O 的进程。

CPU 使用率，是单位时间内 CPU 繁忙情况的统计，跟平均负载并不一定完全对应。比如：

CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；
I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；
大量等待 CPU 的进程调度也会导致平均负载升高，此时的 CPU 使用率也会比较高。

1.4、监控命令

安装对应的命令：apt install stress sysstat
其中sysstat 包括了mpstat 和pidstat 。

压测命令：stress ，一个 Linux 系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景。

监测命令：mpstat 是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。

pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。

（1）检测是否有活动进程：
sudo ps -ef |grep "nginx: master process" |grep -v grep
（2）检测有几个同样的活动进程
sudo ps -ef |grep "nginx: master process" |grep -v grep |wc -l

top命令

top命令用于查看活动进程的CPU和内存信息，能够实时显示系统中各个进程的资源占用情况，可以按照CPU、内存的使用情况和执行时间对进程进行排序。

我们可以用以下所示的top命令的快捷键对输出的显示信息进行转换。
t：切换报示进程和CPU状态信息。
n：切换显示内存信息。
r：重新设置一个进程的优先级。系统提示用户输人需要改变的进程PID及需要设置的进程优先级，
然后输入个正数值使优先级降低，反之则可以使该进程拥有更高的优先级，即是在原有基础上进行
相加，默认优先级的值是100
k：终止一个进程，系统将提示用户输入需要终止的进程PID o
s：改变刷新的时间间隔。
u：查看指定用户的进程。

top 命令查找cpu占用率最高的程序，找到对应的PID
top -Hp pid ，查看具体进程下的线程，比如

mpstat命令

此命令用于实时监控系统CPU的一些统计信息，这些信息存放在/proc/stat文件中，在多核CPU系统里，不但能查看所有CPU的平均使用信息，还能查看某个特定CPU的信息。
使用方式：mpstat [-P {cpu|ALL}] [internal [count]]
当mpstat不带参数时，输出为从系统启动以来的平均值。

mpstat -P ALL
使用mpstat -P ALL 5 2命令，表示每5秒产生一个报告，总共产生2个。

pidstat

pidstat用于监控全部或指定的进程占用系统资源的情况，包括CPU、内存、磁盘I/O、程切换、线程数等数据。

-u：表示查看cpu相关的性能指标
-w：表示查看上下文切换情况，要想查看每个进程的详细情况，要加上-w
-t：查看线程相关的信息，默认是进程的;常与-w结合使用(cpu的上下文切换包括进程的切换、线程
的切换、中断的切换)
-d：展示磁盘 I/O 统计数据
-p：指明进程号

pidstat -urd -p 进程号
[root@VM_0_ubuntu ~]# pidstat -urd -p 24615
Linux 3.10.0-957.5.1.el7.x86_64 (VM_0_ubuntu)     08/22/2019  x86_64    (1 CPU)

场景一：CPU 密集型进程

# 1、模拟一个 CPU 使用率 100% 的场景
stress --cpu 1 --timeout 600

# 2、在第二个终端运行 uptime 查看平均负载的变化情况
uptime

# 3、第三个终端运行 mpstat 查看 CPU 使用率的变化情况
mpstat -P ALL 5

场景二：I/O 密集型进程

# 1. 第一个终端运行 stress 命令模拟 I/O 压力
stress -i 1 --timeout 600

# 2. 第二个终端运行 uptime 查看平均负载的变化情况
uptime

# 3. 第三个终端运行 mpstat 查看 CPU 使用率的变化情况
mpstat -P ALL 5 1

# 4. 查看是哪个进程，导致 iowait较高
pidstat -u 5 1

场景三：大量进程的场景

# 1. 第一个终端模拟8个进程
stress -c 8 --timeout 600

# 2. 第二个终端uptime
uptime

# 3. 使用pidstat查看进程情况
pidstat -u 5 1

stress --cpu 1 --timeout 600
mpstat -P ALL 5 2
pidstat -urd -p 3320
vmstat 5
apt install sysbench
sysbench --num-threads=10 --max-time=300 --max-requests=1000000 --test=threads run
free -h
iostat
swapon -s
df -h
du -s
du -c

ip -s addr show dev ens33

sar -n DEV 1

1.5、CPU上下文切换

1、所谓的上下文切换，就是把上一个任务的寄存器和计数器保存起来，然后加载新任务的寄存器和计数器，最后跳转到新任务的位置开始执行新任务。
2、根据任务的不同，CPU 的上下文切换就可以分为几个不同的场景，也就是进程上下文切换、线程上下文切换以及中断上下文切换。

1、系统调用上下文切换

linux 进程既可以在用户空间运行，又可以在内核空间中运行。
当它在用户空间运行时，被称为进程的用户态；当它进入进入内核空间的时候，被称为进程的内核态
从用户态到内核态的转变过程，需要通过系统调用来完成
CPU 寄存器里原来的指令位置是在用户态。但是为了执行内核态代码，需要先把用户态的位置保存起
来，然后寄存器更新为内核态指令的新位置。最后跳转到内核态运行内核任务。
当系统调用结束后，CPU 寄存器需要恢复原来保存的用户态位置，然后再切换到用户空间，继续运行进程。一次系统调用发生了两次 CPU 上下文切换！
系统调用过程中对用户态的资源没有任何影响，也不会切换进程，所以也称为特权模式切换

2、进程上下文切换

进程是由内核来管理和调度的，所以进程的切换只发生在内核态。进程的上下文不仅包括了虚拟内存、
栈、全局变量等用户空间的资源，还包括了内核堆栈、寄存器等内核空间的状态。
进程的上下文切换在保存当前进程的内核状态和 CPU 寄存器之前，需要先把该进程的虚拟内存、栈等保
存下来；而加载了下一进程的内核态后再刷新进程的虚拟内存映射关系和用户栈，刷新虚拟内存映射就
涉及到 TLB 快表 (虚拟地址缓存)，因此会影响内存的访问速度。

进程上下文切换的原因
其一，为了保证所有进程可以得到公平调度，CPU 时间被划分为一段段的时间片，这些时间片再被轮流分配给各个进程。这样，当某个进程的时间片耗尽了，就会被系统挂起，切换到其它正在等待 CPU 的进程运行。（被动切换）
其二，进程在系统资源不足，这个时候进程也会被挂起，并由系统调度其他进程运行。（主动切换）
其三，当进程通过睡眠函数 sleep 这样的方法将自己主动挂起时，自然也会重新调度。
其四，当有优先级更高的进程运行时，为了保证高优先级进程的运行，当前进程会被挂起，由高优先级进程来运行。
第五，发生硬件中断时，CPU 上的进程会被中断挂起，转而执行内核中的中断服务程序。

3、线程上下文切换

线程与进程的区别在于：线程是调度的基本单位，而进程是资源分配基本单位。内核中的任务调度，实际调度的是线程；而进程只是给线程提供了虚拟内存、全局变量等资源。
1：当进程只有一个线程时，可以认为进程就等于线程
2：当进程拥有多个线程时，共享虚拟内存和全局变量等资源。这些资源在上下文切换时不需要修改
3：线程也有自己的私有数据，比如栈和寄存器等，这些在上下文切换时需要保存

4、线程的上下文切换分为两种

1.前后两个线程属于不同进程。此时，因为资源不共享，所以切换过程就跟进程上下文切换是一样。
2.前后两个线程属于同一个进程。此时，因为虚拟内存是共享的，所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据、寄存器等不共享的数据

5、中断上下文切换

为了快速响应硬件的事件，中断处理会打断进程的正常调度和执行，转而调用中断处理程序，响应设备
事件。而在打断其他进程时，就需要将进程当前的状态保存下来，这样在中断结束后，进程仍然可以从原来的状态恢复运行。
跟进程上下文不同，中断上下文切换并不涉及到进程的用户态。中断上下文只包括内核态中断服务程序执行所必需的状态，包括 CPU 寄存器、内核堆栈、硬件中断参数等

6、怎么查看上下文切换

过多的上下文切换，会把 CPU 时间消耗在寄存器、内核栈以及虚拟内存等数据的保存和恢复上，缩短进程真正运行的时间，成了系统性能大幅下降的一个元凶。
们可以使用 vmstat 这个工具，来查询系统的上下文切换情况。此命令显示关于内核线程、虚拟内存、
磁盘I/O 、陷阱和CPU占用率的统计信息。

# 每隔5秒输出一组数据
vmstat 5

需要注意如下内容。
r（Running or Runnable）是就绪队列的长度，也就是正在运行和等待 CPU 的进程数。
b（Blocked）则是处于不可中断睡眠状态的进程数。
buff：是I/O系统存储的磁盘块文件的元数据的统计信息。
cache：是操作系统用来缓存磁盘数据的缓冲区，操作系统会自动一调节这个参数，在内存紧张时
操作系统会减少cache的占用空间来保证其他进程可用。
si和so较大时，说明系统频繁使用交换区，应该查看操作系统的内存是否够用。
bi和bo代表I/O活动，根据其大小可以知道磁盘I/O的负载情况。
in（interrupt）则是每秒中断的次数。
cs：参数表示线程环境的切换次数，此数据太大时表明线程的同步机制有问题。

7、案例分析
上下文切换频率是多少次才是正常的？
使用sysbench 来模拟系统多线程调度切换的情况。
有命令，都默认以 root 用户运行，运行 sudo su root 命令切换到 root 用户。

# 1. 测试工具和监测命令的安装：
apt install sysbench sysstat

# 2. 使用vmstat查看空闲系统的上下文切换次数
# 间隔1秒后输出1组数据
vmstat 1 1

# 3. 在另一个终端开始压测
# 以10个线程运行5分钟的基准测试，模拟多线程切换的问题
sysbench --num-threads=10 --max-time=300 --max-requests=10000000 --test=threads run

# 4. 使用vmstat查看
vmstat 1

cs 列：的上下文切换次数从之前的 35 骤然上升到了 139 万。
r 列：就绪队列的长度已经到了 8，远远超过了系统 CPU 的个数 2，所以肯定会有大量的 CPU 竞争。
us（user）和 sy（system）列：这两列的 CPU 使用率加起来上升到了 100%，其中系统 CPU 使用率，也就是 sy 列高达 84%，说明 CPU 主要是被内核占用了。
in 列：中断次数也上升到了 1 万左右，说明中断处理也是个潜在的问题。
综合这几个指标，我们可以知道，系统的就绪队列过长，也就是正在运行和等待 CPU 的进程数过多，
导致了大量的上下文切换，而上下文切换又导致了系统 CPU 的占用率升高。

8、使用pidstat查看

什么进程导致了这些问题呢？
在第三个终端再用 pidstat 来看一下， CPU 和进程上下文切换的情况：

# 每隔1秒输出1组数据（需要 Ctrl+C 才结束）
# -w参数表示输出进程切换指标，而-u参数则表示输出CPU使用指标
$ pidstat -w -u 1

从 pidstat 的输出你可以发现，CPU 使用率的升高果然是 sysbench 导致的，它的 CPU 使用率已经达到了 100%。但上下文切换则是来自其他进程，包括非自愿上下文切换频率最高的 pidstat ，以及自愿上下文切换频率最高的内核线程 kworker 和 sshd。怪异的事儿：pidstat 输出的上下文切换次数，加起来也就几百，比 vmstat 的 139 万明显小了太多。这是怎么回事呢？难道是工具本身出了错吗？别着急，在怀疑工具之前，我们再来回想一下，前面讲到的几种上下文切换场景。其中有一点提到， Linux 调度的基本单位实际上是线程，而我们的场景sysbench 模拟的也是线程的调度问题，那么，是不是 pidstat 忽略了线程的数据呢？通过运行 man pidstat ，你会发现，pidstat 默认显示进程的指标数据，加上 -t 参数后，才会输出线程的指标。所以，我们可以在第三个终端里， Ctrl+C 停止刚才的 pidstat 命令，再加上 -t 参数，重试一下看看

# 每隔1秒输出一组数据（需要 Ctrl+C 才结束）
# -wt 参数表示输出线程的上下文切换指标
pidstat -wt 1

现在你就能看到了，虽然 sysbench 进程（也就是主线程）的上下文切换次数看起来并不多，但它的子线程的上下文切换次数却有很多。看来，上下文切换罪魁祸首，还是过多的 sysbench 线程。
每秒上下文切换多少次才算正常呢？这个数值其实取决于系统本身的 CPU 性能。在我看来，如果系统的上下文切换次数比较稳定，那么从数百到一万以内，都应该算是正常的。但当上下文切换次数超过一万次，或者切换次数出现数量级的增长时，就很可能已经出现了性能问题。

这时，你还需要根据上下文切换的类型，再做具体分析。比方说：
自愿上下文切换变多了，说明进程都在等待资源，有可能发生了 I/O 等其他问题；
非自愿上下文切换变多了，说明进程都在被强制调度，也就是都在争抢 CPU，说明 CPU 的确成了瓶
颈；中断次数变多了，说明 CPU 被中断处理程序占用，还需要通过查看 /proc/interrupts 文件来分析具体的中断类型。

1.6、 遇到CPU利用率高该如何排查

遇到CPU使用率高时，首先确认CPU是消耗在哪一块，如果是内核态占用CPU较高：

1. %iowait 高，这时要重点关注磁盘IO的相关操作，是否存在不合理的写日志操作，数据库操作等；
2. %soft或%cs 高，观察CPU负载是否较高、网卡流量是否较大，可不可以精简数据、代码在是否在多线程操作上存在不合适的中断操作等；
3. %steal 高，这种情况一般发生在虚拟机上，这时要查看宿主机是否资源超限；如果是用户态较高，且没有达到预期的性能，说明应用程序需要优化。

1.7、根据指标查找工具

2、内存性能监控

2.1、内存是什么-虚拟内存和物理内存

操作系统有虚拟内存与物理内存的概念。在很久以前，还没有虚拟内存概念的时候，程序寻址用的都是物理地址。程序能寻址的范围是有限的，这取决于CPU的地址线条数。比如在32位平台下，寻址的范围是2^32也就是4G。并且这是固定的，如果没有虚拟内存，且每次开启一个进程都给4G的物理内存，就可能会出现很多问题：

1、因为我的物理内存时有限的，当有多个进程要执行的时候，都要给4G内存，很显然你内存小一点，这很快就分配完了，于是没有得到分配资源的进程就只能等待。当一个进程执行完了以后，再将等待的进程装入内存。这种频繁的装入内存的操作是很没效率的
2、由于指令都是直接访问物理内存的，那么我这个进程就可以修改其他进程的数据，甚至会修改内核
地址空间的数据，这是我们不想看到的
3、因为内存时随机分配的，所以程序运行的地址也是不正确的

dos2unix和unix2dos

用于转换Windows和UNIX的换行符，通常在Windows系统h开发的脚本和配置，UNIX系统下都需要转换。

使用方式：
dos2unix test.txt
unix2dos test.txt

#转换整个目录
find . -type f -exec dos2unix {} \;
find ./ -type f 此命令是显示当前目录下所有的文件