day21-进程管理2

1.管理进程状态

当程序运行为进程后,如果希望停止进程,怎么办呢? 那么此时我们可以使用linux的kill命令对进程发送关闭信号。当然除了kill、还有killall,pkill

  • 1.使用kill -l列出当前系统所支持的信号



    虽然linux支持信号很多,但是我们仅列出我们最为常用的3个信号

数字编号 信号含义 信号翻译
1 SIGHUP 通常用来重新加载配置文件
9 SIGKILL 强制杀死进程
15 SIGTERM 终止进程,默认kill使用该信号

1.我们使用kill、pkill命令杀死指定PID的进程。

[root@localhost ~]# ps aux | grep nginx
root       6885  0.0  0.2  46440   980 ?        Ss   08:31   0:00 nginx: master process nginx
nginx      6887  0.0  0.4  46852  2176 ?        S    08:31   0:00 nginx: worker process
root      10490  0.0  0.2 112708   976 pts/0    R+   17:08   0:00 grep --color nginx
[root@localhost ~]# kill 6885
[root@localhost ~]# ps aux | grep nginx
root      10520  0.0  0.2 112708   976 pts/0    S+   17:08   0:00 grep --color nginx

2.Linux系统中的killall、pkill命令用于杀死指定名字的进程。我们可以使用kill命令杀死指定进程PID的进程,如果要找到我们需要杀死的进程,我们还需要在之前使用ps等命令再配合grep来查找进程,而killall、pkill把这两个过程合二为一,是一个很好用的命令。

---------使用pkill--------
[root@localhost ~]# ps aux | grep nginx
root      10536  0.0  0.2  46440   980 ?        Ss   17:10   0:00 nginx: master process nginx
nginx     10538  0.0  0.4  46852  1936 ?        S    17:10   0:00 nginx: worker process
root      10553  0.0  0.2 112708   972 pts/0    R+   17:10   0:00 grep --color nginx
[root@localhost ~]# pkill nginx
[root@localhost ~]# ps aux | grep nginx
root      10584  0.0  0.2 112708   976 pts/0    S+   17:10   0:00 grep --color nginx

---------使用killall--------
[root@localhost ~]# ps aux | grep nginx
root      10536  0.0  0.2  46440   980 ?        Ss   17:10   0:00 nginx: master process nginx
nginx     10538  0.0  0.4  46852  1936 ?        S    17:10   0:00 nginx: worker process
root      10553  0.0  0.2 112708   972 pts/0    R+   17:10   0:00 grep --color nginx
[root@localhost ~]# killall nginx
[root@localhost ~]# ps aux | grep nginx
root      10584  0.0  0.2 112708   976 pts/0    S+   17:10   0:00 grep --color nginx

2.管理后台进程

1.什么是后台进程

  • 通常进程都会在终端前台运行,一旦关闭终端,进程也会随着结束,那么此时我们就希望进程能在后台运行,就是将在前台运行的进程放入后台运行,这样及时我们关闭了终端也不影响进程的正常运行。

2.我们为什么要将进程放入后台运行

  • 比如:我们此前在国内服务器往国外服务器传输大文件时,由于网络的问题需要传输很久,如果在传输的过程中出现网络抖动或者不小心关闭了终端则会导致传输失败,如果能将传输的进程放入后台,是不是就能解决此类问题了。

3.使用什么工具将进程放入后台

  • 早期的时候大家都选择使用&符号将进程放入后台,然后在使用jobs、bg、fg等方式查看进程状态,但太麻烦了。也不直观,所以我们推荐使用screen。

4.screen的使用(强烈推荐,生产必用)

#1.开启一个screen窗口,指定名称
[root@localhost ~]# screen -S wget
[screen is terminating]

#2.在screen窗口中执行任务即可

#4.ctrl+a+d 平滑的退出screen,但不会终止screen中的任务。
注意: 如果使用exit或者ctrl+d(先使用ctrl+c)才算真的关闭screen窗口


#5.查看当前正在运行的screen有哪些
[root@localhost ~]# screen -list
There is a screen on:
    10667.wget  (Detached)
1 Socket in /var/run/screen/S-root.
#6.进入正在运行的screen
[root@localhost ~]# screen -r
 wget

3.进程的优先级[进阶]

1.什么优先级

  • 优先级指的是优先享受资源,比如排队买票时,军人优先、老人优先。等等

2.为什么要有系统优先级

  • 举个例子: 海底捞火锅正常情况下响应就特别快,那么当节假日来临时人员突增则会导致处理请求特别慢,那么假设我是海底捞VIP客户(最高优先级),无论门店多么繁忙,我都不用排队,海底捞人员会直接服务于我,满足我的需求。至于没有VIP的人员(较低优先级)则进入排队等待状态。(PS: 至于等多久,那.....)

3.系统中如何给进程配置优先级?

  • 在启动进程时,为不同的进程使用不同的调度策略。
    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
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:+

#2.使用ps查看进程优先级
[root@localhosts ~]# ps axo command,nice |grep sshd|grep -v grep
/usr/sbin/sshd -D             0
sshd: root@pts/2              0

2.nice指定程序的优先级。语法格式 nice -n 优先级数字 进程名称

#1.开启vim并且指定程序优先级为-5
[root@m01 ~]# nice -n -5 vim &
[1] 98417

#2.查看该进程的优先级情况
[root@localhosts ~]# ps axo pid,command,nice |grep 98417
 98417 vim                         -5

3.renice命令修改一个正在运行的进程优先级。语法格式 renice -n 优先级数字 进程pid

#1.查看sshd进程当前的优先级状态
[root@m01 ~]# ps axo pid,command,nice |grep 折叠shd
 70840 sshd: root@pts/2              0
 98002 /usr/sbin/sshd -D             0
 
#2.调整sshd主进程的优先级
[root@localhosts ~]# renice -n -20 98002
98002 (process ID) old priority 0, new priority -20

#3.调整之后记得退出终端
[root@localhosts ~]# ps axo pid,command,nice |grep 折叠shd
 70840 sshd: root@pts/2              0
 98002 /usr/sbin/sshd -D           -20
[root@localhosts ~]# exit

#4.当再次登陆sshd服务,会由主进程fork子进程(那么子进程会继承主进程的优先级)
[root@localhosts ~]# ps axo pid,command,nice |grep 折叠shd
 98002 /usr/sbin/sshd -D           -20
 98122 sshd: root@pts/0            -20

4.系统平均负载[进阶]

每次发现系统变慢时,我们通常做的第一件事,就是执行 top 或者 uptime 命令,来了解系统的负载情况。比如像下面这样,我在命令行里输入了 uptime 命令,系统也随即给出了结果。

[root@localhosts ~]# uptime
 04:49:26 up 2 days,  2:33,  2 users,  load average: 0.70, 0.04, 0.05
#我们已经比较熟悉前面几列,它们分别是当前时间、系统运行时间以及正在登录用户数。

# 而最后三个数字呢,依次则是过去 1 分钟、5 分钟、15 分钟的平均负载(Load Average)。

平均负载案例分析实战

下面,我们以三个示例分别来看这三种情况,并用 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@localhosts ~]# stress --cpu 1 --timeout 600

------2.接着,在第二个终端运行 uptime 查看平均负载的变化情况-----
# 使用watch -d 参数表示高亮显示变化的区域(注意负载会持续升高)
[root@m01 ~]# 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@localhosts ~]# 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@localhosts ~]# 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%。

你可能感兴趣的:(day21-进程管理2)