欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  科技

进程管理(二)

程序员文章站 2022-07-09 17:46:15
[toc] 进程的优先级 那么在系统中如何给进程配置优先级 在启动进程时,为不同的进程使用不同的调度策略。 nice值越高:表示优先级越低,例如19,该进程容易将CPU使用量让给其他进程。 nice值越低:表示优先级越高,例如 20,该进程更不倾向于让出CPU。 远程连接不上操作步骤 网络 端口 用 ......

目录

进程的优先级

那么在系统中如何给进程配置优先级

在启动进程时,为不同的进程使用不同的调度策略。

nice值越高:表示优先级越低,例如19,该进程容易将cpu使用量让给其他进程。
nice值越低:表示优先级越高,例如-20,该进程更不倾向于让出cpu。

远程连接不上操作步骤

  • 网络

    ping 10.0.0.100
  • 端口

    telnet 10.0.0.150 22
    tcping 10.0.0.150 22
  • 用户

    root
  • 密码

    1

使用nice命令指定进程优先级

#打开一个终端
[root@zls ~]# nice -n -5 vim zls

#打开另一个终端,查看进程的优先级
[root@zls ~]# ps aux|grep [v]im
root       2342  0.1  0.2 151720  5212 pts/1    s<+  19:49   0:00 vim zls
[root@zls ~]# ps axo command,nice|grep [v]im
vim zls                      -5

使用renice调整已运行程序的优先级

#先查看sshd的优先级
[root@zls ~]# ps axo pid,command,nice|grep 折叠shd
   869 /usr/sbin/sshd -d             0
  1194 sshd: root@pts/0              0
  1307 sshd: root@pts/1              0
  1574 sshd: root@pts/2              0
  
#设置sshd的优先级为-20
[root@zls ~]# renice -n -20 869
869 (进程 id) 旧优先级为 0,新优先级为 -20

#再次查看sshd的优先级
[root@zls ~]# ps axo pid,command,nice|grep 折叠shd
   869 /usr/sbin/sshd -d           -20
  1194 sshd: root@pts/0              0
  1307 sshd: root@pts/1              0
  1574 sshd: root@pts/2              0

#一定要退出终端重新连接
[root@zls ~]# exit
登出

#再检查,就可以看到当前终端的优先级变化了
[root@zls ~]# ps axo pid,command,nice|grep sshd
   869 /usr/sbin/sshd -d           -20
  1194 sshd: root@pts/0              0
  1574 sshd: root@pts/2              0
  2361 sshd: root@pts/1            -20

企业案例,linux假死

什么是假死

所谓假死,就是能ping通,但是ssh不上去;任何其他操作也都没反应,包括上面部署的nginx也打不开页面。

假死如何实现

有一个确定可以把系统搞成假死的办法是:主进程分配固定内存,然后不停的fork,并且在子进程里面sleep(100)。
也就是说,当主进程不停fork的时候,很快会把系统的物理内存用完,当物理内存不足时候,系统会开始使用swap;那么当swap不足时会触发oom killer进程;
当oom killer杀掉了子进程,主进程会立刻fork新的子进程,并再次导致内存用完,再次触发oom killer进程,于是进入死循环。而且oom killer是系统底层优先级很高的内核线程,也在参与死循环。

系统假死为何能ping同无法连接

此时机器可以ping通,但是无法ssh上去。这是由于ping是在系统底层处理的,没有参与进程调度;sshd要参与进程调度,但是优先级没oom killer高,总得不到调度。

怎样解决

其实建议使用nice将sshd的进程优先级调高。这样当系统内存吃紧,还能勉强登陆sshd,进入调试。然后分析故障

后台进程管理

后台进程

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

为什么要把进程放到后台运行

企业中很多时候会有一些需求:
1.传输大文件,由于网络问题需要传输很久
2.我们之前的国外业务,国内到国外,网速很慢,我们需要选择节点做跳板机,那么就必须知道,哪个节点到其他地区网速最快,丢包率最低。
3.有些服务没有启动脚本,那么我们就需要手动运行,并把他们放到后台

后台进程管理

jobs:查看后台进程
bg:永久放到后台
fg:调出后台任务

screen

#安装screen命令
[root@zls ~]# yum install -y screen

#安装redis
[root@zls ~]# yum install -y redis

#启动redis
[root@zls ~]# redis-server

#放到后台ctrl + z
[1]+  已停止               redis-server

