1.kill
①使用kill -l 查看当前系统所支持的信号
[root@wxb ~]# kill -l
1) SIGHUP 终端的控制进程结束，通知session内的各个作业，脱离关系
2) SIGINT 程序终止信号（Ctrl+c）
3) SIGQUIT 和2号信号类似（Ctrl+\），产生core文件
4) SIGILL 执行了非法指令，可执行文件本身出现错误
5) SIGTRAP 有断点指令或其他trap指令产生，有debugger使用
6) SIGABRT 调用abort函数生成的信号
7) SIGBUS 非法地址（内存地址对齐出错）
8) SIGFPE 致命的算术错误（浮点数运算，溢出，及除数为0 错误）
9) SIGKILL 用来立即结束程序的运行
10) SIGUSR1 用户使用
11) SIGSEGV 访问内存错误
12) SIGUSR2 用户使用
13) SIGPIPE 管道破裂
14) SIGALRM 时钟定时信号
15) SIGTERM 程序结束信号（可被阻塞，处理）
16) SIGSTKFLT 协处理器栈堆错误
17) SIGCHLD 子进程结束，父进程收到这个信号并进行处理，（wait也可以）否则僵尸进程
18) SIGCONT 让一个停止的进程继续执行（不能被阻塞）
19) SIGSTOP 让一个进程停止执行（不能被阻塞，处理，忽略）
20) SIGTSTP 停止进程的运行（可以被处理和忽略）
21) SIGTTIN 当后台作业要从用户终端读数据时, 该作业中的所有进程会收到SIGTTIN信号. 缺省时这些进程会停止执行.
22) SIGTTOU 类似SIGTTIN,但在写终端时收到
23) SIGURG 有紧急数据或者out—of—band 数据到达socket时产生
24) SIGXCPU 超过CPU资源限定，这个限定可改变
25) SIGXFSZ 当进程企图扩大文件以至于超过文件大小资源限制
26) SIGVTALRM 虚拟时钟信号（计算的是该进程占用的CPU时间）
27) SIGPROF 时钟信号（进程用的CPU时间及系统调用时间）
28) SIGWINCH 窗口大小改变时发出
29) SIGIO 文件描述符准备就绪，可以进行读写操作
30) SIGPWR power failure
31) SIGSYS 非法的系统调用
[root@wxb ~]# systemctl start vsftpd
[root@wxb ~]# ps aux|grep vsftpd
root 7810 0.0 0.0 53176 580 ? Ss 14:57 0:00 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
root 7812 0.0 0.0 112708 976 pts/0 R+ 14:58 0:00 grep --color=auto vsftpd
1)发送重载信号，例如 vsftpd 的配置文件发生改变，希望重新加载
[root@wxb ~]# kill -1 7810
[root@wxb ~]# ps aux|grep vsftpd
root 7810 0.0 0.0 53176 760 ? Ss 14:57 0:00 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
root 7814 0.0 0.0 112708 972 pts/0 R+ 14:59 0:00 grep --color=auto vsftpd
2)发送停止信号，当然vsftpd 服务有停止的脚本(sytemctl stop vsftpd)
[root@wxb ~]# kill 7810
[root@wxb ~]# ps aux|grep vsftpd
root 7818 0.0 0.0 112708 976 pts/0 R+ 15:00 0:00 grep --color=auto vsftpd
3)重启后发送强制停止信号
[root@wxb ~]# systemctl start vsftpd
[root@wxb ~]# ps aux|grep vsftpd
root 7826 0.0 0.0 53176 580 ? Ss 15:00 0:00 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
root 7828 0.0 0.0 112708 976 pts/0 R+ 15:00 0:00 grep --color=auto vsftpd
[root@wxb ~]# kill -9 7826
[root@wxb ~]# ps aux|grep vsftpd
root 7843 0.0 0.0 112708 976 pts/0 R+ 15:01 0:00 grep --color=auto vsftpd
②.Linux系统中的killall、pkill命令用于杀死指定名字的进程。我们可以使用kill命令杀死指定进程PID的进程时我们还需要在之前使用ps等命令再配合grep来查找进程，而killall、pkill无需查找
1）用名称
[root@wxb ~]# systemctl start nginx
[root@wxb ~]# ps aux|grep nginx
root 7854 0.0 0.0 46340 968 ? Ss 15:14 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 7855 0.0 0.0 46748 1932 ? S 15:14 0:00 nginx: worker process
root 7857 0.0 0.0 112708 976 pts/0 R+ 15:15 0:00 grep --color=auto nginx
[root@wxb ~]# pkill nginx
[root@wxb ~]# ps aux|grep nginx
root 7862 0.0 0.0 112708 976 pts/0 R+ 15:15 0:00 grep --color=auto nginx
[root@wxb ~]# killall nginx
[root@wxb ~]# ps aux|grep nginx
root 7862 0.0 0.0 112708 976 pts/0 R+ 15:15 0:00 grep --color=auto nginx
2)用终端
[root@wxb ~]# pkill -9 -t pts/0
2.管理后台进程
1).什么是后台进程
通常进程都会在终端前台运行，一旦关闭终端，进程也会随着结束，那么此时我们就希望进程能在后台运行，就是将在前台运行的进程放入后台运行，这样及时我们关闭了终端也不影响进程的正常运行。
2).我们为什么要将进程放入后台运行
比如：我们此前在国内服务器往国外服务器传输大文件时，由于网络的问题需要传输很久，如果在传输的过程中出现网络抖动或者不小心关闭了终端则会导致传输失败，如果能将传输的进程放入后台，是不是就能解决此类问题了。
3).screen
①安装
[root@wxb ~]# yum install screen -y
②打开一个指定的特殊窗口
[root@wxb ~]# screen -S wget_mysql
[root@wxb ~]# wget https://mirrors.aliyun.com/centos/7/isos/x86_64/CentOS-7-x86_64-DVD-1810.iso
使用CTRL+ad退出窗口
③查看后台运行程序
[root@wxb ~]# screen -list
There is a screen on:
7895.wget_mysql (Detached)
1 Socket in /var/run/screen/S-root.
④将后台运行程序调至前台
[root@wxb ~]# screen -r wget_mysql
⑤结束后台运行程序
ctrl+c---->exit
ctrl+c---->ctrl+d
3.进程优先级
- nice 值越高： 表示优先级越低，例如+19，该进程容易将CPU 使用量让给其他进程。
- nice 值越低： 表示优先级越高，例如-20，该进程更不倾向于让出CPU。
nice修改程序优先级
①使用top可以查看nice优先级。 NI: 实际nice级别，默认是0。 PR: 显示nice值，-20映射到0，+19映射到39
②使用ps查看进程优先级
[root@wxb ~]# ps axo command,nice |grep sshd|grep -v
③如何设置进程优先级
[root@wxb ~]# nice -n -5 vim
[1] 98417
[root@wxb ~]# ps axo pid,command,nice |grep 98417
98417 vim -5
renice修改正在运行的进程优先级
①查看sshd进程当前的优先级状态
[root@wxb ~]# ps axo pid,command,nice |grep shd
70840 sshd: root@pts/2 0
98002 /usr/sbin/sshd -D 0
②.调整sshd主进程的优先级
[root@wxb ~]# renice -n -20 98002
98002 (process ID) old priority 0, new priority -20
③.调整之后记得退出终端
[root@wxb ~]# ps axo pid,command,nice |grep shd
70840 sshd: root@pts/2 0
98002 /usr/sbin/sshd -D -20
[root@wxb ~]# exit
④.当再次登陆sshd服务，会由主进程fork子进程(那么子进程会继承主进程的优先级)
[root@wxb ~]# ps axo pid,command,nice |grep shd
98002 /usr/sbin/sshd -D -20
98122 sshd: root@pts/0 -20
4.平均负载
场景一：CPU 密集型进程
1.首先，我们在第一个终端运行 stress 命令，模拟一个 CPU 使用率 100% 的场景：
[root@wxb ~]# stress --cpu 1 --timeout 600
2.接着，在第二个终端运行 uptime 查看平均负载的变化情况使用watch -d 参数表示高亮显示变化的区域(注意负载会持续升高)
[root@wxb ~]# watch -d uptime
17:27:44 up 2 days, 3:11, 3 users, load average: 1.10, 0.30, 0.17
3.最后，在第三个终端运行 mpstat 查看 CPU 使用率的变化情况
-P ALL 表示监控所有 CPU，后面数字 5 表示间隔 5 秒后输出一组数据
[root@wxb ~]# mpstat -P ALL 5
Linux 3.10.0-957.1.3.el7.x86_64 (m01) 2019年04月29日 _x86_64_ (1 CPU)
17时32分03秒 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
17时32分08秒 all 99.80 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00
17时32分08秒 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@wxb ~]# pidstat -u 5 1
Linux 3.10.0-957.1.3.el7.x86_64 (m01) 2019年04月29日 _x86_64_(1 CPU)
17时33分21秒 UID PID %usr %system %guest %CPU CPU Command
17时33分26秒 0 110019 98.80 0.00 0.00 98.80 0 stress
从这里可以明显看到，stress 进程的 CPU 使用率为 100%。
场景二：I/O 密集型进程
1.首先还是运行 stress 命令，但这次模拟 I/O 压力，即不停地执行 sync
[root@wxb ~]# stress --io 1 --timeout 600s
2.然后在第二个终端运行 uptime 查看平均负载的变化情况：
[root@wxb ~]# watch -d uptime
18:43:51 up 2 days, 4:27, 3 users, load average: 1.12, 0.65, 0.00
3.最后第三个终端运行 mpstat 查看 CPU 使用率的变化情况：
显示所有 CPU 的指标，并在间隔 5 秒输出一组数据
[root@wxb ~]# mpstat -P ALL 5
Linux 3.10.0-693.2.2.el7.x86_64 (bgx.com) 2019年05月07日 _x86_64_ (1 CPU)
14时20分07秒 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
14时20分12秒 all 0.20 0.00 82.45 17.35 0.00 0.00 0.00 0.00 0.00 0.00
14时20分12秒 0 0.20 0.00 82.45 17.35 0.00 0.00 0.00 0.00 0.00 0.00
会发现cpu的与内核打交道的sys占用非常高
4.那么到底是哪个进程，导致 iowait 这么高呢？我们还是用 pidstat 来查询
间隔 5 秒后输出一组数据，-u 表示 CPU 指标
[root@wxb ~]# pidstat -u 5 1
Linux 3.10.0-957.1.3.el7.x86_64 (m01) 2019年04月29日 _x86_64_(1 CPU)
18时29分37秒 UID PID %usr %system %guest %wait %CPU CPU Command
18时29分42秒 0 127259 32.60 0.20 0.00 67.20 32.80 0 stress
18时29分42秒 0 127261 4.60 28.20 0.00 67.20 32.80 0 stress
18时29分42秒 0 127262 4.20 28.60 0.00 67.20 32.80 0 stress
可以发现，还是 stress 进程导致的。
场景三：大量进程的场景
当系统中运行进程超出 CPU 运行能力时，就会出现等待 CPU 的进程。
1.首先，我们还是使用 stress，但这次模拟的是 4 个进程
[root@wxb ~]# stress -c 4 --timeout 600
2.由于系统只有 1 个 CPU，明显比 4 个进程要少得多，因而，系统的 CPU 处于严重过载状态
[root@wxb ~]# 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@wxb ~]# pidstat -u 5 1
平均时间: UID PID %usr %system %guest %wait %CPU CPU Command
平均时间: 0 130290 24.55 0.00 0.00 75.25 24.55 - stress
平均时间: 0 130291 24.95 0.00 0.00 75.25 24.95 - stress
平均时间: 0 130292 24.95 0.00 0.00 75.25 24.95 - stress
平均时间: 0 130293 24.75 0.00 0.00 74.65 24.75 - stress
可以看出，4 个进程在争抢 1 个 CPU，每个进程等待 CPU 的时间（也就是代码块中的 %wait 列）高达 75%。
这些超出 CPU 计算能力的进程，最终导致 CPU 过载。