Linux进程:CPU密集型程序问题[Bash Shell]

时间:2012-04-09 14:05:01

标签: bash operating-system process

我正在尝试查看有关Linux中进程的一些内容,我有一些问题希望您能为我解答。

我做了这个小程序,看看它是如何起作用的:

#!/bin/bash
count=1
while [ true ]
do
  echo "Counter $count "
  count=$(( $count + 1 ))
done

只是无限循环

现在,当我执行程序并在shell中使用top命令时,该进程就是消耗更多CPU资源的进程:

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND   
4037 lola    20   0  16880 1248 1028 R   80  0.0   0:33.42 memoryleak.sh  

我让程序运行一段时间,但从未超过85%的CPU消耗,为什么会这样?我想这是OP的卫生机制,但是,如果真相,这是要决定的参数。更重要的是,计数器仍然有效,而且,对于我所看到的,仍然可以 ad infinitum 为什么CPU密集型程序不会导致CPU崩溃?

现在,如果我中断了流程 - 发送 STOP 信号 - 并执行ps aux我得到:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
lola       3896 24.4  0.0  16880  1248 pts/3    T    09:15   0:37 /bin/bash ./cpukilla.sh

为什么在停止进程后,CPU消耗仍为24%?不应该为零?

任何帮助都将不胜感激。

编辑:好吧,抱歉内存泄漏术语的“混乱”。从来没有,它在技术上不会是内存泄漏,因为计数消耗大量内存而不释放它?

3 个答案:

答案 0 :(得分:2)

如果它永远不会超过CPU的85%,那是因为操作系统有其他事情调用其资源。很多进程都在多任务系统上运行,操作系统的工作就是让它们都能很好地运行。

事实上,在Linux下(对于一个),如果你的过程始终使用其整个时间片(即,不提前放弃),其优先级将被降级为“惩罚”。

CPU密集型程序不会崩溃操作系统只是因为操作系统知道如何保护自己不受这些恶作剧的影响: - )

至于24%的数字,我不确定。 可能该数字是基于程序的生命周期而不是最后几秒,在这种情况下,它会逐渐减少(相隔10秒的一系列ps -aux语句将证实或破坏该数字理论上,前者如果不断减少,后者如果再次跳起来的话。)

该手册页没有提供关于%cpu实际代表的内容的批次,但确实说:

  

CPU使用率目前表示为在流程的整个生命周期中运行所花费的时间百分比。这不是理想的,并且它不符合ps否则符合的标准。 CPU使用率不太可能达到100%。

可以读取为在一段时间内计算的数字,而不是(例如,最后五分钟)而不是瞬时(最后一秒)。

答案 1 :(得分:1)

首先,这根本不会导致内存泄漏。也许你错了“内存泄漏”与另一个概念。内存泄漏是指分配内存并无法释放内存。在这里,你没有直接分配的任何记忆

  1. 内核为每个进程预留时间,因此没有人会“挨饿”,特别是对自己而言,所以它可以安排一切正常(顺便说一句,这样的脚本会崩溃Windows'98,例如多任务执行不力)
  2. 为什么CPU会崩溃?这个问题毫无意义。它可以 ad无限,是的。
  3. It is not running(感谢geekosaur)

答案 2 :(得分:1)

通常,内存泄漏是指一种情况,其中一块存储器被分配给一个程序,并且(通常由于编程错误),该程序在完成时不会释放该存储器。实际上,这里的bash脚本没有内存泄漏。

操作系统将阻止进程100%控制CPU。 Linux是一种先发制人的多任务系统;它永远不会放弃对CPU的控制。调度程序确保所有需要CPU时间片的进程都获得一个。以下是Linux调度程序的更多信息: http://www.ibm.com/developerworks/linux/library/l-scheduler/

发送STOP信号不会终止该过程;它只会暂停它。发送SIGCONT让它继续。如果您终止它,它将从您的进程列表中删除。