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."

Comments

Scheduling Priority is for sissys

[SatanicPuppy]

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.

Re:Scheduling Priority is for sissys

[Gothmolly]

If they're lucky, they'll get placed on the game grid, where they'll use futuristic "light cycles" and weird jai-lai pelotas to battle for supremacy.

Re:Scheduling Priority is for sissys

[moro_666]

i use nice a lot, and also renice afterwards when something goes kindof out of hands, too bad the powernowd needs to be disabled to let the machine run at full speed but process still at a nice priority ...

  is there a similar option for kernel modules ? some kind of scheduling trick ? the vmplayer from vmware is quite nice, but with it's kernel module it totally annihilates the rest of your linux, and renice'ing the vmware's process itself doesn't really have an effect, since the kernel module is what makes the load...

Re:Scheduling Priority is for sissys

[eviloverlordx]

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.

Fight! Fight! Fight!

Re:Scheduling Priority is for sissys

[hackstraw]

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.

Very funny. Its like when I'm talking to people that believe in heaven and hell, I just say "Kill 'em all and let God sort them out!"

But back on the topic. Err, I'm new to UNIX/Linux, I've only been using it since 1993, but nice and getpriority() setpriority() and scheduling have been around for a _long_ time.

Debian launches services via the start-stop-daemon program that has the -N|--nicelevel option. RedHat has a function called daemon() in /etc/init.d/functions that takes a nice argument.

In other words, I'm not impressed with the IBM article or with slashdot for printing this. Oh, and the slocate cron job in most Linux distros has been niced to -19 for years. I guess copying and pasting the contents of the cron script is helpful for people that don't have access to a Linux box. Next week, they are going to HTMLize the kernel source for those that can't download that either.

I hate being negative here, but what is the target audience for the IBM article and this slashdot reprinting of it?

Re:Scheduling Priority is for sissys

[SatanicPuppy]

I hardly ever use nice...Usually only to de-prioritize some job that isn't playing well with others, so you're nice-knowledge is bound to be superior to my own.

Re:Scheduling Priority is for sissys

[SatanicPuppy]

I don't know, I mean, it's kind of nice for some reasons, though I agree, nice is ancient. There is so much in Unix though, that I don't mind occasional articles about semi-obscure commands, and nice is obscure for a lot of people...I can't count the number of times I've had people bring up "irreconcilable" job scheduling to me, that can easily be solved with nice...So I think refresher articles are a good thing; occasionally I learn something.

Re:Scheduling Priority is for sissys

[Alwin Henseler]

(responding to subject line)

Not a true hardcore geek, are you? PYG (Pretty Young Girl(s)) requesting some sort of intimacy/sex/pubic hair shave job always get top priority on my schedule, no matter what user caused the request.

F**k that dayjob or afternoon shopping trip when the opportunity of your lifetime comes along.

Re:Scheduling Priority is for sissys

[hackstraw]

I don't mind refresher stuff either, but UNIX was designed from the beginning to be multi-user and multi-tasking. The top command has a nice column. The manpage for top says:

The nice value of the task. A negative nice value means higher priority, whereas a positive nice value means lower priority. Zero in this field simply means priority will not be adjusted in determining a task's dispatchability.

nice, and renice are common commands for dealing with running processes. top can renice a process as well, which is very handy being that its usually the top process displayed in top that you want to increase or decrease its priority.

If any of this is new to anybody, then they cannot put UNIX or Linux on their resume. BTW, I'm looking for a job. Anybody want a BOFH that knows his stuff?

Re:Scheduling Priority is for sissys

[Jim_Maryland]

I haven't used it recently too but at one point, I used it quite often. Back in the mid to late 90's when ESRI's ArcInfo software ran on UNIX systems, I was used to do a fair amount of GIS processing on datasets. Generally I was pulling together tiled data into a single dataset or doing some spatial data checks that took a while so I would either lower other users priorities or increase mine (I also was the SA for most of these jobs too). Most of the other users on the system were pretty much just data collectors (digitizing tables or on screen and assigning attributes) that weren't tasking the system much anyways.

Lately I've found that the systems I work with are pretty high end so I haven't found the need to alter priorities often. When systems at work range from 2CPUs and 4GB of RAM TO 4 CPUs with 32 GB of RAM, most things aren't tasking the system too heavily.

Re:Scheduling Priority is for sissys

[SeeMyNuts!]

"Usually only to de-prioritize some job that isn't playing well with others"

Once, while in college, I was sitting in the Solaris lab wondering why every workstation was slow as molasses. It quickly became apparent that an over-enthusiastic EE major was using every workstation in a cluster to do his bidding. He was not being 'nice' at all :(

Re:Scheduling Priority is for sissys

[mrhartwig]

I'm new to UNIX/Linux, I've only been using it since 1993....

Considering that half of the /. population wasn't even reading in 1993, I think that allows you to drop your "new" classification.

Re:Scheduling Priority is for sissys

[operagost]

Come on, kids-- fight nice!

Re:Scheduling Priority is for sissys

[dlZ]

I'm new to UNIX/Linux, I've only been using it since 1993....

Considering that half of the /. population wasn't even reading in 1993, I think that allows you to drop your "new" classification.

I consider myself pretty "new" to the UNIX/Linux world, too, and I've been using some variation since 1993. I'll stop considering myself new when I can remember every command ;)

Re:Scheduling Priority is for sissys

[kimvette]

I'll stop considering myself new when I can remember every command ;)

By that standard everyone is a *nix newbie.

Re:Scheduling Priority is for sissys

[hackstraw]

I consider myself pretty "new" to the UNIX/Linux world, too, and I've been using some variation since 1993. I'll stop considering myself new when I can remember every command ;)

While we are on the topic, is there a market for a slashdot style site that is more geared for computer professionals?

Slashdot has a very smart userbase, and I would not abandon slashdot, but I would like to get away from the highschool and undergrad "know it all" people. Articles like this one are way below anyone who does Linux or UNIX professionally, and when I mention things like this the /. moderators slap me with an overrated moderation.

I'm serious, would there be a target audience of professionals that would like a website geared for them? Does one already exist that I don't know about that has active readers and interactive discussions?

Re:Scheduling Priority is for sissys

[dlZ]

While we are on the topic, is there a market for a slashdot style site that is more geared for computer professionals?

Slashdot has a very smart userbase, and I would not abandon slashdot, but I would like to get away from the highschool and undergrad "know it all" people. Articles like this one are way below anyone who does Linux or UNIX professionally, and when I mention things like this the /. moderators slap me with an overrated moderation.

I'm serious, would there be a target audience of professionals that would like a website geared for them? Does one already exist that I don't know about that has active readers and interactive discussions?

I don't know of one, either. I wouldn't stop reading /. but something a bit more professional away from the sophmoric attitude of many of the "younger" /. crowd would be great. And I don't mean just younger in age or ID. Sometimes it can be amusing, but you're right, the chances your comment, and now mine, will get slapped down as overrated or trolls.

It's really going to come down to someone creating it. But the problem is actually getting the users over there, while not allowing the same things to happen. It's a thin line to walk if you don't want to censor but at the same time want to keep the immaturity down. I know that's what the moderation system is for here, but maybe just having users with a different mind set and attitude would make all the difference.

Re:Scheduling Priority is for sissys

[cortana]

For Linux news, LWN; for general tech/sci news, Technocrat.

Slashdot has a *lot* more users than either though. Although some times it can seem otherwise, the good comments can show though... you just need to browse at +4 and ignore anything posted = 25 minutes after a story is posted. :)

Re:Scheduling Priority is for sissys

[karnal]

That sounds like some sort of AI game to play.

Have all of the apps be aware of their nice levels, and strive to bring their nice levels up. However, they can't adjust their own nice levels, but they can adjust other apps nice levels....

Put in other limitations as well, so it doesn't just throw everything out the window. As in, the top niced program can't be reniced until it's not the top niced program anymore... and every time you nice an app, another app at random automatically loses niceness..

