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
You don't need the nice utility.
Some "R" stickers along the side, a huge wing on top of the box, and replacing the sound card with a fart can is all you need to tune your server.
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.
There are two keys to efficient server tuning. One, build the server with the capability to run at least 3 times as much as you need right now. Then kill -9 any process that slows your watching the p0rn filter go nuts during lunch and breaks. Who really needs a freaking relational database engine anyway? The accounting department can kiss off, you have blackmail to collect.
No animals were harmed in the making of this sig.
Well, there was that one puppy, but he is all better now.
I just don't get the whole submission thing here sometimes. My submission on the value of tr got rejected!
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.
I use it on my own system all the time. I've got a dual processor Mac, but once in a while I have too many things running in the background (encoding a movie, analyzing my data in Matlab, etc) and want to keep manipulating some images in the foreground, so I set Quicktime and Matlab and whatever else to -19 priority. They still finish, but when I need the processor to open/close/resize/apply a filter to my image, it takes it and then lets the rest work on the past stuff. I find that it can greatly increase the amount I get done in a day and makes my Mac feel as fast as it is when I'm not doing anything else.
I also tend to increase the priority on httpd processes on the same Mac since I host my website from it. It doesn't take much CPU time, but when a request comes in, I want it to respond as quickly as possible, so if I'm doing a lot, it will give priority to it.
Also, Boinc (the grid client for distributed computing) always sets all the jobs to -19 when they are run. I barely even notice if they are running in the background.
Does anyone know why lower numbers give higher priority? Isn't it more intuitive to use higher numbers for higher priority? I'm curious as to why it was done this way...
Is Ric Romero taking notes on this article?
This is really rather simple. Let's say you have a number, X. What comes before X? X-1. And what comes before that? X-2.
So, now with that out of the way, let's say you want to iterate all numbers. Most sane people would start at either the beginning(low value) or the end(high value). And probably most would start at the beginning.
When walking the list of things to run, a simple scheduler would act on the first thing it finds. This means that something that existed lower in this list would be run more often than something that existed later. So, that means that lower priority number actually means run more often.
Anyone know the historic reason why negative numbers are used for processes with HIGHER priority? It's counterintuitive and everything that's not *nix-like does it differently.
Nice values measure how nice your programs are. Being nice means it gets out of the way for other programs. So a program with a nice value of 10 is nicer than that with a nice value of 0 and will get out of the way.
We could do it the other way around and have a 'mean' program that assigns 'mean' values to programs which then hog the CPU. But only the super user would be able to assign positive values.
Give me Classic Slashdot or give me death!
A computer is like an employee who does tasks for you -- it's a good idea to keep from overburdening them.
Don't I already pay this hunk of junk enough in electricity and bandwidth to keep it from slacking off? If it isn't willing to constantly pull more weight, for the greater success, what am I keeping it on for?
Terrorists can attack freedom, but only Congress can destroy it.
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
Its also very helpful to run Apache at nice level 5. That way when the CGI programs go nuts and the load shoots up to 200 the sshd process won't get starved for CPU time and you can still log in to fix the server.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.