基本概念
- 程序:通常为二进制程序放置在存储媒介中(如硬盘、光盘、软盘、磁带等),以物理文件的形式存在。
- 进程:程序被触发后,执行者的权限与属性、程序的程序代码与所需数据等都会加载到内存中,操作系统并给予这个内存内的单元一个标识符(PID),可以说,进程就是一个正在进行中的程序。
- 系统或网络服务:常驻在内存的进程。通常都是负责一些系统所提供的功能以服务用户各项任务,因此这些常驻进程就会被我们称为服务(daemon)。主要为系统本身所需要的服务和负责网络联机的服务。而网络服务被执行后,它会启动一个可以负责网络监听的端口,以提供外部客户端的链接请求。
工作管理
概述
这个工作管理是用在bash环境下的,也就是说:当我们登录系统取得bash shell 之后,在单一终端机下同时进行多个工作的行为管理。
- 前台:你可以控制与执行命令的这个环境称为前台(foreground)的工作;
- 后台:可以自行运行的工作,无法使用ctrl+c终止它,可使用bg/fg调用该工作;
- 后台中执行的进程不能等待terminal/shell的输入(input)。即不能与用户互动,比如vim可以放在后台挂起,但绝对不能在后台里面执行。
前台与后台
直接将程序放在后台: &
[root@localhost ~]# tar -zpcf /temp/etc.tar.gz /etc &
这样仍会有输出输入到屏幕
数据流重定向后放入后台运行
[root@localhost ~]# tar -zpcf /temp/etc.tar.gz /etc > /dev/null 2>&1 &
[1] 8400 <==[job number] PID
[root@localhost ~]# jobs
[1] + running python rap_worker_post.py > /dev/null 2>&1
将当前的工作丢到后台中“暂停”:ctrl+z
[root@localhost ~]# vim ~/.bashrc
#在vim的一般模式下,按下ctrl+z
[1]+ Stopped
[root@localhost ~]# jobs
[1] - running python rap_worker_post.py > /dev/null 2>&1
[2] + suspended vim .bashr
查看目前的后台工作状态 :jobs -l
[root@localhost ~]# jobs -l
[1] - 55019 running python rap_worker_post.py > /dev/null 2>&1
[2] + 55182 suspended vim .bashrc
+:表示最近被放到后台的工作号码,也是fg命令默认取的工作
-:表示最近最后第二个被放置到后台中的工作号码。
将后台工作拿到前台来处理:fg
[root@localhost ~]# fg <==默认取出+的工作
[root@localhost ~]# fg %1 <==直接取规定的工作号码
让程序在后台运行:bg
[root@localhost ~]# find / -name elasticsearch
#ctrl+z放到后台暂停
[root@localhost ~]# jobs
[1] running python rap_worker_post.py > /dev/null 2>&1
[2] - suspended vim .bashrc
[3] + suspended find / -name elasticsearch
[root@localhost ~]# bg %3;jobs <==将任务3在后台中运行,任务运行完后会自动从jobs中消失
[1] running python rap_worker_post.py > /dev/null 2>&1
[2] + suspended vim .bashrc
[3] - running find / -name elasticsearch
终止后台任务:kill
kill -signal %jobnumber
-1: 重新读取一次参数的配置文件(类似reload);
-2:代表与由键盘输入ctrl+c同样的操作;
-9:立刻强制删除一个工作;
-15:以正常的程序方式终止一项工作。
[root@localhost ~]# kill -9 %1 <==杀掉工作1
-9与-15,两者不同。举例来说,在用vim的时候,会产生一个.filename.swap文件,使用-15会删除这个.filename.swap,但使用-9时,由于vim会被强制删除掉,因此.filename.swap会继续存在文件系统中。
另外,kill后面接的数字默认是PID,如果想要管理bahs的工作控制,要加上%数字。
脱机管理:nohup/setsid/&
场景:
如果只是临时有一个命令需要长时间运行,即脱离当前shell客户端后,仍可以保证它在后台稳定运行呢?
解决方法:
我们知道,当用户注销(logout)或者网络断开时,终端会收到 HUP(hangup)信号从而关闭其所有子进程。因此,我们的解决办法就有两种途径:要么让进程忽略 HUP 信号,要么让进程运行在新的会话里从而成为不属于此终端的子进程。
1、nohup
[root@localhost ~]# nohup ping www.baidu.com
[1] 56648
nohup: 忽略输入并把输出追加到"nohup.out"
[root@localhost ~]# jobs
[1] + running nohup ping www.ibm.com
[root@localhost ~]# ps -ef|grep ibm
root 56648 56577 0 16:34 pts/9 00:00:00 ping www.ibm.com
当断开当前shell客户端,重新连接后
[root@localhost ~]# jobs <==此时执行jobs任务为空
[root@localhost ~]# ps -ef|grep ibm
root 56648 1 0 16:34 ? 00:00:00 ping www.ibm.com <==注意这里父进程变成了1
默认的标准输出和标准错误缺省会被重定向到当前目录的nohup.out文件中。一般我们可在结尾加上”&”来将命令同时放入后台运行,也可用> filename 2>&1 来更改缺省的重定向文件名。
[root@localhost ~]# nohup ping www.baidu.com > /dev/null 2>&1 &
[root@localhost ~]# [1] 56140
[root@localhost ~]# ps -ef |grep 56140
root 56140 55516 0 16:13 pts/9 00:00:00 ping www.baidu.com
2、setsid
nohup 无疑能通过忽略 HUP 信号来使我们的进程避免中途被中断,但如果我们换个角度思考,如果我们的进程不属于接受 HUP 信号的终端的子进程,那么自然也就不会受到 HUP 信号的影响了。setsid 就能帮助我们做到这一点。让我们先来看一下 setsid 的帮助信息:
SETSID(8) Linux Programmer’s Manual SETSID(8)
NAME
setsid - run a program in a new session
SYNOPSIS
setsid program [ arg ... ]
DESCRIPTION
setsid runs a program in a new session.
可见 setsid 的使用也是非常方便的,也只需在要处理的命令前加上 setsid 即可。
[root@pvcent107 ~]# setsid ping www.ibm.com > /dev/null 2>&1 &
[root@pvcent107 ~]# ps -ef |grep www.ibm.com
root 31094 1 0 07:28 ? 00:00:00 ping www.ibm.com
root 31102 29217 0 07:29 pts/4 00:00:00 grep www.ibm.com
[root@pvcent107 ~]#
值得注意的是,上例中我们的进程 ID(PID)为31094,而它的父 ID(PPID)为1(即为 init 进程 ID),并不是当前终端的进程 ID。请将此例与nohup 例中的父 ID 做比较。
&
这里还有一个关于 subshell 的小技巧。我们知道,将一个或多个命名包含在“()”中就能让这些命令在子 shell 中运行中,从而扩展出很多有趣的功能,我们现在要讨论的就是其中之一。
当我们将”&”也放入“()”内之后,我们就会发现所提交的作业并不在作业列表中,也就是说,是无法通过jobs来查看的。让我们来看看为什么这样就能躲过 HUP 信号的影响吧。
subshell 示例
[root@pvcent107 ~]# (ping www.ibm.com &)
[root@pvcent107 ~]# ps -ef |grep www.ibm.com
root 16270 1 0 14:13 pts/4 00:00:00 ping www.ibm.com
root 16278 15362 0 14:13 pts/4 00:00:00 grep www.ibm.com
[root@pvcent107 ~]#
从上例中可以看出,新提交的进程的父 ID(PPID)为1(init 进程的 PID),并不是当前终端的进程 ID。因此并不属于当前终端的子进程,从而也就不会受到当前终端的 HUP 信号的影响了
将当前进程改为脱机运行进程
disown
场景:
我们已经知道,如果事先在命令前加上 nohup 或者 setsid 就可以避免 HUP 信号的影响。但是如果我们未加任何处理就已经提交了命令,该如何补救才能让它避免 HUP 信号的影响呢?
解决方法:
这时想加 nohup 或者 setsid 已经为时已晚,只能通过作业调度和 disown 来解决这个问题了。让我们来看一下 disown 的帮助信息
disown [-ar] [-h] [jobspec ...]
Without options, each jobspec is removed from the table of
active jobs. If the -h option is given, each jobspec is not
removed from the table, but is marked so that SIGHUP is not
sent to the job if the shell receives a SIGHUP. If no jobspec
is present, and neither the -a nor the -r option is supplied,
the current job is used. If no jobspec is supplied, the -a
option means to remove or mark all jobs; the -r option without
a jobspec argument restricts operation to running jobs. The
return value is 0 unless a jobspec does not specify a valid
job.
可以看出,我们可以用如下方式来达成我们的目的。
- 用disown -h jobspec来使某个作业忽略HUP信号。
- 用disown -ah 来使所有的作业都忽略HUP信号。
- 用disown -rh 来使正在运行的作业忽略HUP信号。
ctrl-z 的用途就是将当前进程挂起(Suspend),然后我们就可以用jobs命令来查询它的作业号,再用bg jobspec来将它放入后台并继续运行。需要注意的是,如果挂起会影响当前进程的运行结果,请慎用此方法。
disown 示例1(如果提交命令时已经用“&”将命令放入后台运行,则可以直接使用“disown”)
[root@pvcent107 build]# cp -r testLargeFile largeFile &
[1] 4825
[root@pvcent107 build]# jobs
[1]+ Running cp -i -r testLargeFile largeFile &
[root@pvcent107 build]# disown -h %1
[root@pvcent107 build]# ps -ef |grep largeFile
root 4825 968 1 09:46 pts/4 00:00:00 cp -i -r testLargeFile largeFile
root 4853 968 0 09:46 pts/4 00:00:00 grep largeFile
[root@pvcent107 build]# logout
disown 示例2(如果提交命令时未使用“&”将命令放入后台运行,可使用 CTRL-z 和“bg”将其放入后台,再使用“disown”)
[root@pvcent107 build]# cp -r testLargeFile largeFile2
[1]+ Stopped cp -i -r testLargeFile largeFile2
[root@pvcent107 build]# bg %1
[1]+ cp -i -r testLargeFile largeFile2 &
[root@pvcent107 build]# jobs
[1]+ Running cp -i -r testLargeFile largeFile2 &
[root@pvcent107 build]# disown -h %1
[root@pvcent107 build]# ps -ef |grep largeFile2
root 5790 5577 1 10:04 pts/3 00:00:00 cp -i -r testLargeFile largeFile2
root 5824 5577 0 10:05 pts/3 00:00:00 grep largeFile2
[root@pvcent107 build]#
screen
场景:
我们已经知道了如何让进程免受 HUP 信号的影响,但是如果有大量这种命令需要在稳定的后台里运行,如何避免对每条命令都做这样的操作呢?
解决方法:
此时最方便的方法就是 screen 了。简单的说,screen 提供了 ANSI/VT100 的终端模拟器,使它能够在一个真实终端下运行多个全屏的伪终端。screen 的参数很多,具有很强大的功能,我们在此仅介绍其常用功能以及简要分析一下为什么使用 screen 能够避免 HUP 信号的影响。我们先看一下 screen 的帮助信息:
SCREEN(1) SCREEN(1)
NAME
screen - screen manager with VT100/ANSI terminal emulation
SYNOPSIS
screen [ -options ] [ cmd [ args ] ]
screen -r [[pid.]tty[.host]]
screen -r sessionowner/[[pid.]tty[.host]]
DESCRIPTION
Screen is a full-screen window manager that multiplexes a physical
terminal between several processes (typically interactive shells).
Each virtual terminal provides the functions of a DEC VT100 terminal
and, in addition, several control functions from the ISO 6429 (ECMA
48, ANSI X3.64) and ISO 2022 standards (e.g. insert/delete line and
support for multiple character sets). There is a scrollback history
buffer for each virtual terminal and a copy-and-paste mechanism that
allows moving text regions between windows.
使用 screen 很方便,有以下几个常用选项:
- 用screen -dmS session name来建立一个处于断开模式下的会话(并指定其会话名)。
- 用screen -list 来列出所有会话。
- 用screen -r session name来重新连接指定会话。
screen 示例
[root@pvcent107 ~]# screen -dmS Urumchi
[root@pvcent107 ~]# screen -list
There is a screen on:
12842.Urumchi (Detached)
1 Socket in /tmp/screens/S-root.
[root@pvcent107 ~]# screen -r Urumchi
当我们用“-r”连接到 screen 会话后,我们就可以在这个伪终端里面为所欲为,再也不用担心 HUP 信号会对我们的进程造成影响,也不用给每个命令前都加上“nohup”或者“setsid”了。这是为什么呢?让我来看一下下面两个例子吧。
1. 未使用 screen 时新进程的进程树
[root@pvcent107 ~]# ping www.google.com &
[1] 9499
[root@pvcent107 ~]# pstree -H 9499
init─┬─Xvnc
├─acpid
├─atd
├─2*[sendmail]
├─sshd─┬─sshd───bash───pstree
│ └─sshd───bash───ping
2. 使用了 screen 后新进程的进程树
[root@pvcent107 ~]# screen -r Urumchi
[root@pvcent107 ~]# ping www.ibm.com &
[1] 9488
[root@pvcent107 ~]# pstree -H 9488
init─┬─Xvnc
├─acpid
├─atd
├─screen───bash───ping
├─2*[sendmail]
而使用了 screen 后就不同了,此时 bash 是 screen 的子进程,而 screen 是 init(PID为1)的子进程。那么当 ssh 断开连接时,HUP 信号自然不会影响到 screen 下面的子进程了。
总结
现在几种方法已经介绍完毕,我们可以根据不同的场景来选择不同的方案。nohup/setsid 无疑是临时需要时最方便的方法,disown 能帮助我们来事后补救当前已经在运行了的作业,而 screen 则是在大批量操作时不二的选择了。
进程管理
PS:查看某个时间点的进程
查看自己操作环境(bash)的相关进程
[root@pvcent107 ~]# ps -l
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
4 S 0 30581 30579 4 80 0 - 35931 sigsus pts/0 00:00:00 zsh
0 R 0 30620 30581 0 80 0 - 30319 - pts/0 00:00:00 ps
//具体的详细参数F,S,UID,PID.....请自行google,或参考鸟哥私房菜基础篇第三版P516.
[root@pvcent107 ~]# ps -lA <==大写的A,显示系统所有进程。与ps aux一样,但显示的条目标题不同
查看所有系统运行的进程
[root@pvcent107 ~]# ps aux <==注意这里没有-
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 54340 4132 ? Ss 5月22 0:11 /usr/lib/systemd/systemd --switched-root --system --deserialize 23
root 2 0.0 0.0 0 0 ? S 5月22 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S 5月22 0:00 [ksoftirqd/0]
....
//具体参数参考P517页。
找出与crom与syslog服务有关的PID
[root@pvcent107 ~]# ps aux|egrep '(cron|syslog)'
僵尸进程
成因:通常,造成僵尸进程的成因是因为该进程应该已经执行完毕,或者是因故应该要终止了,但是该进程的父进程却无法完整将该进程结束掉,而造成那个进程一直存在内存当中。
查看:当执行ps查看进程时,若进程后面有 < defunct>,就代表该进程时僵尸进程。
比如:
root 29570 4486 0 16:39 ? 00:00:00 [python] <defunct>
top:动态查看进程的变化
显示内容解析
[root@TG1704 log]# top
top - 14:06:23 up 70 days, 16:44, 2 users, load average: 1.25, 1.32, 1.35
Tasks: 206 total, 1 running, 205 sleeping, 0 stopped, 0 zombie
Cpu(s): 5.9%us, 3.4%sy, 0.0%ni, 90.4%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 32949016k total, 14411180k used, 18537836k free, 169884k buffers
Swap: 32764556k total, 0k used, 32764556k free, 3612636k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28894 root 22 0 1501m 405m 10m S 52.2 1.3 2534:16 java
18249 root 18 0 3201m 1.9g 11m S 35.9 6.0 569:39.41 java
统计信息区:
前五行是当前系统情况整体的统计信息区。下面我们看每一行信息的具体意义。
第一行,任务队列信息,同 uptime 命令的执行结果,具体参数说明情况如下:
14:06:23 — 当前系统时间
up 70 days, 16:44 — 系统已经运行了70天16小时44分钟(在这期间系统没有重启过的吆!)
2 users — 当前有2个用户登录系统
load average: 1.15, 1.42, 1.44 — load average后面的三个数分别是1分钟、5分钟、15分钟的负载情况。
load average数据是每隔5秒钟检查一次活跃的进程数,然后按特定算法计算出的数值。如果这个数除以逻辑CPU的数量,结果高于5的时候就表明系统在超负荷运转了。
第二行, Tasks — 任务(进程),具体信息说明如下:
系统现在共有206个进程,其中处于运行中的有1个,205个在休眠(sleep),stoped状态的有0个,zombie状态(僵尸)的有0个。
第三行,cpu状态信息,具体属性说明如下:
5.9%us — 用户空间占用CPU的百分比。
3.4% sy — 内核空间占用CPU的百分比。
0.0% ni — 改变过优先级的进程占用CPU的百分比
90.4% id — 空闲CPU百分比
0.0% wa — IO等待占用CPU的百分比
0.0% hi — 硬中断(Hardware IRQ)占用CPU的百分比
0.2% si — 软中断(Software Interrupts)占用CPU的百分比
备注:在这里CPU的使用比率和windows概念不同,需要理解linux系统用户空间和内核空间的相关知识!
第四行,内存状态,具体信息如下:
32949016k total — 物理内存总量(32GB)
14411180k used — 使用中的内存总量(14GB)
18537836k free — 空闲内存总量(18GB)
169884k buffers — 缓存的内存量 (169M)
第五行,swap交换分区信息,具体信息说明如下:
32764556k total — 交换区总量(32GB)
0k used — 使用的交换区总量(0K)
32764556k free — 空闲交换区总量(32GB)
3612636k cached — 缓冲的交换区总量(3.6GB)
将top信息进行2次,输出到文本
[root@TG1704 log]# top -b -n 2 > /temp/top.txt
/*
-d : 进程界面更新的秒数,默认是5秒
-b : 以批次的方式执行top
—n : 与-b搭配,意义是,需要进行几次top的输出结果。
-p : 指定某个PID来进行检测
交互命令
?: 显示在top中可以输入的按键命令
P: 以CPU的使用资源排序显示
M: 以内存的使用资源排序显示
N: 以PID来排序
T: 由该进程使用的cpu时间累积排序
k: 给予某个PID一个信号
r: 给予某个重新指定一个nice值
q: 离开top
1.多U多核CPU监控
在top基本视图中,按键盘数字“1”,可监控每个逻辑CPU的状况:
2.进程字段排序
输入M(大写),按内存占用率排序
输入P(大写),按cpu利用率排序
x(小写):高亮排序的字段。
3,q,退出top
pstree,查看进程树
进程优先级
[root@TG1704 log]# ps -l
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
4 S 0 30581 30579 0 80 0 - 35931 sigsus pts/0 00:00:00 zsh
0 R 0 32362 30581 0 80 0 - 30319 - pts/0 00:00:00 ps
PRI表示进程优先级,PRI值越低代表优先级越大,PRI由内核动态调整的,用户无法直接调整PRI。但可以设置Nice值
PRI(new) = PRI(old)+nice
nice值的范围是-20~19
所以当nice为负值时,该程序就会降低PRI值。
使用
//在命令前加nice
[root@TG1704 log]# nice -n -5 vim temp.txt &
[root@TG1704 log]# renice [number] PID
系统资源的查看
free:查看内存使用情况
uname -a:查看系统内核信息
uptime:查看系统启动时间与工作负载
netstat:跟踪网络
dmesg:输出所有的内核开机信息
vmstat:检测系统资源变化