• 进入"运维那点事"后,希望您第一件事就是阅读“关于”栏目,仔细阅读“关于Ctrl+c问题”,不希望误会!

Linux中进程管理命令

系统管理 彭东稳 9年前 (2015-09-01) 20718次浏览 已收录 0个评论

一、进程的类型

在Linux中有守护(daemon)进程,在后台运行;还有一种在前台运行的进程,那么这种进程会阻塞此终端,做不了别的事情了,但是此类进行可以使用类似supervisor这样的工具来进行维护。而Linux中的守护进程也分为两种:独立守护进程和瞬时守护进程。

独立守护进程:chkconfig可以控制关联运行级别的服务,这种进程又两大特点:一是可以自行启动运行而不需要利用系统其他机制来管理,二是启动之后会一直占用系统内存与系统资源。因而这种守护进程有一个非常突出的优点响应最快。这种进程在Linux中也非常多;如apachemysql等。

超级守护进程xinetd:管理瞬时守护进程相当于代理人不需要关联至运行级别和不需要实时守护当有其他进程来访问时由超级守护进程来通知瞬时守护进程并唤醒;特点跟独立守护相反。

xinetd守护进程的配置文件放置在/etc/xinetd.d/目录下和/etc/xinetd.conf文件中。一般不用关心xinetd.conf文件的内容。而/etc/xinetd.d中的每个文件代表一个独立的xinetd守护进程。

安装xinetd

瞬时守护进程

二、进程管理命令

ps

显示静态进程信息(BSD风格)

进程的基本属性解释:

ps

显示静态进程信息(SysV风格)

对于SysV风格的ps选项可以发现多了一个PPID字段,就是用于显示此进行的父进程的PID,在排查进程问题的时候还是很有用的。

另外,ps可以显示给定进程的相关线程:

top

显示动态系统进程活动状态以及一些系统状况信息,top作为日常管理工作中最常用也是最重要的Linux系统监控工具之一,可以动态观察系统进程状况。top命令显示的项目很多,默认值是每5秒更新一次。

常用选项

使用示例

Linux中进程管理命令

第1行信息(top)

第2行信息(Tasks)

第3-10行信息(Cpu0)

第11行信息(KiB Mem)

第12行信息(KiB Swap)

第13行信息(KiB Swap)

top常用的命令

查问题的大招,多种条件合并显示,-p指定进程号,-d每10秒刷新一次,-c显示指令完整命令,-H显示相关线程。

Linux中进程管理命令

uptime:系统简单信息输出(同top命令第一行)

pstree

以树状结构显示进程,并显示进程号。

pgrep

以名称为依据从运行进程队列中查找进程,并显示查找到的进程id。每一个进程ID以一个十进制数表示,通过一个分割字符串和下一个ID分开,默认的分割字符串是一个新行。对于每个属性选项,用户可以在命令行上指定一个以逗号分割的可能值的集合。

kill

终止一个进程

Linux中的重要信号

1=SIGHUP :让一个进程不用重启就可以重读其配置文件并让新的配置信息生效;

2=SIGINT :中断一个进程;

9=SIGKILL :强制杀死一个进程;

15=SIGTERM :终止一个进程,默认信号;

pidof

根据进程名查找其PID号

&

把作业启动时直接送到后台执行

Ctrl+z

把已经启动的作业送到后台,进程在后台默认为停止状态

jobs

查看后台的作业(作业号不同于进程号)

bg 

后台停止的作业运行起来

fg

把后台的作业调到前台执行

kill %JOB_ID

终止后台作业,%不能省略不然就成了终止进程

pmap

查看进程占用的内存空间

也可以使用cat /proc/1/maps查看1号进程占据内存的空间,每个进程都有。

vmstat

查看系统状态、CPU使用率、内存、IO等情况

procs段

memory段

swap段

io段

System段

Cpu段

iostat 

查看CPU负载,硬盘状况

avg-cpu段意义

Device段意义

dstat

使用Python编写的dstat实时查看命令是一个可以取代vmstatiostatnetstatifstat这些命令的多功能产品;dstat克服了这些命令的局限并增加了一些另外的功能,增加了监控项也变的更加灵活了;dstat可以很方便监控系统运行的状况并用于基准测试和排除故障。

可带的选项

dstat附带了一些插件很大程度地扩展了它的功能可通过/usr/share/dstat/目录查看

htop

top更高级的进程监控工具

Linux中进程管理命令

 

 

 

 

 

 

 

 

 

F1:显示帮助信息以便使用Htop

F2:进入htop的设定界面;可以根据自己的使用习惯和风格定制化

F3htop提供的搜索功能;输入进程名即可

F4:进入过滤器、相当于关键字搜索且不区分大小写

F5:显示树状结构

F6:选择排序方式;最常用的就是cpumemory

F7htop提供的nice-;选定一个进程直接可以调整nice

F8htop提供的nice+;选定一个进程直接可以调整nice

F9:结束进程

安装htop

三、守护进程控制命令”chkconfig”

chkconfig命令是CentOS 7之前系统使用的服务控制命令,在CentOS 7系统中开始使用systemd init管理服务了,所以此命令已经没用了。

四、CPU利用率和负载率的区别

这里要区别CPU负载和CPU利用率,它们是不同的两个概念,但它们的信息可以在同一个top命令中进行显示。CPU利用率显示的是程序在运行期间实时占用的CPU百分比,这是对一个时间段内CPU使用状况的统计,通过这个指标可以看出在某一个时间段内CPU被占用的情况, 如果被占用时间很高,那么就需要考虑CPU是否已经处于超负荷运作。而CPU负载显示的是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息,也就是CPU使用队列的长度的统计信息。

