Nice Performance Tuning For UNIX
Professor writes "Be 'nice' to your computers and examine some general guidelines for tuning server performance. A computer is like an employee who does tasks for you -- it's a good idea to keep from overburdening them. Keep this from happening by using the UNIX 'nice' command."
Set 'em all to -19, and let the best program win! If they don't have to fight each other for CPU cycles they will grow up weak and feeble.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
nice -19 -n doFirstPost
i'll surely get first post this way!!!
"Facts are meaningless. You could use facts to prove anything that's even remotely true." - Homer Simpson
Performance tuning means that IO and other resources are sufficient to run tasks. The 'nice' command isn't that. 'nice' lets you run jobs whose complete time can vary, since you can put them on the bottom of the list.
/proc, and matching file and FS parameters with your page size.
Performance tuning is fiddling with
This is a non-article.
I want to delete my account but Slashdot doesn't allow it.
When using 'nice' try the -666 option to enable the evil bit. Hilarity will ensue.
Now here's a fun thing to do: rip a DVD with several programs at once, all at nice -19 at you suggest, and encode it to XVid and DivX and Theora all at once for good measure.
Watch the DVD drive churn and seek and gasp!
Watch the encoders fight for CPU time with top open in a terminal window!
Run some unnecessary I/O-bound process like updatedb in the background so that the hard drive can get in on the thrashing!
Wheeee! What fun...
My bicyles
FTFA: "In fact, only the ps command was running when I generated this list. Most tasks are designed to do what they need to do quickly and then exit or sleep."
/proc/self for a while.
Of course, because all other processes, at the instant PS was running, were blocking on the CPU. In other words, on a uniprocessor system, you can only have one process running at a time, and in the case of a process that reports the state of other processes, its only THAT PROCESS THAT WILL APPEAR RUNNING...
Go play in
-- (appended to the end of comments you post, 120 chars)
Yep
In arch/i386/kernel/signal.c [2.6.17-rc1-mm2]
LL
The above post refers to the killall from the psmisc package.
The Sun Solaris "killall" command kills *all* processes.
AIX "killall" kills all processes (except those in its family tree) owned by the calling user (maybe owned by the calling user *and* attached to the current terminal...).
I used to work at NASA/GSFC, and one of the workstations there sat all day running periodic housekeeping tasks from cron -- parsing telemetry, handling command load updates, etc. The problem was that every once in a while something would stall and the next batch of cron jobs would launch before the first ones completed. Instant snowballing death would ensue as nothing completed and the load average would soar into the hundreds as cron maniacally, stupidly spawned more and more processes into the poor overloaded workstation.
There are several relevant tools available now but then I wrote my own - a perl script called "qproc" that would queue up jobs for execution, kill them if they hung too long, and refrain from launching multiple copies of the same job at the same time.
Until I got hit by that, I never thought about the fact that cron is very dangerous to use on a production server. But it is -- if cron tasks use a non-infinitesimal part of the computer, you have to take steps to prevent the same marching-broomsticks failure mode.
In short : nice doesn't change the total amount of time your processes take (or, at least, not by very much), it just changes which one finishes first.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.