进程管理
# 什么是进程
开发写的代码我们称为程序，那么将开发的代码运行起来，我们称为进程；
总结一句话就是：当我们运行一个程序，那么我们将运行的程序叫进程；
当程序运行为进程后，系统会为该进程分配内存，以及进程运行的身份和权限；
在进程运行的过程中，系统会有各种指标来表示当前运行的状态；
# 程序和进程的区别
- 程序是数据和指令的集合，是一个静态的概念；
- 比如
/bin/ls、/bin/cp等二进制文件，同时程序可以长期存在系统中。
- 比如
- 进程是程序运行的过程，是一个动态的概念；
- 进程是存在生命周期的概念的，也就是说进程会随着程序的终止而销毁，不会永久存在系统中。
# 进程的生命周期
- 生命周期就是指一个对象的生老病死，用处很广；
当父进程接收到任务调度时，会通过fock派生子进程来处理，那么子进程会继承父进程属性；
子进程在处理任务代码时，父进程会进入等待状态，其运行过程是由linux系统进行调度的；
子进程在处理任务代码后，会执行退出，然后唤醒父进程来回收子进程的资源；
如果子进程在处理任务代码过程中异常退出，而父进程却没有回收子进程资源，会导致子进程虽然运行实体已经消失，但仍然在内核的进程表中占据一条记录，长期下去对于系统资源是一个浪费；(僵尸进程)
如果子进程在处理任务过程中，父进程退出了，子进程没有退出，那么这些子进程就没有父进程来管理了，由系统的
system进程管理；(孤儿进程)
PS：每个进程的父进程叫PPID，子进程则叫PID。
# 监控进程状态
- 程序在运行后，我们需要了解进程的运行状态，查看进程的状态分为：
- 静态查看
- 动态查看
# 静态查看进程：ps
ps -aux常用组合，查看进程用户、PID、占用cpu百分比、占用内存百分比、状态、执行的命令等
# 每列含义详解
| 状态 | 描述 |
|---|---|
| USER | 启动进程的用户 |
| PID | 进程运行的ID号 |
| %CPU | 进程占用CPU百分比 |
| %MEM | 进程占用内存百分比 |
| VSZ | 进程占用虚拟内存大小(单位KB) |
| RSS | 进程占用物理内存实际大小(单位KB) |
| TTY | 进程是由哪个终端运行启动的tty1、pts/0等?表示内核程序与终端无关 |
| STAT | 进程运行过程中的状态man ps（/STATE） |
| START | 进程的启动时间 |
| TIME | 进程占用CPU的总时间(为0表示还没超过秒) |
| COMMAND | 程序的运行指令，[方括号]属于内核态的进程。没有[]的是用户态进程。 |
# STAT状态含义
STAT状态的S、Ss、S+、R、R、S+等等，都是什么意思？
STAT基本状态 描述 STAT状态+符号 描述 R 进程运行 s 进程是控制进程，Ss进程的领导者，父进程 S 可中断睡眠 < 进程运行在高优先级上，S<优先级较高的进程 T 进程被暂停 N 进程运行在低优先级上，SN优先级较低的进程 D 不可中断进程 + 当前进程运行在前台，R+该表示进程在前台运行 Z 僵尸进程 l 进程是多线程的，Sl表示进程是以线程方式运行 例一、进程状态切换
- 在终端1上运行
vim；
[root@web ~]# vim new_file1- 在终端2上运行
ps命令查看状态；
[root@web ~]# ps aux|grep new_file # S表示睡眠模式，+表示前台运行 root 58118 0.4 0.2 151788 5320 pts/1 S+ 22:11 0:00 new_file1
2- 在终端1上挂起
vim命令；
按下：ctrl+z1- 回到终端2再次运行
ps命令查看状态；
[root@web ~]# ps aux|grep new_file # T表示停止状态 root 58118 0.1 0.2 151788 5320 pts/1 T 22:11 0:00 vim new_file1
2- 在终端1上运行
例二、不可中断状态进程
- 使用
tar打包文件时，可以通过终端不断查看状态，由S+，R+变为D+
[root@web ~]# tar -czf etc.tar.gz /etc/ /usr/ /var/ [root@web ~]# ps aux|grep tar|grep -v grep root 58467 5.5 0.2 127924 5456 pts/1 R+ 22:22 0:04 tar -czf etc.tar.gz /etc/ [root@web ~]# ps aux|grep tar|grep -v grep root 58467 5.5 0.2 127088 4708 pts/1 S+ 22:22 0:03 tar -czf etc.tar.gz /etc/ [root@web ~]# ps aux|grep tar|grep -v grep root 58467 5.6 0.2 127232 4708 pts/1 D+ 22:22 0:03 tar -czf etc.tar.gz /etc/1
2
3
4
5
6
7
8- 使用
# 动态查看进程：top
top常见指令；
字母 含义 h 查看帮助 1 数字1，显示所有CPU核心的负载 z 以高亮显示数据 b 高亮显示处于R状态的进程 M 按内存使用百分比排序输出 P 按CPU使用百分比排序输出 q 退出top 头部信息详解；
任务 含义 Tasks: 113 total 当前进程的总数 1 running 正在运行的进程数 112 sleeping 睡眠的进程数 0 stopped 停止的进程数 0 zombie 僵尸进程数 %Cpu(s): 0.8 us 系统用户进程使用CPU百分比 3.0 sy 内核中的进程占用CPU百分比，通常内核是于硬件进行交互 95.8 id 空闲CPU的百分比 0.0 wa CPU等待IO完成的时间 0.0 hi 硬中断，占的CPU百分比 0.0 si 软中断，占的CPU百分比 0.0 st 比如虚拟机占用物理CPU的时间
# 管理进程状态
当程序运行为进程后，如果希望停止进程，该怎么做呢？此时我们可以使用kill命令对进程发送关闭信号，当然除了kill、还有killall,pkill。
# 系统支持的信号
使用
kill -l列出当前系统所支持的信号；
虽然linux支持信号很多，但是我们仅列出我们最为常用的3个信号；
数字编号 信号含义 信号翻译 1 SIGHUP 通常用来重新加载配置文件 9 SIGKILL 强制杀死进程 15 SIGTERM 终止进程，默认kill使用该信号
# 关闭进程kill
使用
kill命令，指定要杀死的进程PID，即可停止该进程；- 安装
vsftpd服务，然后启动；
[root@web ~]# yum -y install vsftpd [root@web ~]# systemctl start vsftpd [root@web ~]# ps aux|grep vsftpd1
2
3- 发送重载信号，例如
vsftpd的配置文件发生改变，希望重新加载；
[root@web ~]# kill -1 91601- 发送停止信号，当然
vsftpd服务有停止的脚本systemctl stop vsftpd；
[root@web ~]# kill 91601- 发送强制停止信号，当无法停止服务时，可强制终止信号；
[root@web ~]# kill -9 91601- 安装
# 关闭进程pkill
Linux系统中的
killall、pkill命令用于杀死指定名字的进程；- 我们可以使用
kill命令杀死指定进程PID的进程，如果要找到需要杀死的进程，我们还需要在之前使用ps等命令再配合grep来查找进程，而killall、pkill把这两个过程合二为一，是一个很好用的命令。
- 我们可以使用
例一、通过服务名称杀掉进程；
[root@web ~]# pkill nginx [root@web ~]# killall nginx1
2例二、使用
pkill将远程用户t下线；- 使用
pkill踢出从远程登录到本机的用户，终止pts/0上所有进程, 并且bash也结束（用户被强制退出）
[root@web ~]# pkill -9 -t pts/01- 使用
# 管理后台进程
# 什么是后台进程
通常进程都会在终端前台运行，一旦关闭终端，进程也会随着结束，那么此时我们就希望进程能在后台运行，就是将在前台运行的进程放入后台运行，这样即使我们关闭了终端也不影响进程的正常运行。
# 我们为什么要将进程放入后台运行
比如：我们此前在国内服务器往国外服务器传输大文件时，由于网络的问题需要传输很久，如果在传输的过程中出现网络抖动或者不小心关闭了终端则会导致传输失败，如果能将传输的进程放入后台，是不是就能解决此类问题了。
# 使用什么工具将进程放入后台
早期的时候大家都选择使用nohup+&符号将进程放入后台，然后再使用jobs、bg、fg等方式查看进程状态，但太麻烦了。也不直观，所以我们推荐使用screen。
# nohup方式
使用
nohup将前台进程转换后台运行；[root@web ~]# nohup sleep 3000 & # 运行程序(时)，让其在后台执行 [root@web ~]# sleep 4000 # ^Z,将前台的程序挂起(暂停)到后台 [2]+ Stopped sleep 40001
2
3查看进程运行情况；
[root@web ~]# ps aux |grep sleep1使用
jobs、bg、fg等方式查看后台作业；[root@web ~]# jobs # 查看后台作业 [1]- Running sleep 3000 & [2]+ Stopped sleep 4000 [root@web ~]# bg %2 # 让作业 2 在后台运行 [root@web ~]# fg %1 # 将作业 1 调回到前台1
2
3
4
5
6
# screen方式
安装screen工具；
[root@web ~]# yum install screen -y1开启一个
screen子窗口,可以通过-S指定名称；[root@web ~]# screen -S wget_soft1在
screen窗口中执行任务即可；平滑的退出
screen,但不会终止screen中的任务；# ctrl+a+d1查看当前正在运行的
screen有哪些；[root@web ~]# screen -list There is a screen on: 22058.wget_soft (Detached) 1 Socket in /var/run/screen/S-root.1
2
3
4可以通过
screenid或screen标签名称进入正在运行的screen；[root@web ~]# screen -r wget_soft [root@web ~]# screen -r 22058 [root@web ~]# exit # 退出进程，结束screen1
2
3
# 进程的优先级
# 什么是优先级
- 优先级指的是优先享受资源，比如排队买票时，军人优先、老人优先等等
# 为什么需要优先级
- 举个例子：海底捞火锅正常情况下响应就特别快，那么当节假日来临时人员突增则会导致处理请求特别慢
- 那么假设我是海底捞VIP客户(最高优先级)，无论门店多么繁忙，我都不用排队，海底捞人员会直接服务于我，满足我的需求；
- 如果我不是VIP客户(较低优先级)则进入排队等待状态；
# 如何为进程配置优先级
- 在启动进程时，为不同的进程使用不同的调度策略
nice值越高：表示优先级越低，例如+19，该进程容易将CPU使用量让给其他进程；nice值越低：表示优先级越高，例如-20，该进程更不倾向于让出CPU；
# 查看进程优先级
使用
top命令查看优先级；# NI：实际nice级别，默认是0 # PR：显示nice值，-20映射到0，+19映射到39 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1083 root 20 0 298628 2808 1544 S 0.3 0.1 2:49.28 vmtoolsd 5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:+1
2
3
4
5使用
ps查看进程优先级；[root@web ~]# ps axo command,nice |grep sshd|grep -v grep /usr/sbin/sshd -D 0 sshd: root@pts/2 01
2
3
# nice指定程序的优先级
- nice用于指定新启动程序的优先级
- 语法格式
nice -n 优先级数字 进程名称
- 语法格式
开启
vim并且指定程序优先级为-5；[root@web ~]# nice -n -5 vim & [1] 984171
2查看该进程的优先级情况；
[root@web ~]# ps axo pid,command,nice |grep 98417 98417 vim -51
2
# 使用renice修改进程优先级
renice命令修改一个正在运行的进程优先级- 语法格式
renice -n 优先级数字 进程pid
- 语法格式
查看
sshd进程当前的优先级状态；[root@web ~]# ps axo pid,command,nice |grep [s]shd 70840 sshd: root@pts/2 0 98002 /usr/sbin/sshd -D 01
2
3调整
sshd主进程的优先级；[root@web ~]# renice -n -20 98002 98002 (process ID) old priority 0, new priority -201
2调整之后记得退出终端，重新打开一个新终端；
[root@web ~]# ps axo pid,command,nice |grep [s]shd 70840 sshd: root@pts/2 0 98002 /usr/sbin/sshd -D -20 [root@web ~]# exit1
2
3
4当再次登陆
sshd服务，会由主进程fork子sshd进程(那么子进程会继承主进程的优先级)；[root@web ~]# ps axo pid,command,nice |grep [s]shd 98002 /usr/sbin/sshd -D -20 98122 sshd: root@pts/0 -201
2
3
# 系统平均负载
每次发现系统变慢时，我们通常做的第一件事，就是执行top或者uptime命令，来了解系统的负载情况。比如像下面这样，我在命令行里输入了uptime命令，系统也随即给出了结果。
[root@web ~]# uptime
04:49:26 up 2 days, 2:33, 2 users, load average: 0.70, 0.04, 0.05
# 前面几列，它们分别是当前时间、系统运行时间以及正在登录用户数。
# 最后三个数字依次则是过去1分钟、5分钟、15分钟的平均负载(Load Average)
1
2
3
4
2
3
4
# 什么是平均负载
- 平均负载不就是单位时间内的CPU使用率吗？
- 上面的0.70，就代表CPU使用率是70%？其实并不是；
- 那到底如何理解平均负载
- 平均负载是指单位时间内，系统处于
可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数；或者简单理解"平均负载"是"单位时间内的活跃进程数"； - 平均负载与CPU使用率并没有直接关系；
- 平均负载是指单位时间内，系统处于
# 可运行状态
- 可运行状态进程
- 指正在使用
CPU或者正在等待CPU的进程，也就是我们ps命令看到处于R状态的进程
- 指正在使用
# 不可中断状态
- 不可中断进程
- 系统中最常见的是等待硬件设备的
I/O响应，也就是我们ps命令中看到的D状态（也称为Disk Sleep）的进程； - 例如：当一个进程向磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或者中断打断的，这个时候的进程就处于不可中断状态。如果此时的进程被打断了，就容易出现磁盘数据与进程数据不一致的问题；
- 所以，不可中断状态实际上是系统对进程和硬件设备的一种保护机制；
- 系统中最常见的是等待硬件设备的
# 平均负载合理设定
- 最理想的状态是每个
CPU上都刚好运行着一个进程，这样每个CPU都得到了充分利用； - 所以在评判平均负载时，首先你要知道系统有几个
CPU，这可以通过top命令获取，或grep 'model name' /proc/cpuinfo； - 示例：假设现在在
4、2、1核的CPU上，如果平均负载为2时，意味着什么；- 在4个
CPU的系统上，意味着CPU有50%的空闲。 - 在2个
CPU的系统上，意味着所有的CPU都刚好被完全占用。 - 而1个
CPU的系统上，则意味着有一半的进程竞争不到CPU。
- 在4个
# 平均负载三大指标
平均负载有三个数值，我们应该关注哪个呢？实际上，三个数值我们都需要关注。
如果1分钟、5分钟、15分钟的三个值基本相同，或者相差不大，那就说明系统负载很平稳。
但如果1分钟的值远小于15分钟的值，就说明系统最近1分钟的负载在减少，而过去15分钟内却有很大的负载。
反过来，如果1分钟的值远大于15分钟的值，就说明最近1分钟的负载在增加，这种增加有可能只是临时性的，也有可能还会持续上升，所以就需要持续观察。
一旦1分钟的平均负载接近或超过了CPU的个数，就意味着系统正在发生过载的问题，这时就得分析问题，并要想办法优化了。
例：假设我们在有2个CPU系统上看到平均负载为2.73，6.90，12.98
- 那么说明在过去1分钟内，系统有136%的超载(2.73/2=136%)
- 而在过去5分钟内，有345%的超载(6.90/2=345%)
- 而在过去15分钟内，有649%的超载，(12.98/2=649%)
- 但从整体趋势来看，系统的负载是在逐步的降低。
# 何时需要关注平均负载
- 当平均负载高于
CPU数量70%的时候，你就应该分析排查负载高的问题了。一旦负载过高，就可能导致进程响应变慢，进而影响服务的正常功能； - 但
70%这个数字并不是绝对的，最推荐的方法，还是把系统的平均负载监控起来，然后根据更多的历史数据，判断负载的变化趋势； - 当发现负载有明显升高趋势时，比如说负载翻倍了，你再去做分析和调查；
# 平均负载与CPU使用率
- 在实际工作中，我们经常容易把
平均负载和CPU使用率混淆，所以在这里，我也做一个区分。 - 可能你会疑惑，既然平均负载代表的是活跃进程数，那平均负载高了，不就意味着CPU使用率高吗？
- 我们还是要回到平均负载的含义上来，平均负载是指单位时间内，处于可运行状态和不可中断状态的进程数。
- 所以，它不仅包括了正在使用CPU的进程，还包括等待CPU和等待I/O的进程。
- 而CPU使用率，是单位时间内CPU繁忙情况的统计，跟平均负载并不一定完全对应。比如：
- CPU密集型进程，使用大量CPU会导致平均负载升高，此时这两者是一致的；
- I/O密集型进程，等待I/O也会导致平均负载升高，但CPU使用率不一定很高；
- 大量等待CPU的进程调度也会导致平均负载升高，此时的CPU使用率也会比较高。
# 平均负载案例分析实战
下面，我们以三个示例分别来看这三种情况，并用
stress、mpstat、pidstat等工具，找出平均负载升高的根源。stress是Linux系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景；mpstat是多核CPU性能分析工具，用来实时查看每个CPU的性能指标，以及所有CPU的平均指标。pidstat是一个常用的进程性能分析工具，用来实时查看进程的CPU、内存、I/O以及上下文切换等性能指标。
# 如果出现无法使用mpstat、pidstat命令查看%wait指标建议更新下软件包 wget http://pagesperso-orange.fr/sebastien.godard/sysstat-11.7.3-1.x86_64.rpm yum localinstall sysstat-11.7.3-1.x86_64.rpm1
2
3
4场景一：CPU密集型进程
- 第一个终端运行
stress命令，模拟一个CPU使用率100%的场景：
[root@web ~]# stress --cpu 2 --timeout 6001- 第二个终端运行
uptime查看平均负载的变化情况
# 使用watch -d 参数表示高亮显示变化的区域(注意负载会持续升高) [root@web ~]# watch -d uptime 10:45:25 up 10 days, 12:34, 5 users, load average: 2.13, 1.12, 0.581
2
3
4- 在第三个终端运行
mpstat查看CPU使用率的变化情况
# -P ALL 表示监控所有CPU，后面数字5表示间隔5秒后输出一组数据 [root@web ~]# mpstat -P ALL 5 Linux 3.10.0-1127.19.1.el7.x86_64 (bi) 2021年07月29日 _x86_64_ (2 CPU) 10时46分12秒 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 10时46分17秒 all 92.81 0.00 5.65 0.00 0.00 1.54 0.00 0.00 0.00 0.00 10时46分17秒 0 91.55 0.00 6.69 0.00 0.00 1.76 0.00 0.00 0.00 0.00 10时46分17秒 1 94.00 0.00 4.67 0.00 0.00 1.33 0.00 0.00 0.00 0.00 # 双核CPU所以只有all,0,11
2
3
4
5
6
7
8
9
10- 从终端二中可以看到，1分钟的平均负载会慢慢增加，而从终端三中还可以看到，正好两个CPU的使用率都很高，但它的
iowait只有0。这说明，平均负载的升高正是由于CPU使用率高。那么，到底是哪个进程导致了CPU使用率高呢？可以使用pidstat来查询
# 间隔5秒后输出一组数据 [root@web ~]# pidstat -u 5 1 Linux 3.10.0-1127.19.1.el7.x86_64 (bi) 2021年07月29日 _x86_64_ (2 CPU) 10时48分33秒 UID PID %usr %system %guest %wait %CPU CPU Command 10时48分38秒 0 42283 88.48 0.98 0.00 9.18 89.45 1 stress 10时48分38秒 0 42284 85.55 1.17 0.00 11.52 86.72 0 stress # 从这里可以明显看到，stress进程的CPU使用率高。1
2
3
4
5
6
7
8
9- 第一个终端运行
场景二：I/O密集型进程
- 在第一个终端运行
stress命令，但这次模拟I/O压力，即不停地执行sync
[root@web ~]# stress --io 2 --timeout 600s1- 然后在第二个终端运行
uptime查看平均负载的变化情况：
[root@web ~]# watch -d uptime 11:15:55 up 10 days, 13:01, 5 users, load average: 2.55, 1.11, 0.561
2- 第三个终端运行
mpstat查看CPU使用率的变化情况：
# 显示所有CPU的指标，并在间隔5秒输出一组数据 [root@web ~]# mpstat -P ALL 5 Linux 3.10.0-1127.19.1.el7.x86_64 (bi) 2021年07月29日 _x86_64_ (2 CPU) 11时15分34秒 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 11时15分39秒 all 5.18 0.00 67.84 0.00 0.00 1.07 0.00 0.00 0.00 25.91 11时15分39秒 0 5.50 0.00 68.20 0.00 0.00 1.53 0.00 0.00 0.00 24.77 11时15分39秒 1 4.86 0.00 67.48 0.00 0.00 0.61 0.00 0.00 0.00 27.05 # 会发现cpu的与内核打交道的sys占用非常高1
2
3
4
5
6
7
8
9
10- 那么到底是哪个进程，导致
iowait这么高呢？我们还是用pidstat来查询
# 间隔5秒后输出一组数据，-u表示CPU指标 [root@web ~]# pidstat -u 5 1 Linux 3.10.0-1127.19.1.el7.x86_64 (bi) 2021年07月29日 _x86_64_ (2 CPU) 11时15分23秒 UID PID %usr %system %guest %wait %CPU CPU Command 11时15分28秒 0 51872 1.58 56.83 0.00 10.10 58.42 1 stress 11时15分28秒 0 51873 2.77 55.05 0.00 10.30 57.82 0 stress # 可以发现，还是stress进程导致的。1
2
3
4
5
6
7
8
9
10- 在第一个终端运行
场景三：大量进程的场景
- 当系统中运行进程超出CPU运行能力时，就会出现等待CPU的进程。
- 首先，我们还是使用
stress，但这次模拟的是8个进程
[root@web ~]# stress -c 8 --timeout 6001- 由于系统有2个CPU，明显比8个进程要少得多，因而，系统的CPU处于严重过载状态
[root@web ~]# watch -d uptime 11:34:40 up 10 days, 13:20, 5 users, load average: 8.15, 3.39, 1.451
2- 然后，再运行
pidstat来看一下进程的情况：可以看出，8个进程在争抢2个CPU，每个进程等待CPU的时间（也就是代码块中的%wait列）高达80%。这些超出CPU计算能力的进程，最终导致CPU过载。
# 间隔5秒后输出一组数据 [root@web ~]# pidstat -u 5 1 Linux 3.10.0-1127.19.1.el7.x86_64 (bi) 2021年07月29日 _x86_64_ (2 CPU) 11时34分16秒 UID PID %usr %system %guest %wait %CPU CPU Command 11时34分21秒 0 58001 23.66 0.57 0.00 79.77 24.24 1 stress 11时34分21秒 0 58002 23.47 0.38 0.00 80.34 23.85 1 stress 11时34分21秒 0 58003 23.28 0.57 0.00 79.96 23.85 1 stress 11时34分21秒 0 58004 23.85 0.57 0.00 80.15 24.43 0 stress 11时34分21秒 0 58005 23.66 0.57 0.00 81.49 24.24 0 stress 11时34分21秒 0 58006 23.28 0.38 0.00 80.15 23.66 1 stress 11时34分21秒 0 58007 23.47 0.38 0.00 79.58 23.85 0 stress 11时34分21秒 0 58008 23.66 0.57 0.00 79.58 24.24 0 stress1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 总结
- 分析完这三个案例，我再来归纳一下平均负载与CPU；
- 平均负载提供了一个快速查看系统整体性能的手段，反映了整体的负载情况。但只看平均负载本身，我们并不能直接发现，到底是哪里出现了瓶颈。所以，在理解平均负载时，也要注意：
- 平均负载高有可能是
CPU密集型进程导致的； - 平均负载高并不一定代表
CPU使用率高，还有可能是I/O更繁忙了； - 当发现负载高的时候，你可以使用
mpstat、pidstat等工具，辅助分析负载的来源；
- 平均负载高有可能是
Last Updated: 2024/03/19, 09:15:23