告别小白，点击直达

进程优先级

1
2
3
4
作用：可以让优先级高的进程，优先使用系统资源，内存、CPU、磁盘、文件描述符...

nice值越高：表示优先级越低，例如19，该进程容易将CPU使用量让给其他进程。
nice值越低：表示优先级越高，例如-20，该进程更不倾向于让出CPU。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
## 查看优先级
[root@localhost ~]# top -n 1 -p 6884
[root@localhost ~]# ps axo pid,user,nice,command|grep sshd
## 配置优先级
# 在进程启动命令之前，加上nice
[root@localhost ~]# nice -n 优先级（-20 ~ 20） 程序启动命令（systemctl不行）
## 配置nginx优先级
# 1.正常启动nginx找到启动命令
[root@localhost ~]# systemctl start nginx
[root@localhost ~]# ps -ef|grep nginx
root 10691 1 0 18:08 ? 00:00:00 nginx: master process
/usr/sbin/nginx
# 2.先停止服务
[root@localhost ~]# systemctl stop nginx
# 3.配置优先级启动
[root@localhost ~]# nice -n -15 /usr/sbin/nginx
# 4.检查是否启动成功
[root@localhost ~]# ps -ef|grep nginx
[root@localhost ~]# netstat -lntup|grep nginx
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
10770/nginx: master
tcp6 0 0 :::80 :::* LISTEN
10770/nginx: master
# 5.检查优先级
[root@localhost ~]# top -p 10770
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10770 root 5 -15
39304 1068 124 S 0.0 0.1 0:00.00 nginx

Linux假死

1
2
3
4
5
6
# ping 通一台机器，一定能ssh连上这台机器吗？
不一定 ping协议：icmp
原因：ping 通，只能能说明icmp协议是通的，不能说明ssh协议是通的
#ping 不通一台机器，一定ssh连不上这台机器吗？
不一定 ping协议：icmp

Linux后台进程管理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# 如何将进程放入后台运行
# 1.方法一：在想要执行的命令后面加上&
[root@localhost ~]# ping baidu.com &
[root@localhost ~]# ping baidu.com >> /tmp/1.txt &
# 2.方法二：在需要放入后台的命令前面加上nohup 后面加上 &
[root@localhost ~]# nohup ping baidu.com & // 在当前目录下生成一个nohup.out文件，
所有输出结果会放入该文件
# 3.方法三：将进程先暂停到后台 输入：bg 将程序放入后台运行（background）
[root@localhost ~]# ping baidu.com
Ctrl + Z // 将程序暂停到后台
bg // 将暂停的程序放入后台运行
fg // 将暂停的程序调到前台运行 根据编号，调用指定的进程到前台
jobs // 查看后台暂停的程序有哪些
# 4.方法四：使用screen，开启新屏幕
[root@localhost ~]# yum install -y screen


## 查看screen后台运行任务
[root@localhost ~]# screen -ls
[root@localhost ~]# screen -list
There are screens on:
11050.sina (Detached)
## 创建卷轴
[root@localhost ~]# screen // 没有命名的卷轴
[root@localhost ~]# screen -S baidu // 指定名字
## 封印 回到前台界面
Ctrl + a + d
## 删除窗口
[root@localhost ~]# screen -S sina -X quit

系统平均负载

每次发现系统变慢时，我们通常做的第一件事，就是执行top或者uptime命令，来了解系统的负载情况。平均负载与CPU使用率并没有直接关系。

1
2
3
4
5
6
7
## 查看系统负载情况
[root@localhost ~]# w
19:36:06 up 3:36, 3 users, load average: 0.00, 0.01, 0.05
[root@localhost ~]# uptime
19:36:10 up 3:36, 3 users, load average: 0.00, 0.01, 0.05
[root@localhost ~]# top -n 1
top - 19:36:15 up 3:36, 3 users, load average: 0.00, 0.01, 0.05
**平均负载是指，单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数**

