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

14 of 206 comments (clear)

  1. Scheduling Priority is for sissys by SatanicPuppy · · Score: 5, Funny

    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.
  2. First Post? by bje2 · · Score: 5, Funny

    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
  3. Next up: "man nice" "man man" "man mount" ? by Gothmolly · · Score: 4, Insightful

    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.

    --
    I want to delete my account but Slashdot doesn't allow it.
    1. Re:Next up: "man nice" "man man" "man mount" ? by eln · · Score: 4, Funny

      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.

    2. Re:Next up: "man nice" "man man" "man mount" ? by SatanicPuppy · · Score: 4, Insightful

      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.

      --
      ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
    3. Re:Next up: "man nice" "man man" "man mount" ? by wild_berry · · Score: 5, Funny

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

  4. Here's a tip. by Anonymous Coward · · Score: 5, Funny

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

  5. Have a DVD-ripping death match! by MoxFulder · · Score: 4, Funny

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

  6. Bad teacher, no cookie! by Fubar420 · · Score: 5, Insightful

    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.

    --
    -- (appended to the end of comments you post, 120 chars)
    1. Re:Bad teacher, no cookie! by alexhs · · Score: 4, Insightful

      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.

      --
      I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
  7. Re:what about killall by LLuthor · · Score: 4, Informative
    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)
    --
    LL
  8. Re:what about killall by Stradenko · · Score: 4, Informative

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

  9. Repetitive tasks and tuning... by Dr.+Zowie · · Score: 5, Interesting

    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.

  10. Re:Worst. Advice. Ever. by gowen · · Score: 4, Informative
    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.
    --
    Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.