Would be interesting to see, for about 5 seconds....

Re:Scheduling Priority is for sissys

[hackstraw]

Slashdot has a *lot* more users than either though. Although some times it can seem otherwise, the good comments can show though... you just need to browse at +4 and ignore anything posted = 25 minutes after a story is posted. :)

Hey, I browse at +4 already. 90% of my foes are those MMLM people with "free" iPods in their sigs. That has gotten rid of most of the college kids. I'm a subscriber and give bonus points to friends, friend of friends, interesting, informative, yada yada. I've been reading slashdot before it was slashdot, AKA chips and dips. I really like slashdot for the discussions. I wish that there was a more professional side to it. Personally, this topic about nice is way too low for me. I would love to see discussions about software trends, especially things like learning software, cool new APIs or libraries or things like memcached which drives slashdot and other high volume DB based sites. I've used memcached successfully and really like it. I would like to see Linux topics like about the preemptive kernel patches. I like the MySQL/PostgreSQL/Oracle debates, but even those are not lead by very informed people. Basically, I would like a more experienced, professional twist to the discussions. I guess the saying that "Knowledge shared is power lost" is true. The people that know keep it to themselves, while the people that know next to nothing will tell you all about it, with confidence and conviction, yet no working experience is behind the wisdom.

Re:Scheduling Priority is for sissys

[Danny Rathjens]

Not websites, which is a poor meidum for discussion anyway, but mailing lists and usenet and irc all still work fine; albeit with more necessary filters and moderation than was the case a decade ago when the net was mostly we science and computer geeks. ;)

Re:Scheduling Priority is for sissys

[Artifex]

I would love to see discussions about software trends, especially things like learning software, cool new APIs or libraries or things like memcached [danga.com] which drives slashdot and other high volume DB based sites. I've used memcached successfully and really like it. I would like to see Linux topics like about the preemptive kernel patches. I like the MySQL/PostgreSQL/Oracle debates, but even those are not lead by very informed people. Basically, I would like a more experienced, professional twist to the discussions.

So what's your submission history look like?

If you want a higher level of discussion, sometimes you have to start it yourself. Write an article about your memcached adventures and submit it. Ask slashdot about those patches -- are they right for you? Please, though, pass over the db debates. :)

Be part of the signal, instead of complaining about the noise. :)

p.s.

I've been reading slashdot before it was slashdot

Haven't we all? :) Just kidding.

Re:Scheduling Priority is for sissys

[cloudmaster]

Unfortunately, with sites like that, you still end up eventually attracting the "I've installed two distros of Linux, now I'm teh Unix g0d!" kind of people, and they're almost always prolific posters. I follow things like the Postfix mailing list, and there are some people up there who truly do have the mad SMTP skillz, but there's a *lot* of "how do I do something that's in the docuemntation and asked weekly" posts as well.

The solution isn't to somehow ban those people, it's to develop the ability to quickly identify them for ignoring. Slashdot's good with the friend+1/foe-1 thing, and a lot of forum software has "ignore user" capability. But it comes down to simply developing the ability to quickly scan and identify things that warrent further investigation. Unfortunately.

BTW, I've never seen the ads in .sigs. Probably because I turned off viewing of signatures several years ago. :) Now if I could just find a way to erase the .sigs that people are apparently inserting to their comment with some kind of javascript/greasemonkey kind of thing...

what about killall

[bhalter80]

I guess once you've given nice a shot you could move on to killall -KILL 1. That'll show any misbehaving system who's boss.

Re:what about killall

[LLuthor]

Umm. You can't sigkill init on Linux (at least on moderately recent kernels). I am pretty sure that is also the case on BSD systems.

Yep ...
In arch/i386/kernel/signal.c [2.6.17-rc1-mm2]

563 /*
564 * Note that 'init' is a special process: it doesn't get signals it doesn't
565 * want to handle. Thus you cannot kill init even with a SIGKILL even by
566 * mistake.
567 */
568 static void fastcall do_signal(struct pt_regs *regs)

Re:what about killall

[Stradenko]

Not to mention that "killall -KILL 1" would kill processes named "1", as opposed to the process with the PID "1".

Re:what about killall

[hackstraw]

On a related note, I installed Ubuntu yesterday, and I wanted to use it as a headless box, so I monkeyed with /etc/inittab to try and put it in a runlevel that only provided getty logins and remote logins.

After monkeying with it, I did the standard telinit q to make init reread its config file. Well, telinit q told init to just kill all running processes. Nice feature.

Ubuntu might be OK for a novice who wants to say that they run Linux, but it is not a distro geared for professional use.

Re:what about killall

[Stradenko]

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...).

Re:what about killall

[coaxeus]

this article is about linux ?

Re:what about killall

[Luyseyal]

Short answer: File a bug.

Long answer: I'm on Debian, so I'm not 100% sure if Ubuntu uses the same sysvinit package, but, I did check it out and 'telinit q' and its manpage both agree on rereading inittab. So, I'd look into filing a bug.

-l

Re:what about killall

[fossa]

What exactly the purpose of Sun's killall? I'm sure it's useful to someone, but from here I have no idea why anyone would want to use it...?

Re:what about killall

[Amouth]

kill -9 init alwasy works :) well that is if you want something bad to happen

Re:what about killall

[Anonymous Coward]

You can, however, do this:

xxx ~ # kill -SEGV 1; tail -1 /var/log/messages
Apr 12 12:27:58 xxx init: PANIC: segmentation violation at 0xb7f54872! sleeping for 30 seconds. :-)

Re:what about killall

[Stradenko]

From the man page: killall is used by shutdown(1M) to kill all active processes not directly related to the shutdown procedure.

but yeah, it's probably not something joe user would want to use (the man page says only super-users can use it, but it's set mode 755 ... I assume there's some check in the code)

Re:what about killall

[nuzak]

> kill -9 init alwasy works :) well that is if you want something bad to happen

If you consider "nothing at all" to be "something bad".

In fact there's bunches of processes that are unkillable. Such as any kernel thread.

Re:what about killall

[Anonymous Coward]

> Umm. You can't sigkill init on Linux (at least on
> moderately recent kernels). I am pretty sure that is also
> the case on BSD systems.

not true, from FreeBSD's /sbin/shutdown:

    (void)kill(1, doreboot ? SIGINT : /* reboot */
                                dohalt ? SIGUSR1 : /* halt */
                                dopower ? SIGUSR2 : /* power-down */
                                SIGTERM); /* single-user */

Re:what about killall

[Abalamahalamatandra]

If it's 755, users can execute it, but if they don't have root, trying to send signals to processes they don't own is going to be rather futile. I would imagine it would send signals to their own processes, though, so it would act like a personal killall.

Re:what about killall

[myzz]

The right way to do this on linux is:

kill -9 -1

Re:what about killall

[Anonymous Coward]

Actually, under solaris 10, init exists but it does'nt get used anymore thanks to the service management framework.
You can kill off init in the kernel debugger and dead processes still get taken care of.

Re:what about killall

[makomk]

Sounds like a rough equivalent to the Linux command killall5 ("sends a signal to all processes except kernel threads and the processes in its own session")...

Re:what about killall

[Amouth]

you can kill init.. your computer jsut flat out stops but you can kill it

Re:what about killall

[wtarreau]

He did not say he wanted to kill init, but a process named "1" :

      killall -KILL 1

willy

Re:what about killall

[caluml]

The Sun Solaris "killall" command kills *all* processes.

Yep. Found that out the hard way. killall httpd on Solaris does not do quite what you think.

Stupid lame Sun. Why can't they stick to the right way of doing things. Linux has been around for much longer than them, so they should damn well stick to the standards.*



* Please don't feed me.

Re:what about killall

[Anonymous Coward]

Fedora Core 4, vanilla 2.6.16.2 kernel, and init is unkillable:

[root@localhost ~]# killall -s KILL init
[root@localhost ~]# ps aux | grep init
root 1 0.0 0.0 1748 448 ? S 08:47 0:00 init [5]