可运行状态和不可中断状态是什么？

1
2
1.可运行状态进程，是指正在使用CPU或者正在等待CPU的进程，也就是我们用PS命令看的处于R状态的进程
2.不可中断进程，（你在做什么事情的时候是不能被打断的呢？...不可描述）系统中最常见的是等待硬件设备的IO相应，也就是我们PS命令中看到的D状态（也成为Disk Sleep）的进程。平均负载其实就是单位时间内的活跃进程数

平均负载多少时合理？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
最理想的状态是每个CPU上都刚还运行着一个进程，这样每个CPU都得到了充分利用。
所以在评判负载时，首先你要知道系统有几个CPU，这可以通过top命令获取，或grep 'model name'
/proc/cpuinfo
## 如何查看当前系统CPU核心数
[root@localhost ~]# top
[root@localhost ~]# cat /proc/cpuinfo
[root@localhost ~]# lscpu
假设现在在4，2，1核的CPU上，如果平均负载为2时，意味着什么呢？
1.在4个CPU的系统上，意味着CPU有50%空闲。
2.在2个CPU的系统上，以为这所有的CPU都刚好完全被占用。
3.在1个CPU的系统上，则意味着有一半的进程竞争不到CPU。

#三个值关注哪个合理
1）三个值，不能只关注其中一个值（三个都要看）
2）不能根据1分钟负载低情况来判断，当前负载处于下降状态（不关注服务器的问题）


#计算方式
假设我们在有2个CPU系统上看到平均负载为2.73，6.90，12.98那么说明在过去1分钟内，系统有136%的超载
1分钟：（2.73/2*100%=136%）
5分钟：（6.90/2*100%=345%）
15分钟：(12.98/2*100%=649%)
计算公式：（负载/核心数）*100%

负载过高排查

1
2
3
4
5
6
7
web01机器很卡，找出原因
### 压测命令
stress （K8S）是Linux系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景
##################################################################
### 排查工具
mpstat是多核CPU性能分析工具，用来实时检查每个CPU的性能指标，以及所有CPU的平均指标。
pidstat是一个常用的进程性能分析工具，用来实时查看进程的CPU，内存，IO，以及上下文切换等性能指标。

CPU对负载影响

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
[root@localhost ~]# yum intall -y sysstat
## 分析CPU
[root@localhost ~]# mpstat -P ALL 1
[root@localhost ~]# top
%Cpu0 : 99.2 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.8 si, 0.0 st
%Cpu1 :100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 : 0.0 us, 0.0 sy, 0.0 ni, 99.0 id, 0.0 wa, 0.0 hi, 1.0 si, 0.0 st
%Cpu3 :100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
[root@localhost ~]# pidstat -u 5 1
Linux 3.10.0-957.el7.x86_64 (localhost.localdomain) 04/26/2024 _x86_64_(4 CPU)
08:21:50 PM UID PID %usr %system %guest %CPU CPU Command
08:21:55 PM 0 9 0.00 0.20 0.00 0.20 0 rcu_sched
08:21:55 PM 0 60 0.00 0.20 0.00 0.20 0 kworker/0:1
08:21:55 PM 0 6618 0.00 0.20 0.00 0.20 0 sshd
08:21:55 PM 0 6803 99.60 0.20 0.00 99.80 3 java
08:21:55 PM 0 6804 99.40 0.40 0.00 99.80 2 java
08:21:55 PM 0 6805 99.60 0.40 0.00 100.00 1 java
08:21:55 PM 0 6815 0.00 0.20 0.00 0.20 0 pidstat
Average: UID PID %usr %system %guest %CPU CPU Command
Average: 0 9 0.00 0.20 0.00 0.20 - rcu_sched
Average: 0 60 0.00 0.20 0.00 0.20 - kworker/0:1
Average: 0 6618 0.00 0.20 0.00 0.20 - sshd
Average: 0 6803 99.60 0.20 0.00 99.80 - java
Average: 0 6804 99.40 0.40 0.00 99.80 - java
Average: 0 6805 99.60 0.40 0.00 100.00 - java
Average: 0 6815 0.00 0.20 0.00 0.20 - pidstat
## 查找对应程序的日志
tail -f /var/log/nginx/access.log
tial -f /var/log/java/xxxx.log
error：找到报错
## 将日志交给开发处理/分析

