On Wed, 21 Jun 2006 19:30:55 +0200
gregor herrmann <[EMAIL PROTECTED]> wrote:
> On Wed, 21 Jun 2006 10:43:52 -0400, A. Costa wrote:
>
> Thanks for your bugreport!
You're very welcome, thanks for the "bug"! Joking... that should
be: thanks for the '.deb' package!
> > Suppose the user wants to put the brakes on the command 'foo
> > --cpuhog'. Can 'cpulimit' do that?
>
> Good question ;-)
>
> > It's clear from 'man cpulimit' that this is OK:
> > % cpulimit foo 50
>
> No, that does not work. The syntax is:
> $ cpulimit TARGET [OPTIONS...]
> with TARGET in (one of) -p, -e, or -P, and OPTIONS in -l (mandatory)
> and some other.
Egad, you're completely right, and I'm trying to figure out how I got
the idea that 'cpulimit' doubled as a command launcher. Just reread
the man page, the package description, the whatis line, guess I thought
'process' meant program. But now I know what it really means so it
looks "normal", and my first reading seems stupid.
Maybe because I'm too used to 'trickle', which is an online bandwidth
limiter, which works as a launcher:
trickle -2 apt-get install some.ten.meg.package
...that runs 'apt-get' and cuts it down to around 2K/second for the
resulting monster download, so you can still browse the web in the
foreground. On a dialup that sort of thing helps.
> { useful examples deleted }
> Conclusion:
> * Bad news: "centericq --no-xtitles" cannot be limited
> * Good news: the process _is_ limited by giving only the executable's
> name, or the full path, or the PID.
> * In fact that's how the man page describes the behaviour.
Thanks for the tips, the scales have fallen from my eyes, it all makes
sense; not a command launcher, but an limiter for already running
processes. Also, this program is quite useful. For example, good old
'trickle' is a slow pig on dialup! 'cpulimit' slows it down much
better than renicing, and yet 'trickle' still works fine.
> So I don't think the man page needs any changes but if you have a
> suggestion I'll consider it of course.
> (Maybe adding "(without any argument)" to the -e and -P options might
> be helpful indeed.)
So now I know my reading was in error, but I have a feeling that
it might well be an error that other erring readers also might be
prone to making. Therefore an example in the man page seems like a good
way to prevent this.
While the examples you gave helped me, they could be improved by
showing start to finish something a user can do. For that, we need a
standard Debian program that's able to become a CPU hog -- having to
install some arbitrary bandwidth eater just to run a demo would be a
hassle. Hmmm. 'gzip' is required.
Become 'root'.
Run this sure-fire CPU waster:
gzip -9 </dev/zero >/dev/null &
Observe the CPUs go up in gkrellm or something like it...
...it'd be nice if there was a good command line method of showing
how much CPU the command is eating. 'ps' works at first:
ps -C gzip o cmd,%cpu,pid,ni
CMD %CPU PID NI
gzip -9 89.5 24953 0
...but then when you run 'cpulimit' the above 'ps' line doesn't
show the same results that 'grellm', 'top', et al do:
% cpulimit -p 24953 -l 10 &
% ps -C gzip o cmd,%cpu,pid,ni
CMD %CPU PID NI
gzip -9 71.7 24953 0
So to make the above example better, what's needed is a basic command
line function that shows the true average speed of 'gzip'. Where does
'top' get its CPU% from, somewhere in '/proc' maybe? Help.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