CPU利用率高并不意味着负载就一定大,可能这个任务是一个CPU密集型的。一样CPU低利用率的情况下是否会有高Load Average的情况产生呢?理解占有时间和使用时间就可以知道,当CPU分配时间片以后,是否使用完全取决于使用者,因此完全可能出现低利用率高Load Average的情况。另外IO设备也可能导致CPU负载高。

由此来看,仅仅从CPU的使用率来判断CPU是否处于一种超负荷的工作状态还是不够的,必须结合Load Average来全局的看CPU的使用情况。网上有个例子来说明两者的区别如下:某公用电话亭,有一个人在打电话,四个人在等待,每人限定使用电话一分钟,若有人一分钟之内没有打完电话,只能挂掉电话去排队,等待下一轮。电话在这里就相当于CPU,而正在或等待打电话的人就相当于任务数。在电话亭使用过程中,肯定会有人打完电话走掉,有人没有打完电话而选择重新排队,更会有新增的人在这儿排队,这个人数的变化就相当于任务数的增减。为了统计平均负载情况,我们5秒钟统计一次人数,并在第1、5、15分钟的时候对统计情况取平均值,从而形成第1、5、15分钟的平均负载。有的人拿起电话就打,一直打完1分钟,而有的人可能前三十秒在找电话号码,或者在犹豫要不要打,后三十秒才真正在打电话。如果把电话看作CPU,人数看作任务,我们就说前一个人(任务)的CPU利用率高,后一个人(任务)的CPU利用率低。当然, CPU并不会在前三十秒工作,后三十秒歇着,CPU是一直在工作。只是说,有的程序涉及到大量的计算,所以CPU利用率就高,而有的程序牵涉到计算的部分很少,CPU利用率自然就低。但无论CPU的利用率是高是低,跟后面有多少任务在排队没有必然关系。

CPU数量和CPU核心数(即内核数)都会影响到CPU负载,因为任务最终是要分配到CPU核心去处理的。两块CPU要比一块CPU好,双核要比单核好。因此,我们需要记住,除去CPU性能上的差异,CPU负载是基于内核数来计算的,即“有多少内核,即有多少负载”,如单核最好不要超过100%,也就是负载为1.00,如此类推。

Linux里有一个/proc目录,存放的是当前运行系统的虚拟映射,其中有一个文件为cpuinfo,这个文件里存放着CPU的信息。/proc/cpuinfo文件按逻辑CPU而非真实CPU分段落显示信息,每个逻辑CPU的信息占用一个段落,第一个逻辑CPU标识从0开始。

要理解该文件中的CPU信息,有几个相关的概念要知道,如:processor表示逻辑CPU的标识、model name表示真实CPU的型号信息、physical id表示真实CPU和标识、cpu cores表示真实CPU的内核数等等。

逻辑CPU的描述:现在的服务器一般都使用了“超线程”(Hyper-Threading,简称HT)技术来提高CPU的性能。超线程技术是在一颗CPU同时执行多个程序而共同分享一颗CPU内的资源,理论上要像两颗CPU一样在同一时间执行两个线程。虽然采用超线程技术能同时执行两个线程,但它并不象两个真正的CPU那样,每各CPU都具有独立的资源。当两个线程都同时需要某一个资源时,其中一个要暂时停止,并让出资源,直到这些资源闲置后才能继续。因此超线程的性能并不等于两颗CPU的性能。具有超线程技术的CPU还有一些其它方面的限制。

五、CPU负载率的计算方式

Load average的概念源自UNIX系统,虽然各家的公式不尽相同,但都是用于衡量正在使用CPU的进行数量和正在等待CPU的进程数量,一句话就是runable processes的数量。所以Load average可以作为CPU瓶颈的参考指标,如果大于CPU的数量,说明CPU可能不够用了。

但是,在Linux上有点差异!

Linux上的load average除了包括正在使用CPU的进程数量和正在等待CPU的进程数量之外,还包括uninterruptible sleep的进程数量。通常等待IO设备、等待网络的时候,进程会处于uninterruptible sleep状态。Linux设计者的逻辑是,uninterruptible sleep应该都是很短暂的,很快就会恢复运行,所以被等同于runnable。然而uninterruptible sleep即使再短暂也是sleep,何况现实世界中uninterruptible sleep未必很短暂,大量的、或长时间的uninterruptible sleep通常意味着IO设备遇到了瓶颈。众所周知,sleep状态的进程是不需要CPU的,即使所有的CPU都空闲,正在sleep的进程也是运行不了的,所以sleep进程的数量绝对不适合用作衡量CPU负载的指标,Linux把uninterruptible sleep进程算进load average的做法直接颠覆了load average的本来意义。所以在Linux系统上,load average这个指标基本失去了作用,因为你不知道它代表什么意思,当看到load average很高的时候,你不知道是runnable进程太多还是uninterruptible sleep进程太多,也就无法判断是CPU不够用还是IO设备有瓶颈。

从另一个方面来说,也就可以解释为什么磁盘慢时(大量磁盘使用时),CPU负载会飙高了。基本上我碰到CPU负载高的情况就两种情况:CPU本身处理太多任务,再加上软中断和上下文切换太频繁导致负载高;再就是磁盘太慢导致了不可中断睡眠太多导致CPU负载高。

原理:http://linuxperf.com/?p=176


如果您觉得本站对你有帮助,那么可以支付宝扫码捐助以帮助本站更好地发展,在此谢过。
喜欢 (0)
[资助本站您就扫码 谢谢]
分享 (0)

您必须 登录 才能发表评论!