Re:what about killall

[Amouth]

well alteast in slackware it is killable

First Post?

[bje2]

nice -19 -n doFirstPost

i'll surely get first post this way!!!

Re:First Post?

[Bobke]

You would have made it, if only you had typed "nice -n 19 doFirstPost".

Tip: put

alias nicest="nice -n 19"

into your .bashrc or .zshrc or whatever, and make sure you'll get it next time.

Next up: "man nice" "man man" "man mount" ?

[Gothmolly]

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.

Performance tuning is fiddling with /proc, and matching file and FS parameters with your page size.

This is a non-article.

Re:Next up: "man nice" "man man" "man mount" ?

[eln]

Whoa whoa whoa, slow down. First I learn there's a "nice" command, and now you're telling me there's a "man" command too? This is way too much information for one day.

Re:Next up: "man nice" "man man" "man mount" ?

[SatanicPuppy]

One of the things I don't like about nice is that people often use it to baby weak code. Some joker writes the world most inefficient Perl script, and then, because it takes forever to run, uses nice to give it a higher priority than it deserves, thus cutting it's runtime down to an acceptable time, rather than just fixing the damn code. I hardly ever see anyone use it nicely (har har), setting a non-critical job to run at a lower priority.

So I'm always suspicious when I see nice used. I really prefer to just schedule more intelligently, so things don't overlap as much, and running daemons that hog cycles 24/7 on their own hardware.

Re:Next up: "man nice" "man man" "man mount" ?

[maxwell demon]

Whoa whoa whoa, slow down. First I learn there's a "nice" command, and now you're telling me there's a "man" command too? This is way too much information for one day.

Obviously it is. Otherwise you would have noted that he told you about the mount command as well. :-)

Re:Next up: "man nice" "man man" "man mount" ?

[TheRaven64]

From what I recall, the O(1) scheduler in Linux doesn't properly interact with nice anyway (i.e. the difference between a extreme ends of the nice scale is very small). One of the design requirements for the FreeBSD ULE scheduler was that the nice scale should follow a curve which is steep at both ends.

Re:Next up: "man nice" "man man" "man mount" ?

[hackstraw]

Some joker writes the world most inefficient Perl script, and then, because it takes forever to run, uses nice to give it a higher priority than it deserves, thus cutting it's runtime down to an acceptable time, rather than just fixing the damn code.

Well, this joker has root access, because only root can increase a priority of a process.

No system I run with multiple users would have such an incompetent person that is allowed to have root access. In fact, when a user writes some broken perl script that burns a processor for days, I do a trace on the procesws to see what it is doing, kill the process and email the user to fix the code.

Yes, I'm a BOFH, and proud of it!

Re:Next up: "man nice" "man man" "man mount" ?

[Luyseyal]

If the idea of the scheduler is that the system administrator has to hand-tune all their processes with 'nice' to balance interactivity, CPU-hogging, etc., then yes, the Linux scheduler does a terrible job. However, for an untuned workload of dozens of nice = 0 processes, it works great, though.

Having said that, I do nice down my "top" processes and set the delay to at least 5 seconds. This seems to give a better idea of what's running a lot as top then uses less resources.

$0.02USD,
-l

Re:Next up: "man nice" "man man" "man mount" ?

[SatanicPuppy]

I tend to get called in when other people have already screwed things up, and that is one of the things I tend to find. Like I said, on my personal systems, I hardly ever use nice.

Re:Next up: "man nice" "man man" "man mount" ?

[wild_berry]

"mount nice man" doesn't sound like my cup of tea.

Re:Next up: "man nice" "man man" "man mount" ?

[smoker2]

I renice 10 Folding@home so that the computer is actually useable when I need it. When I'm out, it can do what it wants !

Re:Next up: "man nice" "man man" "man mount" ?

[PhilipPeake]

In the dim and distant days when programers were lazy bastards, and the 'who' command did many less things, one of the documented options was "who am i", which printed out the information for the user of the controlling terminal. It was usefull to see who the session belonged to on a logged in terminal.

Well, the lazy bastard who programmed it didn't check for arguments "am" and "i", but just checked to see if the argument count was 2, all other valid arguments being single items.

So it was sometimes amusing to find an unattended logged in terminal, type in:

      $ who screws sheep

and walk away....

Re:Next up: "man nice" "man man" "man mount" ?

[marcosdumay]

"...kill the process and email the user to fix the code."

Tanks! Now I'll need to do all that calculation again...

Re:Next up: "man nice" "man man" "man mount" ?

[Anonymous Coward]

I like the *nix guru's view of sex better:

gawk; talk; nice; date; wine; grep; touch; unzip; strip; touch; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; make mrproper; sleep

Re:Next up: "man nice" "man man" "man mount" ?

[Arandir]

fiddling with /proc

Only on Linux. /proc is a vastly different thing under other Unix systems.

Re:Next up: "man nice" "man man" "man mount" ?

[Arandir]

This isn't the dim and distant past. This is still current behavior on many Unix systems. I just tried it on my Solaris box, and what do you know? I must be part Scots!

Re:Next up: "man nice" "man man" "man mount" ?

[dodobh]

So you are the one that is killing the spam filtering daemon! Smack! Bad BOFH!

Re:Next up: "man nice" "man man" "man mount" ?

[hackstraw]

Tanks! Now I'll need to do all that calculation again...

You must be one of my users :)

No, you need to fix the application because if its burning up the filesystem and CPU unnecessarily, I will kill the process until its fixed.

Running a calculation is not something you do on a multi-user system. I can point you to 500+ dedicated processors for that. A simple perl script that is running as a daemon that is written so poorly that it opens and closes files without reading any data from them in an endless or almost endless for loop is ridiculous. I've done a trace on the script before and in about 1 minutes time it opened over 450,000 files, only about 1,000 were unique. The program was buggy, and after killing it multiple times and emailing the user to fix it, he eventually did. Next year, I'll teach the guy that sleep is a native perl function and you do not need to call system("sleep blah"). pkill -u bad_user is a godsend :)

BOFH I am.

Re:Next up: "man nice" "man man" "man mount" ?

[hackstraw]

"mount nice man" doesn't sound like my cup of tea.

Had to do it :)


