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
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
Ah, yes, the extremely bad idea of running updatedb at low priority surfaces again. Then, instead of finishing during the early morning hours, it lasts all day, interferring with real work. Yes, this is what really happens: we tried this quite a while ago in Debian, and it's a Bad Idea(tm). What happens, IIRC, is that updatedb gets CPU so rarely that other tasks end up flushing the file buffers, and updatedb has to re-read the disk, over and over.
If the problem is that your system isn't on all the time, and anacron is running updatedb when you log in, then just disable updatedb. You probably never use 'locate' anyway.
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.
Please, for the love of all that's holy and Unixy, teach yourselves what a SIGCHLD is and how to use wait(2).
In the course of every project, it will become necessary to shoot the scientists and begin production.
A good [Linux] scheduler already does process restart immediately upon unblocking to reduce latency.
But an overloaded box is still overloaded. The question is how you want it to fail. In what direction? A little cron job watching load with a shedding/restart list probably does better.
For Mac OS X users trying out the commands in the article, you need to type the following to get the list of processes as shown in the article:
ps -ax -o pid,state,nice,command | less -5Also, on a standard Mac OS X system, the updatedb command to update the locate database is run by cron from the 500.weekly script located in /etc/periodic/weekly/.
The future is in beta