测试一下磁盘IO对负载影响

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
## IO对CPU的影响
[root@localhost ~]# mpstat -P ALL 3
Linux 3.10.0-957.el7.x86_64 (localhost.localdomain) 04/26/2024 _x86_64_(4 CPU)
08:29:48 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
08:29:51 PM all 0.17 0.00 73.85 0.00 0.00 0.00 0.00 0.00 0.00 25.98
08:29:51 PM 0 0.00 0.00 66.93 0.00 0.00 0.00 0.00 0.00 0.00 33.07
08:29:51 PM 1 0.00 0.00 68.15 0.00 0.00 0.00 0.00 0.00 0.00 31.85
08:29:51 PM 2 0.00 0.00 79.87 0.00 0.00 0.00 0.00 0.00 0.00 20.13
08:29:51 PM 3 0.00 0.00 78.92 0.00 0.00 0.00 0.00 0.00 0.00 21.08
## iostat 查看磁盘IO信息
[root@localhost ~]# iostat
Linux 3.10.0-957.el7.x86_64 (localhost.localdomain) 04/26/2024 _x86_64_(4 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
16.40 0.00 3.49 0.01 0.00 80.10
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
scd0 0.01 0.53 0.00 1028 0
sda 6.23 283.56 8.79 548598 17015
[root@localhost ~]# pidstat -u 5 1
08:30:36 PM 0 6831 0.40 76.74 0.00 77.14 3 stress
08:30:36 PM 0 6832 0.00 78.13 0.00 78.13 1 stress
08:30:36 PM 0 6833 0.00 74.55 0.00 74.55 3 stress

测试大量进程对负载影响

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[root@localhost ~]# mpstat -P ALL 3
Linux 3.10.0-957.el7.x86_64 (localhost.localdomain) 04/26/2024 _x86_64_(4 CPU)
08:33:45 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
08:33:48 PM all 53.94 0.00 0.25 0.00 0.00 0.25 0.00 0.00 0.00 45.57
08:33:48 PM 0 53.00 0.00 0.50 0.00 0.00 0.00 0.00 0.00 0.00 46.50
08:33:48 PM 1 54.41 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 45.59
08:33:48 PM 2 52.50 0.00 0.50 0.00 0.00 0.50 0.00 0.00 0.00 46.50
08:33:48 PM 3 55.02 0.00 0.00 0.00 0.00 0.48 0.00 0.00 0.00 44.50
[root@localhost ~]# pidstat -u 5 1
08:30:36 PM 0 6831 0.40 76.74 0.00 77.14 3 stress
08:30:36 PM 0 6832 0.00 78.13 0.00 78.13 1 stress
08:30:36 PM 0 6833 0.00 74.55 0.00 74.55 3 stress
# 总结：
1.平均负载高有可能是CPU密集型进程导致的
2.平均负载高并不一定代表CPU的使用率就一定高，还有可能是I/O繁忙
3.当发现负载高时，可以使用mpstat、pidstat等工具，快速定位到，负载高的原因，从而做出处理

负载达到多少时候需要注意

1
2
当平均负载高于CPU数量70%的时候，你就应该分析排查负载高的问题了，一旦负载过高，就可能导致进程相应变慢，进而影响服务的正常功能。
但70%这个数字并不是绝对的，最推荐的方法，还是把系统的平均负载监控起来，然后根据更多的历史数据，判断负载的变化趋势，当发现负载有明显升高的趋势时，比如说负载翻倍了，你再去做分析和调查。