while true
do
    mount /partner && strip /partner/* && (fsck -y /partner && echo god | yes; ^C^C^C); dmesg; which true >/dev/null && make love || umount /partner; umount /partner 2>/dev/null) ;
    sleep 10h
    echo "Good morning `date`"
    find / -name *meaning* -print
done


I've been using UNIX wayyyy too long.

Documentation:

mounting /partner is required for the following chain of commands:
so is stripping /partner/*
the first fsck can fail with no screenfulls of yes
which true will always succeed but the make love is not a guarantee
if make love fails, then immediately umount /partner
regardless a final umount /partner is attempted where any error will be ignored and stored in /dev/null
sleeping will happen regardless of sucessful mounting of /partner
after 10h of sleeping, "Good morning" will be printed followed by the current date

after that an attempt is made to find *meaning* on the system. Nothing will be done if *meaning* is not found, but successful findings of *meaning* will be displayed on the terminal

Disclaimer:

BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.

Here's a tip.

[Anonymous Coward]

When using 'nice' try the -666 option to enable the evil bit. Hilarity will ensue.

Re:Here's a tip.

[ppz003]

When using 'nice' try the -666 option to enable the evil bit. Hilarity will ensue.

For some reason, I read that as Hilary will ensue. Now why would you want to do that to someone?

Re:Here's a tip.

[rcamans]

When I saw 666, the evil bit and Hilarity, I immediately thought Hillary (Clinton)???

Re:Here's a tip.

[caluml]

Hey, that really works!

calum@foo ~ $ nice -666 bash
.... Entering bash666 .....

666 > ls
Bad command, Satan.
666 > help

Purge
Drown
Kill
Maim
Loot
Rape
Exfo liate

help help for more minions.
666 > ^D
calum@foo ~ $ whoami
calum
calum@foo ~ $

Have a DVD-ripping death match!

[MoxFulder]

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...

Re:Have a DVD-ripping death match!

[dpilot]

Do you complain about the lousy framerate you get playing your FPS while the rest of this is happening?

Re:Have a DVD-ripping death match!

[MoxFulder]

Actually, I don't play FPS games, which are too confusing and fast for me. I occasionally play stategy games or old Nintendo platform games. I guess I'm just the freak on slashdot. *shrug*

Re:Have a DVD-ripping death match!

[eyeball]

This brings up a good point. CPU isn't the only limited resource. I've often ran applications that saturate IO busses or network interfaces, or eat up a ton of memory, but only used a fraction of CPU time.

In the first case, a large simple parsing app or file compression/decompression can saturate an IO bus. While performing such operations, other user-sensitive tasks like opening an application or checking mail. Granted most users don't do a lot of IO-flooding apps, but what's more prevalent are network-flooding operations. Just recently, while I was downloading some linux ISOs via HTTP, my web browsing was slow the whole time. Sure QoS can help some of these issues, like putting a higher priority on Game network traffic, but probably wouldn't help web browsing while downloading large files.

It would be nice (no pun intended) to be able to restrict or throttle other resources besides CPU. i.e.:

nice -n-19 wget http://example.com/linux.iso
nice -i-19 gzip bighugefile.csv

This probably exists in Linux already.

Re:Have a DVD-ripping death match!

[MoxFulder]

Yes, that's a very good point. It would be nice if it was possible to throttle other resources in a uniform fashion.

With network bandwidth it's quite application-specific. For example I can tell Azureus (uber-featureful bittorrent client) to only use a certain amount of upload bandwidth. But I can't do this with Gaim, and when I'm sending someone a big file too fast, my web browsing grinds to a halt. It'd be handy to have a uniform way to restrict the bandwidth of apps.

Storage device accesses would be a LOT trickier IMHO. Without knowing the specifics of the device geometry and seek times etc., it's very hard to know how much of a drive's capacity is being used. As I suggested above, it's efficient to have one program read a DVD start-to-finish as fast as it can. It's *HORRIBLY* *AWFULLY* inneficient for TWO programs to do so at once (and from the sound of it, I worry that it will literally break my DVD drive :-)

Re:Have a DVD-ripping death match!

[dpilot]

I just figured as long as you're piling on all the CPU-intensive things you could think of, all at "nice -19", then why not add one more.
But I guess I'm with you, in that I'm more likely to complain about turning DVD blanks into toasters than getting fragged because my fps are too slow.

Re:Have a DVD-ripping death match!

[Anonymous Coward]

Okay, I did that. I ripped The Matrix 3 times using three different programs and running a continuous "find / -print | sort -o /dev/null" in the background.

It took 12 minutes.

Now what?

Re:Have a DVD-ripping death match!

[Anonymous Coward]

It'd be handy to have a uniform way to restrict the bandwidth of apps.

Check out trickle.

Re:Have a DVD-ripping death match!

[tkiesel]

Check out trickle for Linux/*BSD/what-have-you.

Re:Have a DVD-ripping death match!

[MoxFulder]

Well, firstly... holy crap!!! What kind of insane system do you have? My brand spankin' new AMD64 can't rip-- let alone encode --a DVD in under ~10 minutes per hour of video. I'm assuming you just ripped, not encoded, right?

And didn't your DVD drive thrash around horribly while you had three programs trying to read /dev/dvd simultaneously?

Obviously, you're doing this much smarter than I did :-P

Re:Have a DVD-ripping death match!

[petermgreen]

ever read the linux advanced routing and traffic control howto?

you should be able to throttle by port, user account and a whole manner of other things.

Re:Have a DVD-ripping death match!

[mnmn]

Well QoS has existed forever in most posix operating systems out there for network interfaces. Theres your network QoS.

Now I wonder if without using virtualization, on the command line, you could limit memory available to a process. One of the big 3 UNIXen out there probably has that.

Re:Have a DVD-ripping death match!

[KFK2]

After the first time you run the find command, almost all of the filesystem table is in ram. So nothing hits the disk after the first access; and I'm assuming you're not transcoding that video in 10 minutes just ripping, so no cpu is used. Therefore you have two processes: Sort hitting the CPU and the DVD ripping hitting the drive... neither of them are competing for resources.

Re:Have a DVD-ripping death match!

[drinkypoo]

Actually in linux (and probably just about every other Unix system out there these days) you can use the packet scheduler system to handle QoS without depending on actual QoS. You just deliver packets for some protocols immediately (or almost immediately, maybe you drive the ratio way up) and packets for other protocols when the bucket for that protocol is empty. This is about the simplest explanation of the packet scheduler possible, and probably only accurately applies to one or two of the queueing mechanisms, but to be honest I don't know much about it and I don't want to tell you something that isn't correct so I'll stop here :) You can deliver the incoming packets slowly too; when the bucket for incoming packets comes in, your system will instruct the other system to throttle back automatically without depending on QoS protocols, as long as we're talking about TCP - which we are, since you mentioned http. Your mileage will probably vary more with UDP, depending on how bright the app is about controlling transmission speed.

Re:Have a DVD-ripping death match!

[drinkypoo]

It'd be handy to have a uniform way to restrict the bandwidth of apps.

Check out trickle.

That article makes me laugh. First of all, preloading libraries is not guaranteed not to break anything. Second of all, so what if he can't attack the kernel space of the DSL modem? The solution is to put a low-end linux system in between the hosts and the modem. You can then use it for a firewall so you don't have to use firewalling on your individual systems. Anything but a few games will work through such a system - you might have to forward some ports and specify some port ranges but in general it works. Linux conveniently has modules to make some stupid protocols work (like FTP - why does it [by default] use two TCP connections? I could understand one TCP and one UDP, but two TCP? Completely stupid) so it's not as much of a problem as you might imagine.

Put a system in between to be your firewall and you can also use packet scheduling to handle the QoS without any such hacks.

Finally, the following paragraph would have made me laugh out loud if I weren't so tired right now:

Another program that I still haven't fully working the way I want to with "trickle" is bittorrent (for spreading those Linux ISOs). When I decrease the upload limit, the download speed also drops severely, even though I've not touched the download limit at all.

Yeah, you know why? Because bittorrent is designed to reward people who upload more by allowing them to download more. If you're not the only downloader, and you decrease the upload speed, the other bittorrent participants will upload less to you than to people who are uploading more than you are.

Just based on their lack of understanding of this fact, which is very well-known and -documented in most bittorrent programs, documentation, forums, et cetera, I wouldn't listen much to anything they say.

Too bad their email address isn't on the page, so I could tell them all this directly.

Re:Have a DVD-ripping death match!

[MoxFulder]

Hmmm... I don't share your sentiment.

I just downloaded trickle and it works great! Works with all my ftp, downloader, instant messenger software. Excellent. It's certainly a SIMPLE system, and you seem to think that explaining this is a major weakness. I don't think so. It works very well. Why add another box taking up space and power when this type of user-space traffic routing is so effective for so many uses.

When you need kernel traffic shaping, use it. When you really don't, trickle is almost perfect. Cause it's lightweight and a whole heck of a lot easier to understand AND to implement.

Re:Have a DVD-ripping death match!

[eyeball]

Funny, that was actually closer to my real scenario. I was BT'ing some large Linux ISOs, while downloading some large files in Safari. I was throttling Azureus traffic down to 33% of my bandwidth, but couldn't do the same with my Safari downloads. Maybe this could be implemented on a per-client basis, but what a pain for developers to have to implement their own. At the very least, throttling should be a part of the networking C libs.

Re:Have a DVD-ripping death match!

[h4ck7h3p14n37]

Storage device accesses would be a LOT trickier IMHO. Without knowing the specifics of the device geometry and seek times etc., it's very hard to know how much of a drive's capacity is being used.

Honestly, I've had to do much more disk tuning than mucking with QOS, pinning processes to CPUs, tweaking scheduling, etc.

Solaris has a nice tool called iostat that will show you reads/sec, writes/sec, kilobytes read and written/sec, wait time, avg. number of transactions being serviced, service time, percent waiting and percent busy by physical and logical (disk) device. The trick is to know what has been placed on each filesystem and what people are using. For example, if you have a local CVS repository and developer accounts on the same machine, it's a good idea to place them on separate spindles. Likewise, a relational database's data files and logs files should be placed on separate spindles to prevent contention (logs are being written at the same time that data is being accessed).

Now that I think about it, I have also done a bit of tuning wrt. primary memory. Mainly the creation of RAM disks (filesystems) via tmpfs(7FS) to speed up parsing, compilation and execution of JSPs.

I've just started doing AIX administration and that O.S. actually allows you to specify on which cylinders (inner, middle, outer, inner middle, outer middle) a filesystem is stored.

Re:Have a DVD-ripping death match!

[Bert64]

The ulimit command is what you need, you can limit the amount of memory a process or user can use, but beware, the effect of hitting the limit is the same as completely running out of memory, malloc()s will fail and the program may crash if it's not written to cope with such a situation.

Re:Have a DVD-ripping death match!

[drinkypoo]

Shaping can be hard to use, but he has multiple people in his residence. By using shaping, he could ensure that they all can do things without destroying interactive traffic (or whatever kind of traffic) for everyone else, instead of only making sure that he isn't a problem.

I got my server tuned

[Anonymous Coward]

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.

Re:I got my server tuned

[Penguinoflight]

Whoah, I just got a picture of a wing on my transparent case. You think I can get one from AEM?

Re:I got my server tuned

[Anonymous Coward]

Last time I checked AEM did engine management computers, not wings. Good obscure pimp ride reference though.

Bad teacher, no cookie!

[Fubar420]

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."

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 /proc/self for a while.

Re:Bad teacher, no cookie!

[Gothmolly]

Too bad I dont have mod points, +1 Insightful to you!

Re:Bad teacher, no cookie!

[alexhs]

Of course, on a uniprocessor system only one task can run at a time. However, (GNU) ps and (GNU) top report R as Running or Ready to Run, so there may be more than one at any time. Average of runnable tasks count get you the load.

Nota : I put the GNU because BSD equivalent behaves differently, I just checked and I get details like "select" where I guess I would only get "Sleep" on GNU/Linux.

Re:Bad teacher, no cookie!

[ultranova]

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...

Not true. "Running" as a process status doesn't mean that the process is burning CPU time right now, it means that it is in the runqueue and will round-robin with all the other running processes for the CPU time.

The opposite state, sleeping, means that the process is not currently in the runqueue because it is waiting for something - for a disk read to conclude, for some data from the network, for your keypress, or simply that some time has elapsed.

I repeat: a "running" process is one that is in the runqueue, not neccessarily being run by the CPU at this particular microsecond.

Re:Bad teacher, no cookie!

[Kadin2048]

Although the author of TFA could have been a lot more clear, in his defense he does explain this (admittedly in a roundabout way):

The scheduler maintains a number of internal tables to manage the context of every running task in the system. It also manages resources using a pair of queues known as the run queue and the sleep queue. The run queue is where tasks that have all of their resources available are held. The sleep queue is for tasks that are waiting for one or more resources to be available.

He could have been a little more clear when he was talking about interpreting the output from ps, but it's not like he completely forgot to explain the concept.

Re:Bad teacher, no cookie!

[ericbg05]

I found this one FTFA more egregious:

On my workstation, 84 lines were generated. This means that at the time the ps task was running, it was only one of 84 different tasks that were competing for time to run on the CPU.

Those 84 tasks were most certainly not competing for time to run on the CPU. If they were, they'd have been in the run queue, and their states would've been reported as R, not S.

Also:

Most of the tasks are also sleeping; that is, they are waiting for some resource to become available.

This conclusion is also not true. In fact, the correct conclusion is the opposite: those processes are listed as sleeping because they're not interested in any resources!

Worst. Advice. Ever.

[V. Mole]

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.

Re:Worst. Advice. Ever.

[gowen]

Then, instead of finishing during the early morning hours, it lasts all day, interferring with real work.

If there are no other processes competing for resources, niced and non-niced processes will complete in approximately the same time. If your niced late-night updatedb is taking forever, its because you've chosen to run other processes overnight as well. And if your updatedb runs quickly, then the other processes will "interfere with real work".

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.

Re:Worst. Advice. Ever.

[WhiteWolf666]

Is there any reason to use slocate/locate rather than have beagled index everything on your system?

I'm genuinely asking. I have no idea. But do you really need to use locate when you can use beagle-query?

Re:Worst. Advice. Ever.

[nuzak]

> Is there any reason to use slocate/locate rather than have beagled index everything on your system?

Not needing to run a bloatastic daemon and all its hundred dependencies and have to swap it in every time you want to just search for a filename?

Re:Worst. Advice. Ever.

[Black Copter Control]

In short : nice doesn't change the total amount of time your processes take

No. In the instant case, the problem was that the system was 'thrashing'. Useful data was being flushed, and it had to be reloaded from disk again and again. That causes the system to chew up extra resources and slows things down. In a case like that, increasing the priority of updatedb would have it get it's work done quickly during low priority times and then get out of the way. (of course, if you're on a server, you probably need to run updatedb weekly if at all.).

The real answer to his problem is to add more memory. I can't believe the number of people who will get a hot CPU and not enough memory, then find out that they're bogged down because of paging. Disk I/O is orders of magnitude slower than memory. The only things you should be paging out is (almost) completely inactive tasks, or the inactive parts of running tasks. If working tasks regularly get paged out, it was time to add RAM a while ago.

I'll almost always suggest to people to add memory before you jack up the CPU. It's usually way more efficient in terms of speeding the system up. 1Gz machine with 1GB of ram is often going to be way more usable than a 2Gz machine with 256MB, but the cost of upgrading your ram is way less than replacing the CPU (and probably the motherboard to boot). (YMMV).

Re:Worst. Advice. Ever.

[jthill]

For sufficiently large tolerances on "approximately", or when taking "no other processes" sufficiently literally, sure. For industrial-strength batch, round robin is the worst possible scheduler short of apparent malice.

Consider four tasks requiring N minutes of CPU each. Under round-robin, these will each finish after 4N minutes. Average time to complete: 4N minutes. You simply cannot make that average time any worse... unless you have other contention. Then it gets worse. Fast. GP mentioned how that operates in a specific circumstance; there are lots of ways. Hunt up thrashing for the classic examples.

Re:Worst. Advice. Ever.

[asuffield]

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.

Actually it does change the total amount of time. The issue in question here is about disk caching. The problem was that, if you run updatedb niced, then it doesn't get to run as often. In fact, it can run so infrequently that between one timeslice and the next, the disk cache has been replaced by other stuff, because of all the processes that ran in between the two.

The result is that updatedb runs with permanently cold cache. That makes it take hours instead of minutes. Hence the problem. It's not immediately obvious because it only happens when there is a moderate amount of background usage of disk resources - like an active mail server, or a backup job.

Nice isn't very nice to disk-intensive processes. This feature of unix was designed for cpu-intensive processes. It doesn't work very well on things like updatedb - you tend to get bad interactions like this one. If the system is truly idle then you're safe, but if it isn't then you're screwed.

Re:Worst. Advice. Ever.

[myowntrueself]

The issue in question here is about disk caching. The problem was that, if you run updatedb niced

One of the funniest things I ever saw as a sysadmin was updatedb running down an arch repository... on a database server.

Re:Worst. Advice. Ever.

[WhiteWolf666]

Meh.... I suppose.

For me, I don't like slocate/locate, because I leave my system powered down (suspend/standby), and I'd rather not have updatedb grinding on the hard disk when I bring the system up. It makes my games stutter.

For whatever reason, beagled doesn't grind on the drive as badly as updatedb. It certainly doesn't affect my gaming. I'm sure the memory requirements are horrific, though.

Re:Worst. Advice. Ever.

[mibus]

updatedb does the whole system. Beagle will only index your home dir.

Beagle is also run per-user, and requires per-user configuration (albeit minimal).

Re:Worst. Advice. Ever.

[gowen]

You miss my point: All those problems only exist if you're running updatedb in contention with other processes. And if those processes are grabbing resources 24/7, then running updatedb (nice or otherwise) at 3am serves no purpose.

If you run updatedb at 3am because your system is idle at 3am, then nothing will take the timeslices or flush the cache, regardless of the nice level.

Re:Worst. Advice. Ever.

[WhiteWolf666]

Beagle indexes my whole system. I've got / as one of the "directories to index". Of course, stuff that isn't accessible to my user isn't accessible by Beagle.

You could run a beagle daemon as root all the time; it won't take up much CPU once the index is built. Then, you can use either the command line or GUI to search.

*shrug*..... Beagle may not be a 100% replacement for locate, yet; but it's really close, and I think that with a few work arounds you can use it as a replacement.

"nice" as a performance tool?

[Mr Pippin]

Wow! Amazing what constitutes for an article on Slashdot.
"nice" is but a small subset of performance tools, and is the least likely command I would run on a system.
"nice" is fine when you have a series of batch jobs, and you want a specific job to recieve more CPU than another. That's a very small subset of realworld situations.

Re:"nice" as a performance tool?

[robipilot]

I just don't get the whole submission thing here sometimes. My submission on the value of tr got rejected!

Re:"nice" as a performance tool?

[Ithika]

I agree.

I mean, I know they say you shouldn't gripe about these things, but so many unix(-alike) users don't know the full power of programs like true and yes.

What if I was learning shell scripting and didn't know how to define the truth condition? What would I do? What would you do?? What would Brian Boitano do???

Re:mod UP

[MoxFulder]

I agree completely. ... ...
WTF?

Your shell may have its own version of nice

[Anonymous Coward]

Under FreeBSD default shell is csh and it has its own nice command version. So it is better to use full path if you wanna use /usr/bin/nice. Remember your shell deals with different commands and command line options to process your request:
1. Internal commands aka shell builtin command (such as set or nice)
2. External commands (such as clear, date)
3. Aliases (such as alias rm='rm -i')
4. Command substitutions ( such as echo "Today is $(date)")
5. Functions
6. Pipes ( such as cat /etc/passwd | wc -l)
7. I/O redirection (such as cat /etc/passwd > /tmp/names)
Src: http://www.cyberciti.biz/nixcraft/vivek/blogger/20 06/02/how-linux-or-unix-understand-which.php

digg?

[Anonymous Coward]

Wow, what a lame article. I would go to Digg if I wanted to read crap like this.

slmodem

[towsonu2003]

For the precompiled slmodemd (from linmodems.org), I wouldn't be able to stay connected without nice. Anytime CPU usage goes to 80-100%, an un-niced slmodemd will be unable to process info in time and connection will drop. nice (-19) nicely solves this, although stability decreases bc slmodem needs the CPU anytime data is coming from the net.

I wish we had better support for winmodems in Linux...
[sorry for offtopic]

Re:slmodem

[meringuoid]

I wish we had better support for winmodems in Linux...

How much does a good old-fashioned external serial-port modem cost these days?

Mine was about 20 quid, IIRC. I remember just pointing kppp at /dev/ttyS0 and I was away. None of this hassle.

Re:slmodem

[towsonu2003]

How much does a good old-fashioned external serial-port modem cost these days?

I think this. And others seem not to disagree with me much.

Re:slmodem

[Anonymous Coward]

[sorry for offtopic]

You should be sorry. Look at you and your stupid face? Don't you ever get sick of being a complete FAG!!! ? I mean I would have probably ordered a noose or ended it quickly. And please stop messing with modems and go play some XBill, where your talents lie.

...get a job FAG!!!

Re:slmodem

[Anonymous Coward]

Jesus, just spend $5 for a non-win modem.

Re:slmodem

[Anonymous Coward]

Look, Anonymouszilla, I may think people have stupid faces, but I don't call them ***s.

Also, not having a job is in no way related to someone's sexual relation. Who knows, he might, like, work at an awesome shop, selling.. weaponry. Or he might be a she.

You, my anonymous friend, need to stop posting on Slashdot and get a job.

- Strong Bad

nice good, kill better

[DesertWolf0132]

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.

Re:nice good, kill better

[Lispy]

"There are two keys to efficient server tuning"

Heh, on Windows we have three keys for that: + +

Re:nice good, kill better

[Lispy]

Argh, slashdot! *sigh*

It killed the joke: I meant ctrl + alt + del

Whatever... ;)

Re:nice good, kill better

[rtaylor]

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?
What do you store your porn in if it isn't a RDBMS? I need categorization damnit!

Re:nice good, kill better

[mybox]

Kill? I have a runlevel dedicated to watching pr0n..

Heh

[Arcanis the Rogue]

Pun intended.

Interesting article... even for slashdot...

[__aaclcg7560]

Which one of you basement runt been treating UNIX so badly that someone had to post an article on being "nice" to UNIX? Someone here deserves a beating with a network cable.

Re:Interesting article... even for slashdot...

[Anonymous Coward]

Someone here deserves a beating with a network cable.

"Boy, I'll beat ya to with in an inch of yo life wit this length oh CAT5 if ya don't be nice to that thar UNIX match-eeen".

Nice Shot

[BoredWolf]

Maybe Gentoo is radically different, but if I recall correctly, "nice" only sets processing priority, as opposed to overall burden. You could have 20 processes running, or 1, and regardless of their 'nice' setting, either could take up to a maximum of 100% processing power available. Computers are built to take this sort of abuse, that's why we have fans and heat-sinks. Just don't overclock if you're that worried. 'nice' only determines which process will have first dibs on that processing power. Basically, you will have the CPU running at 100% until the remaining processes require a total less than 100%. It is only useful for processes you wish to complete ASAP, or for something you can put on the back burner until there isn't anything more important to crunch. This truly is a non-article.

Repetitive tasks and tuning...

[Dr. Zowie]

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.

Re:Repetitive tasks and tuning...

[suggsjc]

Very true, cron is your best friend at times, but can quickly turn on you. I would be interested to see "qproc", but is there a standard utility that implements smarter job queuing? Something that would allow you to set up a priority system, but also times to run other jobs (cron-style).

Re:Repetitive tasks and tuning...

[nuzak]

Cron is pretty awful, from its baroque crontab syntax to security bugs, to the aforementioned runaway processes. There's oodles of replacements for it, some commercial, many of them cheap. Google for "job scheduler unix" for some of them. "Cron replacement" only points to pages mentioning the existence of replacements (some of which have cron in their name), but not any ringing endorsements.

A partial solution that keeps cron but fixes some of damage: consider having cron fire off make and run your jobs as make targets. Make's a much richer invocation front-end than cron, with dependencies and parallelism, though you do have to suffer Make's godawful primitive dependency logic based solely on file timestamps. There are of course dozens of alternatives to Make that you could also fire off from cron, though most of those improve dependency handling and don't do so hot with parallel execution.

If you don't mind Java, Quartz is a very rich job scheduler. You'll have your work cut out for you giving it a friendly front-end though. Such a front-end might be one of the few uses of a container like Avalon/PicoContainer/whatnot that isn't web-based. That is, it'd make a nice project, but I don't think anyone's done it.

Re:Repetitive tasks and tuning...

[asuffield]

This is an old problem, and it's not one that can be solved perfectly in the scheduler, due to race conditions (what if the admin was doing something at the wrong moment?). Fortunately, it can be solved perfectly in the application being run. Just use a pair of flock()ed lock files to ensure that (a) no more than one copy of the process is running at any one time, and (b) no more than one copy is waiting to run at any one time.

Algorithm:

  - try to get the 'run' lock. if we get the run lock, then run the job

  - otherwise, try to get the 'wait' lock

        - if we get the 'wait' lock, then wait and keep trying to get the 'run' lock
        - when we eventually get the 'run' lock, release the 'wait' lock, then run the job

  - otherwise, just exit

You could just use a single lock, but then you can miss an entire scheduling interval because the last run took a little bit longer than expected. This method ensures that you run the job as often as your system can, without ever running more than one copy at once. We use flock to avoid problems with stale locks. (It's not my idea, I first saw it many years ago - I think it's a very old unix trick, from the days when men were men and computers were bolted to the floor.)

This does not attempt to tackle the independent problem of a running job that gets stuck. That one, you can fix in the scheduler, or in an independent daemon that monitors process run times.

Re:Repetitive tasks and tuning...

[rdebath]

This is a very old unix trick, often reinvented.

My version was using a single lockfile and having any cronjob that didn't get the lock touch a 'missed tick' file. The working process then just looped if it saw a missed tick.

The other option is to used the batch command from your cron script, this will put an upper limit on the load your job will put on the machine.

Wow... that was pretty damn thin

[Anonymous Coward]

nice and not running updatedb... woooooo

Re:Silly question.....

[Wells2k]

Yep. We had that problem as well with some big file servers and NFS. It turned out that pdflush was set to flush data to disk once every five seconds if filled, and once every 30 seconds if stale. This was KILLING our NFS performance. Of course, once we found the real performance tuning points in /proc/sys/vm, we were home free on that. Using nice as a performance tuner of a system is just silly. nice can be used to tune the performance of programs interacting with each other to some extent, but when it comes to the system as a whole, it is a relatively small subset of the whole she-bang.

Is it a slow news day?

[TakeArms]

Is the news so slow today that Slashdot thinks it OK to post articles better left on techincal-how-to websites? Give me a break...

Obligatory...

[bennomatic]

who could ever forget the hilarity of typing this at the prompt?

man woman

Or for that matter:

'How would you rate the dishonesty of Prez Bush?

nice is news?

[Anonymous Coward]

Looks like I left the average /. crowd (including the editors) far, FAR behind myself in terms of nerdiness.

Those painful FUD and buzzword overloads in some articles were already suspicious. But now I'm vertain of it!

Can someone suggest a site like slashdot for more advanced nerds?

Off topic: Zombies

[smcdow]

As someone who just had to deal with a machine becoming inoperable because the process table filled up with thousands of zombies because 3rd party software wasn't reaping its children.....

Please, for the love of all that's holy and Unixy, teach yourselves what a SIGCHLD is and how to use wait(2).

Re:Off topic: Zombies

[nuzak]

> Please, for the love of all that's holy and Unixy, teach yourselves what a SIGCHLD is and how to use wait(2).

Linux must have some process that reaps them automatically. I've kill-9'd plenty of parent processes and forked without waiting, and I haven't seen a zombie in years.

Zombies are an artifact of bad system design. If I didn't express an interest in process accounting when I created the child, I damn sure don't need it hanging around for process accounting when it exits.

Re:Off topic: Zombies

[Anonymous Coward]

Oh, signal(SIGCHLD, SIG_IGN) and they don't.

Re:Off topic: Zombies

[psmears]

Linux must have some process that reaps them automatically. I've kill-9'd plenty of parent processes and forked without waiting, and I haven't seen a zombie in years.

Killing the parent doesn't create a zombie—the orphaned process becomes a child of its parent’s parent (ie its grandparent process), which is often a shell or init (both of which are good at cleaning up after their children).

Zombies are an artifact of bad system design. If I didn't express an interest in process accounting when I created the child, I damn sure don't need it hanging around for process accounting when it exits.

It's not really bad system design, more a poor choice of defaults in the API—the default should probably be not to create zombies. But it’s arguable: often (if you’re writing software for more than throwaway purposes) you’ll want to know the exit status of your children... But you can disable the creation of zombies—just call sigignore(SIGCHLD) in your parent process, and you’ll never see a zombie again.

nice is great for running long jobs in background

[Quevar]

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.

Low numbers == High priority???

[AmbushBug]

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...

Re:Low numbers == High priority???

[Anonymous Coward]

This is (AFAIK!) due to the sign at the beginning of the number. On default, it's a zeroed bit, thus zeroed bit = normal performance. Then, if you want higher performance for that process, you 'flag' it by setting the first bit (aka: it ends up being a negative). Then it's simply the 'higher' the rest of the number (which would be for negatives even more negative) the more (or less) priority it has.

http://en.wikipedia.org/wiki/Two's_complement

Again AFAIk, but 'old' systems didn't have the whole range of priority levels. They just had a few (one?) bit(s) to 'flag' processes which had higher priority.

HtH (and if I'm incorrect please clue me in) :)

- wacco

Re:Low numbers == High priority???

[faloi]

Probably because it's always been that way. IRQs are prioritized with lower numbers getting higher priority (except for the peskiness that ensues with 8-15 being tied back to IRQ 2). Someone probably decided a long time ago that it made sense (do 1, then 2, then 3, etc.) and it's stuck. But signed bits may play into it as well.

Re:Low numbers == High priority???

[NereusRen]

It's because they changed the metaphor from "having priority" to "being nice." If a process is more nice, it lets other processes use CPU time first. If it is less nice, it hogs it all for itself.

It's confusing if you are used to thinking in terms of priority, but it makes sense after the first few times you see it.

Re:Low numbers == High priority???

[kindbud]

Think of "priority" as a commodity to be divided up among all the processes, and the amount of priority a particular process gets is its nice value divided into priority. The smaller the divisor assigned to a process, the more CPU time it gets.

priority / nice = amount of CPU time.

Re:Low numbers == High priority???

[gedhrel]

You're incorrect. The nice -> priority doesn't work that way; and with twos' complement, if you ignore the sign bit then the higher the value of the remainder, the less negative (closer to -1) it is.

Re:Low numbers == High priority???

[Tribbin]

It's the positive viewpoint; the glass is half-full.

Ric Romero?

[cashman73]

Is Ric Romero taking notes on this article?

BUGS

[Alien Being]

I can't remember which version it was, but I once saw a manpage for nice that said:

BUGS
        Nobody ever uses this command.

Wait! There's a "nice" command?

[phreakster]

Now I find there's also a ls command for listing files and directories? Even a chmod for changing permissions! Who knows what's next. You know what would be really cool - that would be like... multitasking and multiuser features. Yeah. That would be TOO rad. :)

I suffer from low self esteem

[Anonymous Coward]

I run nice on all my programs because I'm just not as important as everyone else.

Obligitory...

[fak3r]

nice article.

Re:nice is great for running long jobs in backgrou

[Anonymous Coward]

"manipulating some images in the foreground, so I set Quicktime and Matlab and whatever else to -19 priority.

Er? do you mean +19? The lower the number the higher the priority.

Qouth:
-n priority
            Specifies how the system scheduling priority of the executed utility is
            adjusted. The priority argument is a positive or negative decimal
            integer.

            Positive priority values cause a lower or unchanged system scheduling
            priority.

            Negative priority values might require appropriate privileges and cause
            a higher or unchanged system scheduling priority.

So, stuff in the background would be 19...

The only use for nice

[wsanders]

The only use for nice I've ever been forced to implement was renicing processes based on the job submitter's rank in the company. (This was a CPU-intensive render/simulation farm.)

Well, there was time some bozo's log rotation script filled up var with log copies - he copied every file every day, even copies of copies, until the filesystem ran out of inodes. THere were too many files to delete with "rm *", so I did something like "for n in 0 1 2 3 4 5 6 7 8 9 ; do nice -n $n rm ${n}*; done". I don't think it made one bit of difference, the buffer cache is still mad at me.

Re:The only use for nice

[Anonymous Coward]

find . -user xxx -exec rm {} \;

Re:The only use for nice

[slimey_limey]

Would have been better to do "rm -R ./" so that the shell expansion wouldn't choke.

Re:The only use for nice

[wsanders]

Mostly I was curious about whether running 10 rm's in "parallel" was faster than running one "rm -r". I had to do this on several machines so I was able to compare, and since the 10 rm's in parallel used a lot more CPU than a single "rm -r", based on the "BOFH's Razor" Principle the method that consumed more CPU was obviously better

1975 called- they want their news flash back

[Anonymous Coward]

Thirty of nice and now this groundbreaking article. What's next in the series? Using ps to manage processes??

WTF?

Negative numbers for higher priority?

[operagost]

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.

Re:Negative numbers for higher priority?

[Anonymous Coward]

Because the command is named "nice", not "mean".

Re:Negative numbers for higher priority?

[TeknoHog]

I think it's obvious from the 'nice' command name. A program that is 'nicer' to others, by giving up resources that others want to use, has a higher value of 'niceness'.

Re:Negative numbers for higher priority?

[Adam Heath]

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.

Re:Negative numbers for higher priority?

[Hatta]

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.

Re:Negative numbers for higher priority?

[fintler]

A stack which would implement a priority queue to hold the task structs would be pictured vertically with the last process to be put on the "top" or "back" of the queue. This would mean that the last process to run would get the highest number and the ones that are closer to being able to run get a lower one. It's not so much about tradition as it is about how the system is actually implanted and generally taught in Computer Science 101.

Computers are not my employees

[chowbok]

They are my slaves.

I will thrash them if they don't do what I want. Eventually they will die from overwork, or be shot in the head for being too old to run modern programs.

Re:nice is great for running long jobs in backgrou

[Kadin2048]

I think you're off by a factor of -1.

Negative numbers (down to -19) have the highest priority, and positive numbers have the lowest priority. Yes, it's backwards and nonsensical and I can only assume that some programmer somewhere is having a good laugh at everyone who's ever been confused by it.

I personally haven't ever used "nice" on my Mac -- most of the stuff I launch from the commandline isn't that processor-intensive. I do use "renice" a lot, which modifies the priority of a process that's already running. So I think that would be what you'd use, if you wanted to bump Handbrake or something to a lower priority. (Not that I know from personal experience what Handbrake is, or does, or anything, *cough*)

I'm not sure if "renice" comes with OS X by default or whether I had to install it at some point.

I'm number 1!

[Junior J. Junior III]

Have you ever finished first in life? First in line is next to go.

This is nice too...

[Anonymous Coward]

unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; sleep

Re:nice is great for running long jobs in backgrou

[Black Copter Control]

It's counter-intuitive, but the shell command would be 'nice -19 program' to run it in really nice mode.

To run a program in hog mode, you would go 'nice --19 runmenow'

Thus, his '-19' reference makes complete sense.

-- at least that's how it works for the 'nice' binary, and bash. csh, on the other hand, uses 'nice +19' to be nice and 'nice -19' (as root) to be nasty. -- One of the many things that csh does weird that weaned me off of it. (but let's walk away from bash/csh flame wars, shall we?)

Jesus, what kind of a commie pinko are you?

[RomulusNR]

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?

Re:Worst. Advice. Ever. TRY NOATIME

[redelm]

Agreed. Use the old newspool trick: `updatedb` runs like greased lightening on a partition mounted with `noatime`. ~1 min for 40 GB. All those accesstime updates eat most of the wall time. I mount all partitions NOATIME in /etc/fstab unless I _really_ need atime.

Nice is Nasty

[redelm]

Seriously, nice is not a good performance tuning tool in most cases. All it does is shorten the timeslice, inducing more cache misses. The work remains the same or goes up due to cache reloads.

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.

nice for the Mac geeks

[Been on TV]

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 -5

Also, 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/.

Re:nice is great for running long jobs in backgrou

[Anonymous Coward]

I always thought the command was "nice" because lowering the execution priority of noncritical tasks was the "nice" thing to do -- for the other processes on a single user system, or for the other users on a multi-user system. If this is a true, a nicer process runs at a larger integer, where a jackass process runs at small (i.e. large and negative) integer.

I guess I have a lot to learn!

This is helpful, but not news.

[Aluminum Tuesday]

Educating people about their systems isn't a bad thing, but ought this really be front page news on Slashdot?

nice -5 apachectl start

[Spazmania]

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.

Still works with GNU tools (n/t)

[tabrisnet]

Still works with GNU tools (I did say above 'no text'. Damned /. anti-lameness filter).

Tested OpenSuSE 10.0, debian sarge.

WAAATFM

[Anonymous Coward]

This IBM guy not only RTFM but he Wrote An Article About TFM.

powernowd? -n!

[ndim]

too bad the powernowd needs to be disabled to let the machine run at full speed but process still at a nice priority ...

You do know about "powernowd -n", don't you?

"nice" for disk access and other non-CPU resources

[ndim]

It would be nice (no pun intended) to be able to restrict or throttle other resources besides CPU.

Definitely! Prioritizing local hard disk access according to process nice levels shouldn't even be all that hard to implement and quite useful.

Doing the same thing to network traffic is another matter, because the network has to support that in some fashion.

Thread priority / security context

[butlerm]

What would really be 'nice' would be a way to set relative SCHED_OTHER thread priorities on Linux...

Or even better a way to run threads in different security contexts in the same process, with memory protection, visibility control, and so on. The POSIX standards in this area are a real drag...

Re:nice is great for running long jobs in backgrou

[Anonymous Coward]

You don't have this problem if you run the program correctly, e.g:

nice -n 19
nice -n -20

From the info page:
          On older systems, `nice' supports an obsolete option
          `-ADJUSTMENT'. POSIX 1003.1-2001 (*note Standards conformance::)
          does not allow this; use `-n ADJUSTMENT' instead.

Hmmmmmm

[ninewands]

Use nice(1) and renice(8) to performance-tune your server ... DUH!

C'mon IBM ... this is not even sysadmin 101-level material ...

Here I was all ready to receive the latest recommendations from Big Blue about WHICH processes should be set to WHICH nice(1) level to make a decent first approximation of a well-balanced server and all I get is this stuff.

Very disappointing.

Re:nice is great for running long jobs in backgrou

[Quevar]

Yes, you are right on both accounts - I wasn't thinking when I typed it and got the negative siign and I use renice. I actually type: "renice 19 process_id" to make it more nice (positive number). Negative numbers are less nice.

It does come with "OS X" by default.

Not quite...

[ericbg05]

Average of runnable tasks count get you the load.

Not quite: the load average also takes into account processes in uninterruptible sleep states (i.e. waiting for disk i/o).

While we're on the subject, I found this interesting: the load average isn't your average average.

Not Worth Reading

[juergen]

Some facts are wrong, or Linux specific where described as Unix-generic (for example, other Unixes have varying priority levels). Most of this is trivial to system administratiors, yet there is unneccessary detail for beginners. Too unfocused to be useful to any audience.

ratings:
Helpful: no (x)
Useful: [1] not at all (x)

This, like quite a lot of IBM devnet articles, seems to be produced for page count, not usefulnes.

nice is broken

[Anonymous Coward]

The basic UNIX scheduler has been broken since 1971. If you want something that's "nice" then learn how to use the fair share scheduler in Solaris!

Re:nice is broken

[Anonymous Coward]

Now that's not very nice, is it.

Unix, or AIX ?

[Anonymous Coward]

As far as I know the latter is a Unix deritive, not a full Unix setup. And when I look at Unix I think Sun's DTrace approach on Solaris (being ported to *BSD) simply kicks the ancestors ass big time.

This only increases the risk of bad *nix administration. A program doesn't perform as well as it should, you raise priority and watch it affect the rest of the machine. In the end you'll end up buying other hardware or perhaps doing other symptom fighting while you could have removed the culprit itself.

Nice test

[DenDave]

I remember I once baked a PII 333 by running the setiathome number cruncher in three instances and then nicing them to -19.. it took about three hours before the chip ceased to function.