Slashdot Mirror
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
When using 'nice' try the -666 option to enable the evil bit. Hilarity will ensue.
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)
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.
"mount nice man" doesn't sound like my cup of tea.