#关闭终端,redis进程就没有了

#下载mysql安装包
[root@zls ~]# wget https://downloads.mysql.com/archives/get/file/mysql-5.7.24-linux-glibc2.12-x86_64.tar.gz

#使用screen
[root@zls ~]# screen -s download_mysqld
#ctrl + a + d放置后台
[detached from 3567.download_mysqld]
#查看screen列表
[root@zls ~]# screen -list
there is a screen on:
    3567.download_mysqld    (detached)
1 socket in /var/run/screen/s-root.

#打开screen终端
[root@zls ~]# screen -r 3567

系统平均负载

每次发现系统变慢时,我们通常做的第一件事,就是执行top或者uptime命令,来了解系统的负载情况。

[root@zls ~]# uptime
 20:45:42 up  8:56,  3 users,  load average: 0.01, 0.03, 0.05
#我们已经比较熟悉前面几个例子,他们分别是当前时间,系统运行时间,以及正在登陆用户数

#后面三个数依次是:过去1分钟,5分钟,15分钟的平均负载(load average)

平均负载

那到底如何理解平均负载:平均负载是指,单位时间内,系统处于可运行状态和不可中断状态的平均进程数,也就是平均活跃进程数

ps:平均负载与cpu使用率并没有直接关系。

可运行状态和不可中断状态是什么?

1.可运行状态进程,是指正在使用cpu或者正在等待cpu的进程,也就是我们用ps命令看的处于r状态的进程

2.不可中断进程,(你在做什么事情的时候是不能被打断的呢?...不可描述)系统中最常见的是等待硬件设备的io相应,也就是我们ps命令中看到的d状态(也成为disk sleep)的进程。

例如:当一个进程向磁盘读写数据时,为了保证数据的一致性,在得到磁盘回复前,他是不能被其他进程或者中断程序打断的,这个是后续的进程就处于不可中断的状态,如果此时进程强制被打断,kill -9 ... perfect准备好护照吧,有多远,走多远,千万别回来了。不可中断状态实际上是系统对进程和硬件设备的一种保护机制

因此,可以简单理解为,平均负载其实就是单位时间内的活跃进程数。

平均负载与cpu的使用率有什么关系

在十几工作中,我们经常容易把平均负载和cpu使用率混淆,所以在这里,我也做一个区分,可能你会感觉到疑惑,既然平均负载代表的是活跃进程数,那平均负载搞了,不就意味着cpu使用率高嘛?

我们还是要回到平均负载的含义上来,平均负载指的是每单位时间内,处于可运行状态和不可中断状态的进程数,所以,它不仅包括了正在使用cpu的进程数,还包括等待cpu和等待io的进程数。

而cpu的使用率是单位时间内,cpu繁忙情况的统计,跟平均浮现在并不一定完全对应。
比如:

cpu密集型进程,使用大量的cpu会导致平均负载升高,此时这两者是一致的。
io密集型进程,等待io也会导致平均负载升高,但cpu使用率不一定很高。

大量等待cpu的进程调度也会导致平均负载升高,此时的cpu使用率也会比较高。

但是cpu的种类也分两种:
cpu密集型
io密集型

例如mysql服务器,就需要尽量选择使用io密集型cpu

平均负载案例分析实战

下面我们以三个示例分别来看这三中情况,并用:stress、mpstat、pidstat等工具找出平均负载升高的根源

stress是linux系统压力测试工具,这里我们用作异常进程模拟平均负载升高的场景。

mpstat是多核cpu性能分析工具,用来实时检查每个cpu的性能指标,以及所有cpu的平均指标。

pidstat是一个常用的进程性能分析工具,用来实时查看进程的cpu,内存,io,以及上下文切换等性能指标。

#安装stress,命令sysstat
 yum provides strees    #找寻安装包
[root@zls ~]# yum install -y stress
[root@zls ~]# yum install -y sysstat

案例一:cpu密集型

我们在第一个中断运行stress命令,模拟一个cpu使用率100%的场景:

#第一个终端执行
[root@zls ~]# stress --cpu 1 --timeout 600

#第二个终端查看
[root@zls ~]# uptime
 22:04:12 up 10:15,  4 users,  load average: 1.98, 0.57, 0.22
 
#高亮显示变化区域
[root@zls ~]# watch -d uptime
every 2.0s: uptime                                                                                                                                                                                                                                      sun jul 14 22:05:16 2019

 22:05:16 up 10:16,  4 users,  load average: 2.84, 1.05, 0.41

