古董命令nice/renice

一开始学习Linux时,曾经有个不是太常用但非常好听好记的命令叫做nice。这个命令允许用户通过不同的优先级启动一个程序。而且作为一条通用命令,在各种Linux和Unix发行版中都有相同的命令。此外,还有对应的另一条命令叫做renice,简单粗暴的说这命令就是为一个已经在执行中的命令修改优先级。

如果你用过top,默认就会在比较靠前的位置看到NI列,指的就是该进程的nice等级。一般设定上默认的程序会用nice=0来启动;当nice>0,最大19时则认为该进程的优先级较低,系统在调度的时候将会为其分配更少的时间片;反之nice<0,最小-20的情况下,系统将视其为高优先进程,分配更多的时间片。

从时间片分配的角度来说,这种优先级的调度是没有任何漏洞的——CPU时间决定了CPU资源,获得越多CPU资源的进程将会更快的完成任务。

然而,当前的硬件架构设计却让这个命令无所适从。可以简单在一台“比较新”的主机上用不同的nice等级做压力测试,得出的差异往往直接被当成误差忽略掉。

这种调度方式往往只在多个进程之间发生CPU争抢,且CPU吃紧的情况下才会产生显著的区别。单CPU时代这种情况会经常发生,但对于SMP架构来说,系统往往会在多个核心之间平摊负载,多个进程可以相安无事地在多个CPU上执行,系统会尽可能的避免CPU争抢。

Benchmark类的任务尽管很重,但为了测试的公平和一致,往往不会有意的造成争抢,况且对于当下的硬件环境来说,系统进程的额外开销可谓是微乎其微的。当然如果要有意重现这种nice级别带来的差异的话,你不妨限定CPU的核心数量,并在大量进程内进行IO操作,那效果将会非常明显。

对于传统的nice/renice命令来说,更为简单也更为现代化的方式是通过同为内核态实现的cgroup中cpu,cpuset组来进行限制。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

请补全下列算式: *

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据