管理进程状态
1.使用命令kill -l 列出当前系统所支持的信号
[root@oldboy ~]# kill -l
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR
31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3
38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8
43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7
58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2
63) SIGRTMAX-1 64) SIGRTMAX
虽然linux支持信号很多，但是我们仅列出我们最为常用的3个信号
| 数字编号 | 信号含义 | 信号翻译 |
|---|---|---|
| 1 | SIGHUP | 通常用来重新加载配置文件 |
| 9 | SIGKILL | 强制杀死进程 |
| 15 | SIGTERM | 终止进程，默认kill使用该信号 |
2.我们使用kill命令杀死指定PID的进程
3.linux系统中的killall、pkill命令用于杀死指定的进程，我们可以使用kill命令杀死指定进程的PID的进程，如果我们找到需要杀死的进程，我们还需要在之前使用ps等命令再配合grep来查找进程，而killall、pkill把这两个过程合二为一，是一个很好用的命令。
kill PID 正常停止一个程序
kill -1 PID 平滑重载配置文件
kill -9 PID 强制杀死进程（对于mysql这类有状态的慎用）
pkill Name 批量干掉程序
killall Name 批量干掉程序
管理后台进程
1.什么是后台进程
通常进程都会在终端前台运行，一旦关闭终端，进程也会随着结束，那么此时我们就希望进程能在后台运行，也就是将在前台运行的程序放在后台运行，这样即使我们关闭了终端也不影响进程的正常运行。
2.我们为什么要将进程放入后台运行
比如：我们此前在国内服务器往国外服务器传输大文件时，由于网络的问题需要传输好久，如果在传输的过程中出现 网络抖动或者不小心关闭了终端则会传输失败，如果能将服务器的进程放入后台，是不是就能解决此问题了。
3.使用什么工具将进程放入后台
早期的时候大家都选择使用&符号将进程放入后台，然后在使用jobs、bg、fg等方式查看进程状态，但太麻烦了，也不直观，所以我们推荐使用screen。
1.jobs、bg、fg的使用(不推荐)
[root@xuliangwei ~]# sleep 3000 & //运行程序(时)，让其在后台执行
[root@xuliangwei ~]# sleep 4000 //^Z,将前台的程序挂起(暂停)到后台
[2]+ Stopped sleep 4000
[root@xuliangwei ~]# ps aux |grep sleep
[root@xuliangwei ~]# jobs //查看后台作业
[1]- Running sleep 3000 &
[2]+ Stopped sleep 4000
[root@xuliangwei ~]# bg %2 #让作业 2 在后台运行
[root@xuliangwei ~]# fg %1 #将作业 1 调回到前台
[root@xuliangwei ~]# kill %1 #kill 1，终止 PID 为 1 的进程
[root@xuliangwei ~]# (while :; do date; sleep 2; done) & #进程在后台运行，但输出依然在当前终端
[root@xuliangwei ~]# (while :; do date; sleep 2; done) &>/dev/null &
2.screen的使用（强烈推荐）
#1.安装
[root@oldboy ~]# yum install screen -y
#2.开启一个screen窗口,指定名称
[root@oldboy ~]# screen -S wget_mysql
#3.在screen窗口中执行任务即可
#4.平滑的退出screen,但不会终止screen中的任务。注意: 如果使用exit 才算真的关闭screen窗口
ctrl+a+d
#5.查看当前正在运行的screen有哪些
[root@oldboy ~]# screen -list
There is a screen on:
18402.wget_mysql (Detached)
1 Socket in /var/run/screen/S-root.
#6.进入正在运行的screen
[root@oldboy ~]# screen -r wget_mysql
[root@oldboy ~]# screen -r 18402
进程的优先级
1.什么是优先级
优先级指的是优先级享受资源
2.系统中如何给进程配置优先级
在启动进程时，为不同的进程使用不同的调度策略。
nice 值越高：表示优先级越低，例如+19，该进程容易将CPU使用量让给其他进程
nice 值越低：表示优先级越高，例如-20，该进程更不倾向于让出CPU
（1）使用top或ps命令查看进程的优先级
1.使用top可以查看nice优先级。NI：实际nice级别，默认十0。 PR：显示nice值，-20映射到0，+19映射到39
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 128284 6868 4180 S 0.0 0.3 0:04.71 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
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/0 0
（2）nice指定程序的优先级，语法格式nice -n优先级数字进程名称
1.开启vim并且指定程序 优先级为-5
[root@oldboy ~]# nice -n -5 vim &
[1] 18947
2.查看该进程的优先级情况
[root@oldboy ~]# ps axo pid,command,nice |grep 18947
18947 vim -5
18949 grep --color=auto 18947 0
[1]+ Stopped nice -n -5 vim
（3）renice命令修改一个正在运行的进程优先级，语法格式renice -n有限
1.查看sshd进程当前的优先级状态
[root@oldboy ~]# ps axo pid,command,nice |grep sshd
7374 /usr/sbin/sshd -D 0
18526 sshd: root@pts/1 0
18818 sshd: root@pts/0 0
18960 grep --color=auto sshd 0
2.调整sshd主进程的优先级
[root@oldboy ~]# renice -n -20 7374
7374 (process ID) old priority 0, new priority -20
3.调整之后记得退出终端
[root@oldboy ~]# ps axo pid,command,nice |grep sshd
7374 /usr/sbin/sshd -D -20
18526 sshd: root@pts/1 0
18818 sshd: root@pts/0 0
18964 grep --color=auto sshd 0
[root@oldboy ~]# exit
4.当再次登陆sshd服务，会由主进程fork子进程（那么子进程会继承主进程的优先级）
[root@oldboy ~]# ps axo pid,command,nice |grep sshd
7374 /usr/sbin/sshd -D -20
18526 sshd: root@pts/1 0
18968 sshd: root@pts/0 -20
18995 grep --color=auto sshd -20
linux出现假死，如何通过nice解决
1.什么是假死
所谓假死，就是能ping通，但是ssh不上去；任何其他操作也都没反应，包括上面部署的nginx也打不开页面。
2.假死其实很难出现一次
作为一个多任务操作系统，要把系统忙死，忙到ssh都连不上去，也不是那么容易的。尤其是现在还有fd保护、进程数保护、最大内存保护之类的机制。
你可以fork很多进程，系统会变得很慢，但是ssh还是能连上去；你可以分配很多内存，但是内存多到一定程度oom killer就会把你的进程杀掉，于是ssh又能工作了。
3.假死是如何实现的
有一个确定可以把系统搞成假死的办法是：主进程分配固定内存，然后不停的fork，并且在子进程里面sleep(100)。
也就是说，当主进程不停fork的时候，很快会把系统的物理内存用完，当物理内存不足时候，系统会开始使用swap；那么当swap不足时会触发oom killer进程；
当oom killer杀掉了子进程，主进程会立刻fork新的子进程，并再次导致内存用完，再次触发oom killer进程，于是进入死循环。而且oom killer是系统底层优先级很高的内核线程，也在参与死循环。
4.系统假死为何能ping同无法连接
此时机器可以ping通，但是无法ssh上去。这是由于ping是在系统底层处理的，没有参与进程调度；sshd要参与进程调度，但是优先级没oom killer高，总得不到调度。
5.出现假死怎么办?
为什么要费那么大的力气把机器搞死？我们知道假死是怎么产生的即可，这样可以针对假死的原因进行预防。 (其实假死的情况很少发生，只有当代码写的bug很多的情况下会出现。)
其实建议使用nice将sshd的进程优先级调高。这样当系统内存吃紧，还能勉强登陆sshd，进入调试。然后分析故障。
系统平均负载
1.什么是平均负载
平均负载不就是单位时间内的 CPU 使用率吗？上面的 0.70，就代表 CPU 使用率是 70%。其实上并.....
那到底如何理解平均负载: 平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数， PS: 平均负载与 CPU 使用率并没有直接关系。
2.可运行状态和不可中断状态是什么
（1）可运行状态进程，是指正在使用 CPU 或者正在等待 CPU 的进程，也就是我们ps 命令看到处于 R 状态的进程。
（2）不可中断进程，(你做什么事情的时候是不能打断的?) 系统中最常见的是等待硬件设备的 I/O 响应，也就是我们 ps 命令中看到的 D 状态（也称为 Disk Sleep）的进程。
例如: 当一个进程向磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或者中断打断的，这个时候的进程就处于不可中断状态。如果此时的进程被打断了，就容易出现磁盘数据与进程数据不一致的问题。所以，不可中断状态实际上是系统对进程和硬件设备的一种保护机制。
PS：可以简单理解为，平均负载其实就是单位时间内的活跃进程数。
3.那平均负载为多少时合理
最理想的状态是每个 CPU 上都刚好运行着一个进程，这样每个 CPU 都得到了充分利用。所以在评判平均负载时，首先你要知道系统有几个 CPU，这可以通过 top 命令获取，或grep 'model name' /proc/cpuinfo
例1、假设现在在 4、2、1核的CPU上，如果平均负载为 2 时，意味着什么呢？
Q1.在4 个 CPU 的系统上，意味着 CPU 有 50% 的空闲。
Q2.在2 个 CPU 的系统上，意味着所有的 CPU 都刚好被完全占用。
Q3.而1 个 CPU 的系统上，则意味着有一半的进程竞争不到 CPU。
PS: 平均负载有三个数值，我们应该关注哪个呢?
实际上，我们都需要关注。
（1）如果 1 分钟、5 分钟、15 分钟的三个值基本相同，或者相差不大，那就说明系统负载很平稳。
（2）但如果 1 分钟的值远小于 15 分钟的值，就说明系统最近 1 分钟的负载在减少，而过去 15 分钟内却有很大的负载。
（3）反过来，如果 1 分钟的值远大于 15 分钟的值，就说明最近 1 分钟的负载在增加，这种增加有可能只是临时性的，也有可能还会持续上升，所以就需要持续观察。
PS: 一旦 1 分钟的平均负载接近或超过了 CPU 的个数，就意味着系统正在发生过载的问题，这时就得分析问题，并要想办法优化了
在来看个例子3、假设我们在有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%)
但从整体趋势来看，系统的负载是在逐步的降低。
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指标建议更新下软件包
#如果出现无法使用mpstat、pidstat命令查看%wait指标建议更新下软件包
[root@oldboy ~]# wget http://pagesperso-orange.fr/sebastien.godard/sysstat-11.7.3-1.x86_64.rpm
[root@oldboy ~]# rpm -Uvh sysstat-11.7.3-1.x86_64.rpm
场景一：CPU 密集型进程
1.首先，我们在第一个终端运行 stress 命令，模拟一个 CPU 使用率 100% 的场景：
[root@m01 ~]# stress --cpu 1 --timeout 600
2.接着，在第二个终端运行 uptime 查看平均负载的变化情况
# 使用watch -d 参数表示高亮显示变化的区域(注意负载会持续升高)
[root@m01 ~]# watch -d uptime
17:34:38 up 33 min, 3 users, load average: 0.29, 0.36, 0.34
3.最后，在第三个终端运行 mpstat 查看 CPU 使用率的变化情况
# -P ALL 表示监控所有 CPU，后面数字 5 表示间隔 5 秒后输出一组数据
[root@m01 ~]# mpstat -P ALL 5
05:34:55 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
05:35:00 PM all 99.80 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00
05:35:00 PM 0 99.80 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00
#单核CPU所以只有一个all和0
4.从终端二中可以看到，1 分钟的平均负载会慢慢增加到 1.00，而从终端三中还可以看到，正好有一个 CPU 的使用率为 100%，但它的 iowait 只有 0。这说明，平均负载的升高正是由于 CPU 使用率为 100% 。那么，到底是哪个进程导致了 CPU 使用率为 100% 呢？可以使用 pidstat 来查询
# 间隔 5 秒后输出一组数据
[root@oldboy ~]# pidstat -u 5 1
Linux 3.10.0-957.el7.x86_64 (oldboy) 08/22/2019 _x86_64_ (1 CPU)
05:35:58 PM UID PID %usr %system %guest %wait %CPU CPU Command
05:36:03 PM 0 8107 99.60 0.00 0.00 0.60 99.60 0 stress
#从这里可以明显看到，stress 进程的 CPU 使用率为 100%。
场景二：I/O 密集型进程
1.首先还是运行 stress 命令，但这次模拟 I/O 压力，即不停地执行 sync
[root@oldboy ~]# stress --io 1 --timeout 600s
2.然后在第二个终端运行 uptime 查看平均负载的变化情况：
[root@oldboy ~]# watch -d uptime
17:38:45 up 37 min, 3 users, load average: 0.81, 0.69, 0.49
3.最后第三个终端运行 mpstat 查看 CPU 使用率的变化情况：
[root@oldboy ~]# mpstat -P ALL 5
05:40:42 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
05:40:47 PM all 1.82 0.00 98.18 0.00 0.00 0.00 0.00 0.00 0.00 0.00
05:40:47 PM 0 1.82 0.00 98.18 0.00 0.00 0.00 0.00 0.00 0.00 0.00
4.那么到底是哪个进程，导致 iowait 这么高呢？我们还是用 pidstat 来查询
# 间隔 5 秒后输出一组数据，-u 表示 CPU 指标
[root@oldboy ~]# pidstat -u 5 1
Linux 3.10.0-957.el7.x86_64 (oldboy) 08/22/2019 _x86_64_ (1 CPU)
05:41:50 PM UID PID %usr %system %guest %wait %CPU CPU Command
05:41:55 PM 0 8319 1.80 80.04 0.00 6.19 81.84 0 stress
#可以发现，还是 stress 进程导致的
场景三：大量进程的场景
当系统中运行进程超出 CPU 运行能力时，就会出现等待 CPU 的进程。
1.首先，我们还是使用 stress，但这次模拟的是 4 个进程
[root@oldboy ~]# stress --cpu 4 --timeout 600
2.由于系统只有 1 个 CPU，明显比 4 个进程要少得多，因而，系统的 CPU 处于严重过载状态
[root@oldboy ~]# watch -d uptime
17:45:00 up 43 min, 3 users, load average: 3.31, 1.80, 1.00
3.然后，再运行 pidstat 来看一下进程的情况：
# 间隔 5 秒后输出一组数据
[root@oldboy ~]# pidstat -u 5 1
Linux 3.10.0-957.el7.x86_64 (oldboy) 08/22/2019 _x86_64_ (1 CPU)
05:45:32 PM UID PID %usr %system %guest %wait %CPU CPU Command
05:45:37 PM 0 8608 24.55 0.00 0.00 74.65 24.55 0 stress
05:45:37 PM 0 8609 24.95 0.00 0.00 75.25 24.95 0 stress
05:45:37 PM 0 8610 24.95 0.00 0.00 75.65 24.95 0 stress
05:45:37 PM 0 8611 24.95 0.00 0.00 75.25 24.95 0 stress
可以看出，4 个进程在争抢 1 个 CPU，每个进程等待 CPU 的时间（也就是代码块中的 %wait 列）高达 75%。这些超出 CPU 计算能力的进程，最终导致 CPU 过载。
PS:归纳平均负载与CPU
平均负载提供了一个快速查看系统整体性能的手段，反映了整体的负载情况。但只看平均负载本身，我们并不能直接发现，到底是哪里出现了瓶颈。所以，在理解平均负载时，也要注意：
平均负载高有可能是 CPU 密集型进程导致的；
平均负载高并不一定代表 CPU 使用率高，还有可能是 I/O 更繁忙了；
当发现负载高的时候，你可以使用 mpstat、pidstat 等工具，辅助分析负载的来源