使用mpstat查看cpu使用率的变化情况

[root@zls ~]# mpstat -p all 5
linux 3.10.0-862.el7.x86_64 (zls)   2019年07月14日     _x86_64_    (1 cpu)

22时08分51秒  cpu    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
22时08分56秒  all   99.20    0.00    0.80    0.00    0.00    0.00    0.00    0.00    0.00    0.00
22时08分56秒    0   99.20    0.00    0.80    0.00    0.00    0.00    0.00    0.00    0.00    0.00

22时08分56秒  cpu    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
22时09分01秒  all   99.60    0.00    0.40    0.00    0.00    0.00    0.00    0.00    0.00    0.00
22时09分01秒    0   99.60    0.00    0.40    0.00    0.00    0.00    0.00    0.00    0.00    0.00

从终端2可以看到,1分钟平均负载会慢慢增加到2.00,而从终端三中还可以看到,正好有一个cpu的使用率为100%,但他的iowait只有0,这说明平均负载的升高正式由于cpu使用率为100%,那么到底哪个进程导致cpu使用率为100%呢?可以使用pidstat来查询

#间隔5秒输出一组数据
[root@zls ~]# pidstat -u 5 1
linux 3.10.0-862.el7.x86_64 (zls)   2019年07月14日     _x86_64_    (1 cpu)

22时14分00秒   uid       pid    %usr %system  %guest    %cpu   cpu  command
22时14分05秒     0      8349    0.00    0.20    0.00    0.20     0  kworker/0:3
22时14分05秒     0      9903   99.60    0.00    0.00   99.60     0  stress

平均时间:   uid       pid    %usr %system  %guest    %cpu   cpu  command
平均时间:     0      8349    0.00    0.20    0.00    0.20     -  kworker/0:3
平均时间:     0      9903   99.60    0.00    0.00   99.60     -  stress

案例二:i/o密集型

还是使用stress命令,但是这次模拟io的压力

[root@zls ~]# stress --io 1 --timeout 600s

在第二个终端运行uptime查看平均负载的变化情况

[root@zls ~]# watch -d uptime
every 2.0s: uptime                                                                                                                                                                                                                                      sun jul 14 22:17:38 2019

 22:17:38 up 10:28,  4 users,  load average: 2.47, 2.25, 1.61

在第三个终端运行mpstat查看cpu使用率的变化情况

[root@zls ~]# mpstat -p all 5
linux 3.10.0-862.el7.x86_64 (zls)   2019年07月14日     _x86_64_    (1 cpu)

22时19分32秒  cpu    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
22时19分37秒  all    2.78    0.00   97.22    0.00    0.00    0.00    0.00    0.00    0.00    0.00
22时19分37秒    0    2.78    0.00   97.22    0.00    0.00    0.00    0.00    0.00    0.00    0.00

22时19分37秒  cpu    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
22时19分42秒  all    3.01    0.00   96.99    0.00    0.00    0.00    0.00    0.00    0.00    0.00
22时19分42秒    0    3.01    0.00   96.99    0.00    0.00    0.00    0.00    0.00    0.00    0.00

#发现cpu与内核打交道的sys占用非常高

那么到底哪个进程导致iowait这么高呢?

[root@zls ~]# pidstat -u 5 1
linux 3.10.0-862.el7.x86_64 (zls)   2019年07月14日     _x86_64_    (1 cpu)

22时20分59秒   uid       pid    %usr %system  %guest    %cpu   cpu  command
22时21分04秒     0      6900    0.00    0.20    0.00    0.20     0  kworker/0:0
22时21分04秒     0     10104    2.76   83.07    0.00   85.83     0  stress
22时21分04秒     0     10105    0.00   10.63    0.00   10.63     0  kworker/u256:2


平均时间:   uid       pid    %usr %system  %guest    %cpu   cpu  command
平均时间:     0      6900    0.00    0.20    0.00    0.20     -  kworker/0:0
平均时间:     0     10104    2.76   83.07    0.00   85.83     -  stress
平均时间:     0     10105    0.00   10.63    0.00   10.63     -  kworker/u256:2

这时候发现看到的数据比较少,需要更新一下命令:

#下载新版本的包
[root@zls ~]# wget http://pagesperso-orange.fr/sebastien.godard/sysstat-11.7.3-1.x86_64.rpm

