管理进程状态
当程序运行为进程后，如果希望停止进程，怎么办？那么此时我们可以使用linux的kill命令对进程发送关闭信号，当然除了kill、killall、pkill
1.使用kill -l 列出当前系统所支持的信号
虽然linux支持的信号很多，但是我们仅列出我们最为常用的3个信号
| 数字编号 | 信号含义 | 信号翻译 |
|---|---|---|
| 1 | SIGHUP | 通常用来重新加载配置文件 |
| 9 | SIGKILL | 强制杀死进程 |
| 15 | SIGTERM | 终止进程，默认kill使用信号 |
1.我们使用kill命令杀死指定PID的进程
1.给vsftpd 进程发送信号 1,15
[root@oldboy ~]# yum -y install vsftpd
#下载vsftpd
[root@oldboy ~]# systemctl start vsftpd
#开启vsftpd这个程序
[root@oldboy ~]# ps aux|grep vsftpd
#过滤出vsftpd这个进程
2.发送重载停止信号，例如vsftpd 的配置文件发生改变，希望重新加载
[root@oldboy ~]# kill -1 9048
3.发送停止信号，当然vsftpd 服务有停止的脚本，systemctl stop vsftpd
[root@oldboy ~]# kill 9048
4.发送强制停止信号，当无法停止服务时，可强制停止信号
[root@oldboy ~]# kill -9 9048
2.linux系统中的killall、pkll命令用于杀死指定名字的进程。我们可以用使用kill命令杀死指定进程pid的进程，如果要找到我们需要杀死的进程，我们还需要在之前使用ps等命令在配合grep来查找进程，而killall、pkill把这两个进程和二为一，是一个很好用的命令
1.通过服务名称杀掉进程
[root@oldboy ~]# pkill nginx
[root@oldboy ~]# killall nginx
2.使用pkill踢出从远程登录到本机的用户，终止pts/3上所有进程，并且bash也结束（用户被强制退出）
[root@oldboy ~]# pkill -9 -t pts/3
管理后台进程
什么是后台进程
通常进程都会在终端前台运行，一旦关闭终端，进程也会随着结束，那么此时我们就希望进程能在后台运行，就是在前台运行的进程放入后台运行，这样我们关闭了终端也不影响进程的正常运行
我们为什么要将进程放入后台运行
如果我们此时在国内服务器网国外服务器传输大文件时，由于网络的问题要传输很久，如果在传输的过程中出现网络抖动或者不小心关闭了终端则会导致传输失败，日过能将传输的 进程放入后台，就可以解决这类的问题
3.使用什么工具将进程放入后台
早期的时候大家都选择使用符号&将进程放入后台，然后在使用jobs、bg、fg等方式查看进程状态，但太麻烦了，也不直观我们推荐
screen
1.安装
[root@oldboy ~]# yum install screen -y
2.开启一个screen 窗口，指定名称
[root@oldboy ~]# screen -S wger_mysql
3.在screnn 窗口执行任务
4.平滑的退出screen，但不会终止screen中的任务，（使用ctrl+a+b）注意：如果使用exit ctrl+d 这才算真的关闭screen窗口
5.查看当前正在运行的screen有哪些
[root@oldboy ~]# screen -list
There is a screen on:
9127.wger_mysql (Detached)
1 Socket in /var/run/screen/S-root.
6.进入正在运行的screen
[root@oldboy ~]# screen -r wger_mysql
[root@oldboy ~]# screen -r 9127
进程的优先级[进阶]
1.什么是优先级
优先级指的是优先享受资源
为什么要有系统优先级
优先体验 要紧的进程优先解决
系统中如何给进程配置优先级？
在启动进程时，为不同的进程使用不用调度策略
nice值越高：表示优先级越低，例如+19,该进程容易将cpu使用量让给其他进程
nice值越低：表示优先级越高，例如-20,该进程更不倾向于让出cpu
1.使用top或者ps命令查看进程的 优先级
#1.使用top可以查看nice优先级。NI：实际nice级别，默认0.PR:显示nice值， -20映射到0，+19映射到39
2.使用ps查看进程优先级
[root@oldboy ~]# ps axo command,nice |grep sshd|grep -v grep
/usr/sbin/sshd -D 0
sshd: root@pts/1 0
sshd: root@pts/2 0
2.nice指定程序的优先级。语法格式nice -n优先级数字 进程名称
1.开启vim并且指定程序优先级为-5
[root@oldboy ~]# nice -n -5 vim &
2.查看该进程的优先级情况
[root@oldboy ~]# ps axo pid,command,nice |grep 13664
13664 vim -5
13670 grep --color=auto 13664 0
3.renice命令修改一个正在运行的进程有优先级。语法renice -n 优先级数字 进程pid
1.查看sshd进程优先级状态
[root@oldboy ~]# ps axo pid,command,nice |grep shd
1519 /usr/sbin/sshd -D 0
8982 sshd: root@pts/1 0
9162 sshd: root@pts/2 0
13672 grep --color=auto shd 0
2.调整sshd主进程的优先级
[root@oldboy ~]# renice -n -20 1519
1519 (process ID) old priority 0, new priority -20
3.调整之后记得退出终端
[root@oldboy ~]# ps axo pid,command,nice |grep shd
1519 /usr/sbin/sshd -D -20
8982 sshd: root@pts/1 0
9162 sshd: root@pts/2 0
13693 grep --color=auto shd 0
[root@oldboy ~]# exit
4.当再次登录sshd服务，会由主进程fork子进程（那么子进程会继承主进程的优先级）
[root@oldboy ~]# ps axo pid,command,nice |grep shd
1519 /usr/sbin/sshd -D -20
8982 sshd: root@pts/1 0
linux假死
https://www.xuliangwei.com/bgx/1337.html
系统平均负载[进阶]
每次发现系统变慢时，我们通常做的第一件事，就是执行top或者uptime命令，来了解系统的负载情况，比如：我在命令行里输入了uptime命令，系统也随机给出了结果
[root@oldboy ~]# uptime
17:13:53 up 7:32, 2 users, load average: 0.00, 0.01, 0.05
#他们分别是当前时间、系统运行时间以及正在登录用户数。
后面三个数字，依次则是过去1分钟、5分钟、15分钟的平均负载
1.什么是平均负载
平均负载不就是单位时间内的cpu使用率吗？上面的0.70，就代表cpu使用率是70%,其实上.......
那到底如何理解平均负载：平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，PS：平均负载与CPU使用率并没有直接关系
2.可运行状态和不可中断是什么？
1.可运行状态，是指正在使用CPU或者等待cpu进程，也就是我们PS命令看到处于R状态的进程。
2.不可中断进程实际上是系统对进程和硬件设备的一种保护机制。
划重点，因此你可以死理解为，平均负载其实就是单位时间内的活跃进程数。
平均负载为多少时合理
最理想的状态是每个cpu上刚好运行着一个进程，这样每个CPU都得到了充分利用。所以在评判平均负载时，首先你要知道系统有几个cpu，可以通过top命令获取或者[root@oldboy ~]# grep 'model name' /proc/cpuinfo
PS: 平均负载有三个数值，我们应该关注哪个呢?
实际上，我们都需要关注。就好比上海4月的天气，如果只看晚上天气，感觉在过冬天呢。但如果你结合了早上、中午、晚上三个时间点的温度来看，基本就可以全方位了解这一天的天气情况了。
1.如果 1 分钟、5 分钟、15 分钟的三个值基本相同，或者相差不大，那就说明系统负载很平稳。
2.但如果 1 分钟的值远小于 15 分钟的值，就说明系统最近 1 分钟的负载在减少，而过去 15 分钟内却有很大的负载。
3.反过来，如果 1 分钟的值远大于 15 分钟的值，就说明最近 1 分钟的负载在增加，这种增加有可能只是临时性的，也有可能还会持续上升，所以就需要持续观察。
PS: 一旦 1 分钟的平均负载接近或超过了 CPU 的个数，就意味着系统正在发生过载的问题，这时就得分析问题，并要想办法优化了
4.那么在实际生产环境中，平均负载多高时，需要我们重点关注呢？
当平均负载高于 CPU 数量 70% 的时候，你就应该分析排查负载高的问题了。一旦负载过高，就可能导致进程响应变慢，进而影响服务的正常功能。
但 70% 这个数字并不是绝对的，最推荐的方法，还是把系统的平均负载监控起来，然后根据更多的历史数据，判断负载的变化趋势。当发现负载有明显升高趋势时，比如说负载翻倍了，你再去做分析和调查。
5.平均负载与 CPU 使用率有什么关系
在实际工作中，我们经常容易把平均负载和 CPU 使用率混淆，所以在这里，我也做一个区分。可能你会疑惑，既然平均负载代表的是活跃进程数，那平均负载高了，不就意味着 CPU 使用率高吗？
我们还是要回到平均负载的含义上来，平均负载是指单位时间内，处于可运行状态和不可中断状态的进程数。所以，它不仅包括了正在使用 CPU 的进程，还包括等待 CPU 和等待 I/O 的进程。
而 CPU 使用率，是单位时间内 CPU 繁忙情况的统计，跟平均负载并不一定完全对应。比如：
CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；
I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；
大量等待 CPU 的进程调度也会导致平均负载升高，此时的 CPU 使用率也会比较高。
6.平均负载案例分析实战
下面，我们以三个示例分别来看这三种情况，并用 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
rpm -Uvh sysstat-11.7.3-1.x86_64.rpm
场景一：cpu密集进程
1.首先，我们在第一个终端运行stress命令，模拟一个cpu使用率100%的场景
[root@oldboy ~]# stress --cpu 1 --timeout 600
2.接着，在第二个终端运行uptimr查看平均负载的变化情况
#使用watch -d 参数表示高亮变化的区域（注意负载会持续升高）
[root@oldboy ~]# watch -d uptime
Every 2.0s: uptime Thu Aug 22 19:43:51 2019
19:43:51 up 10:02, 2 users, load average: 1.15, 0.66, 0.31
3.最后，在第三个终端运行mpstat查看CPU使用率的变化 情况
# -p ALL 表示监控所有cpu,后面数字5 表示间隔 5 秒 后输出一组数据
[root@oldboy ~]# mpstat -P ALL 5
Linux 3.10.0-957.27.2.el7.x86_64 (oldboy) 08/22/2019 _x86_64_ (1 CPU)
#单核cpu所有只有一个all 和0
4.从终端二中可以看到，1 分钟的平均负载会慢慢增加到 1.00，而从终端三中还可以看到，正好有一个 CPU 的使用率为 100%，但它的 iowait 只有 0。这说明，平均负载的升高正是由于 CPU 使用率为 100% 。那么，到底是哪个进程导致了 CPU 使用率为 100% 呢？可以使用 pidstat 来查询
#间隔 5秒 后输出一组数据
07:55:55 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
07:56:00 PM all 99.40 0.00 0.20 0.00 0.00 0.40 0.00 0.00 0.00 0.00
07:56:00 PM 0 99.40 0.00 0.20 0.00 0.00 0.40 0.00 0.00 0.00 0.00
#从这里可以明显看到，stress进程的cpu使用率为100%
[root@oldboy ~]# pidstat -u 5 1
Linux 3.10.0-957.27.2.el7.x86_64 (oldboy) 08/22/2019 _x86_64_ (1 CPU)
07:57:13 PM UID PID %usr %system %guest %CPU CPU Command
07:57:18 PM 0 988 0.00 0.20 0.00 0.20 0 vmtoolsd
07:57:18 PM 0 14190 98.23 0.00 0.00 98.23 0 stress
场景二： I/O密集型进程
1.首先还是运行 stress 命令，但这次模拟 I/O 压力，即不停地执行 sync
[root@oldboy ~]# stress --io 1 --timeout 600s
2.然后在第二个终端运行 uptime 查看平均负载的变化情况：
Every 2.0s: uptime Thu Aug 22 20:18:56 2019
20:18:57 up 10:37, 4 users, load average: 0.04, 0.28, 0.41
3.最后第三个终端运行 mpstat 查看 CPU 使用率的变化情况：
显示所有cpu的指标，并在间隔 5秒输出一组数据
[root@oldboy ~]# mpstat -P ALL 5
Linux 3.10.0-957.27.2.el7.x86_64 (oldboy) 08/22/2019 _x86_64_ (1 CPU)
08:08:26 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
08:08:31 PM all 2.42 0.00 97.58 0.00 0.00 0.00 0.00 0.00 0.00 0.00
08:08:31 PM 0 2.42 0.00 97.58 0.00 0.00 0.00 0.00 0.00 0.00 0.00
#会发现cpu的与内核打交道的sys占用非常高
4.那么到底是哪个进程，导致 iowait 这么高呢？我们还是用 pidstat 来查询
#间隔 5秒后输出一组数据， -u表示cpu 指标
[root@oldboy ~]# pidstat -u 5 1
Linux 3.10.0-957.27.2.el7.x86_64 (oldboy) 08/22/2019 _x86_64_ (1 CPU)
08:15:12 PM UID PID %usr %system %guest %wait %CPU CPU Command
08:15:17 PM 0 42 0.00 11.88 0.00 3.37 11.88 0 kworker/u256:1
08:15:17 PM 0 14277 0.20 0.20 0.00 0.00 0.40 0 watch
08:15:17 PM 0 14423 0.00 8.51 0.00 2.57 8.51 0 kworker/u256:0
08:15:17 PM 0 14695 0.00 0.20 0.00 0.99 0.20 0 kworker/0:3
08:15:17 PM 0 14744 2.18 75.84 0.00 8.91 78.02 0 stress
08:15:17 PM 0 14763 0.00 0.20 0.00 0.00 0.20 0 pidstat
#可以发现，还是stress进程导致的。
场景三：大量进程的场景
当系统运行进程超出CPU运行能力时，就会出现CPU的进程
1.首先，我们还是使用 stress，但这次模拟的是 4 个进程
[root@oldboy ~]# stress -c 4 --timeout 600
2.由于系统只有1个cpu，明显比4个进程要少得多，因此，系统的ecpu处于严重过载状态
[root@oldboy ~]# watch -d uptime
19:11:07 up 2 days, 4:45, 3 users, load average: 4.65, 2.65, 4.65
3.然后，在运行pidstat来进程看一下进程的情况
#间隔 5 秒后输出一组数据
[root@oldboy ~]# pidstat -u 5 1
Linux 3.10.0-957.27.2.el7.x86_64 (oldboy) 08/22/2019 _x86_64_ (1 CPU)
08:26:40 PM UID PID %usr %system %guest %wait %CPU CPU Command
08:26:45 PM 0 988 0.20 0.20 0.00 5.99 0.40 0 vmtoolsd
08:26:45 PM 0 15348 24.75 0.00 0.00 75.05 24.75 0 stress
08:26:45 PM 0 15349 24.75 0.00 0.00 75.65 24.75 0 stress
08:26:45 PM 0 15350 24.75 0.00 0.00 75.45 24.75 0 stress
08:26:45 PM 0 15351 24.95 0.00 0.00 75.45 24.95 0 stress
08:26:45 PM 0 15354 0.00 0.20 0.00 0.20 0.20 0 watch
08:26:45 PM 0 15421 0.00 0.20 0.00 0.00 0.20 0 pidstat
可以看出，4 个进程在争抢 1 个 CPU，每个进程等待 CPU 的时间（也就是代码块中的 %wait 列）高达 75%。这些超出 CPU 计算能力的进程，最终导致 CPU 过载。
分析完这三个案例，我再来归纳一下平均负载与CPU
平均负载提供了一个快速查看系统整体性能的手段，反映了整体的负载情况。但只是平均负载本身，我们并不能直接发现，到底是哪里出现了瓶颈，所以，在理解平均负载时，也要注意：
平均负载高有可能是CPU密集型进程导致的：
平均负载高并不一定代表CPU使用率高，还有可能是I/O更繁忙了；
当发现负载高的时候，你可以使用mpstat、pidstat 等工具，辅助分析负载的来源
strees