#升级到新版本
[root@zls ~]# rpm -uvh sysstat-11.7.3-1.x86_64.rpm
准备中...                          ################################# [100%]
正在升级/安装...
   1:sysstat-11.7.3-1                 ################################# [ 50%]
正在清理/删除...
   2:sysstat-10.1.5-17.el7            ################################# [100%]

然后再次查看结果,明显显示的数据多了

[root@zls ~]# pidstat -u 5 1
linux 3.10.0-862.el7.x86_64 (zls)   2019年07月14日     _x86_64_    (1 cpu)

22时24分40秒   uid       pid    %usr %system  %guest   %wait    %cpu   cpu  command
22时24分45秒     0       281    0.00    0.20    0.00    0.40    0.20     0  xfsaild/sda3
22时24分45秒     0     10104    2.99   82.67    0.00    0.00   85.66     0  stress
22时24分45秒     0     10105    0.00    8.76    0.00   92.43    8.76     0  kworker/u256:2
22时24分45秒     0     10118    0.20    0.40    0.00    0.00    0.60     0  watch
22时24分45秒     0     10439    0.00    3.98    0.00   94.82    3.98     0  kworker/u256:3
22时24分45秒     0     11007    0.00    0.20    0.00    0.00    0.20     0  pidstat

平均时间:   uid       pid    %usr %system  %guest   %wait    %cpu   cpu  command
平均时间:     0       281    0.00    0.20    0.00    0.40    0.20     -  xfsaild/sda3
平均时间:     0     10104    2.99   82.67    0.00    0.00   85.66     -  stress
平均时间:     0     10105    0.00    8.76    0.00   92.43    8.76     -  kworker/u256:2
平均时间:     0     10118    0.20    0.40    0.00    0.00    0.60     -  watch
平均时间:     0     10439    0.00    3.98    0.00   94.82    3.98     -  kworker/u256:3
平均时间:     0     11007    0.00    0.20    0.00    0.00    0.20     -  pidstat

案例三:大量进程的场景

当系统运行进程超出cpu运行能力时,就会出现等待cpu的进程。

1.首先,我们还是使用stress命令,模拟的是多个进程

[root@zls ~]# stress -c 4 --timeout 600

2.由于系统只有一个cpu,明显比4个进程要少的多。因此,系统的cpu处于严重过载状态

[root@zls ~]#
every 2.0s: uptime                                                                                                                                                                                                                                      sun jul 14 22:28:50 2019

 22:28:50 up 10:39,  4 users,  load average: 3.96, 3.89, 3.00

3.在运行pidstat命令来查看一下进程的情况

[root@zls ~]# pidstat -u 5 1
linux 3.10.0-862.el7.x86_64 (zls)   2019年07月14日     _x86_64_    (1 cpu)

22时31分12秒   uid       pid    %usr %system  %guest   %wait    %cpu   cpu  command
22时31分17秒     0     11317   24.75    0.00    0.00   75.05   24.75     0  stress
22时31分17秒     0     11318   24.95    0.00    0.00   75.45   24.95     0  stress
22时31分17秒     0     11319   24.75    0.00    0.00   75.25   24.75     0  stress
22时31分17秒     0     11320   24.75    0.00    0.00   75.45   24.75     0  stress
22时31分17秒     0     11381    0.20    0.40    0.00    0.00    0.60     0  watch
22时31分17秒     0     11665    0.00    0.20    0.00    0.00    0.20     0  pidstat

平均时间:   uid       pid    %usr %system  %guest   %wait    %cpu   cpu  command
平均时间:     0     11317   24.75    0.00    0.00   75.05   24.75     -  stress
平均时间:     0     11318   24.95    0.00    0.00   75.45   24.95     -  stress
平均时间:     0     11319   24.75    0.00    0.00   75.25   24.75     -  stress
平均时间:     0     11320   24.75    0.00    0.00   75.45   24.75     -  stress
平均时间:     0     11381    0.20    0.40    0.00    0.00    0.60     -  watch
平均时间:     0     11665    0.00    0.20    0.00    0.00    0.20     -  pidstat

总结

1.平均负载高有可能是cpu密集型进程导致的
2.平均负载高并不一定代表cpu的使用率就一定高,还有可能是i/o繁忙
3.当发现负载高时,可以使用mpstat、pidstat等工具,快速定位到,负载高的原因,从而做出处理