|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
| See Also | Recommended Links | Performance tuning | time | x11perf | ||
| nohup | top | vmstat | Horror Stories | Unix History | Humor | Etc |
|
|
In Unix no process can monopolize all system resources (CPU, memory, disk access, and so on). The kernel’s primary function is to manage the system resources equitably. It does this by assigning a priority to each process so that some processes get better access to system resources and some processes might have to wait longer until their turn arrives. Changing priority of the task can be useful in a situation in which CPU and RAM use must be reserved or allocated for a specific task. That's what nice and renice commands allow you to do.
The operating system's task switcher, also known as the scheduler, is designed to do the following:
|
|
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. In general, the scheduler makes sure that the system runs in an orderly, responsive manner.
Many things make up the context of a running task. When a task runs, there is a CPU register called the instruction pointer (IP) that contains the memory address of the current machine code instruction being executed. When a task is switched out, the task switcher must save the value of that IP register to be able to reload it again later when the task is switched back in. Therefore, part of the context of a task is the current IP value.
Another important value that makes up the context of a task is the stack pointer (SP). The stack is a last-in-first-out (LIFO) queue that holds subroutine return addresses, items of data, pointers, and so on. The meaning of each item held on the stack is determined by the instructions that operate on them, according to the programmer's detailed design.
The IP and SP, along with all of the other important CPU registers that make up the context of the running task, are the low-level details that the task switcher uses to switch contexts and run different tasks. The task switcher also works with higher-level details. One of those higher-level details is the priority of the task.
In the UNIX scheme of things, this priority is indicated by a number that
can vary from a -20 to a +19 and is known as the nice number of the
task. The programs with the highest priority have the lowest nice value,
so a value of -20 makes a task important in the UNIX scheme. Contrary to that, a
task with a nice value of +19 is a nice, unselfish task that allows
all other tasks to have a greater share of the CPU's precious time to run on than
itself.
The nice command is used with its -n option, along with an argument in the range of -20 to 19, in order from highest to lowest priority (the lower the number, the higher the priority). For example, to run the gzip with a low priority, use the nice command like this:
$ nice -n 12 gzip /proxylogs/* &
UNIX provides several tools for detailed viewing of what is running on the computer
at any time. Among them the ps command and top. Based
on the ps command, the top command provides a convinient text-based
display of constantly updated console-based output showing the most CPU-intensive
processes currently running. It can be started like this:
# top
The renice command can be used to reset the priority of running processes or control the priority and scheduling of all processes owned by a user. Regular users can only numerically increase process priorities (that is, make tasks less important) with this command, but the root operator can use the full nice range of scheduling (-20 to 19).
System administrators can also use the time command to get an idea of how much time and what proportion of a system’s resources are required for a task, such as a shell script. (Here, time is used to measure the duration of elapsed time; the command that deals with civil and sidereal time is the date command.) This command is used with the name of another command (or script) as an argument like this:
# time -p find / -name core -print /dev/core /proc/sys/net/core real 1.20 user 0.14 sys 0.71
Output of the command displays the time from start to finish, along with the user and system time required. Other factors you can query include memory, CPU use, and file system input/output (I/O) statistics. See the time command’s man page for more details.
Nearly all graphical process-monitoring tools include some form of process control or management. Many of the early tools ported to Linux were clones of legacy UNIX utilities. One familiar monitoring (and control) program is top.
 |
 |
 |
In addition to the
topcommand, you can also display niceness values using thepscommand. You can either customize the output as you saw in the article "Learn Linux 101: Create, monitor, and kill processes," or you can just use the-loption to get a long listing. The output ofps -lis shown in Listing 2. As withtop, look for the niceness value in the NI column.
Listing 2. Using ps to find niceness
You may have guessed from Listing 1 or Listing 2 that the default niceness, at least for processes started by regular users, is 0. This is usually the case on current Linux systems. You can verify the value for your shell and system by running the
nicecommand with no parameters as shown in Listing 3.
Listing 3. Checking default niceness
Before we look at how to set or change niceness values, let's build a little CPU-intensive script that will show how niceness really works.
We'll create a small script that just uses CPU and does little else. The script takes two inputs, a count and a label. It prints the label and the current date and time, then spins, decrementing the count till it reaches 0, and finally prints the label and the date again. This script shown in Listing 4 has no error checking and is not very robust, but it illustrates our point.
Listing 4. CPU-intensive script
If you run this on your own system, you might see output similar to Listing 5. Depending on the speed of your system, you may have to increase the count value to even see a difference in the times. This script uses lots of CPU, as we'll see in a moment. If your default shell is not Bash, and if the script does not work for you, then use the second form of calling shown below. If you are not using your own workstation, make sure that it is okay to use lots of CPU before you run the script.
Listing 5. Running count1.sh
So far, so good. Now let's create a command list to run the script in background and launch the
topcommand to see how much CPU the script is using. (See the previous article "Learn Linux 101: The Linux command line" for a refresher on command lists.) The command list is shown in Listing 6 and the output fromtopin Listing 7.
Listing 6. Running count1.sh and top
top - 15:41:15 up 1 day, 17:59, 6 users, load average: 0.20, 0.06, 0.02 Tasks: 169 total, 2 running, 167 sleeping, 0 stopped, 0 zombie Cpu(s): 52.1%us, 0.7%sy, 0.0%ni, 47.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 4057976k total, 1393772k used, 2664204k free, 235596k buffers Swap: 10241428k total, 0k used, 10241428k free, 662592k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 26756 ian 20 0 4004 588 496 R 100 0.0 0:03.53 sh 11220 ian 20 0 555m 101m 27m S 5 2.6 57:58.07 firefox 26757 ian 20 0 19132 1364 980 R 0 0.0 0:00.03 top 1 root 20 0 19584 1888 1196 S 0 0.0 0:00.89 init 2 root 15 -5 0 0 0 S 0 0.0 0:00.01 kthreadd
Not bad. We are using 100% of one of the CPUs on this system with just a simple script. If you want to stress multiple CPUs, you can add an extra invocation of
count1.shto the command list. If we had a long running job such as this, we might find that it interfered with our ability (or the ability of other users) to do other work on our system.Now that we can keep a CPU busy for a while, we'll see how to set a priority for a process. To summarize what we've learned so far:
- Linux and UNIX® systems use a priority system with 40 priorities, ranging from -20 (highest priority) to 19 (lowest priority.
- Processes started by regular users usually have priority 0.
- The
pscommand can display the priority (nice, or NI, level, for example) using the-loption.- The
nicecommand displays our default priority.The
nicecommand can also be used to start a process with a different priority. You use the-nor (--adjustment) option with a positive value to increase the priority value and a negative value to decrease it. Remember that processes with the lowest priority value run at highest scheduling priority, so think of increasing the priority value as being nice to other processes. Note that you usually need to be the superuser (root) to specify negative priority adjustments. In other words, regular users can usually only make their processes nicer.To demonstrate the use of
niceto set priorities, let's start two copies of thecount1.shscript in different subshells at the same time, but give one the maximum niceness of 19. After a second we'll useps -lto display the process status, including niceness. Finally, we'll add an arbitrary 30-second sleep to ensure the command sequence finishes after the two subshells do. That way, we won't get a new prompt while we're still waiting for output. The result is shown in Listing 8.
Listing 8. Using nice to set priorities for a pair of processes
Are you surprised that the two jobs finished at the same time? What happened to our priority setting? Remember that the script occupied one of our CPUs. This particular system runs on an AMD Athlon™ 7750 dual-core processor, which is very lightly loaded, so each core ran one process, and there wasn't any need to prioritize them.
So let's try starting four processes at four different niceness levels (0, 6, 12, and18) and see what happens. We'll increase the busy count parameter for each so they run a little longer. Before you look at Listing 9, think about what you might expect, given what you've already seen.
Listing 9. Using nice to set priorities for four of processes
With four different priorities, we see the effect of the different niceness values as each job finishes in priority order. Try experimenting with different nice values to demonstrate the different possibilities for yourself.A final note on starting processes with
nice; as with thenohupcommand, you cannot use a command list or a pipeline as the argument ofnice.If you happen to start a process and realize that it should run at a different priority, there is a way to change it after it has started, using the
renicecommand. You specify an absolute priority (and not an adjustment) for the process or processes to be changed as shown in Listing 10.
Listing 10. Using renice to change priorities
Remember that you have to be the superuser to give your processes higher scheduling priority and make them less nice.
You can find more information on
niceandrenicein the man pages.
|
|
|
Apr 04, 2006 | Developerworks
... The operating system's task switcher, also known as the scheduler, is designed to do the following:
- Load the context of a task into the Central Processing Unit (CPU) registers.
- Let the task run for a short period of time.
- Save that context before loading the context of the next task.
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. In general, the scheduler makes sure that the system runs in an orderly, responsive manner.
Many things make up the context of a running task. When a task runs, there is a CPU register called the instruction pointer (IP) that contains the memory address of the current machine code instruction being executed. When a task is switched out, the task switcher must save the value of that IP register to be able to reload it again later when the task is switched back in. Therefore, part of the context of a task is the current IP value.
Another important value that makes up the context of a task is the stack pointer (SP). The stack is a last-in-first-out (LIFO) queue that holds subroutine return addresses, items of data, pointers, and so on. The meaning of each item held on the stack is determined by the instructions that operate on them, according to the programmer's detailed design.
The IP and SP, along with all of the other important CPU registers that make up the context of the running task, are the low-level details that the task switcher uses to switch contexts and run different tasks. The task switcher also works with higher-level details. One of those higher-level details is the priority of the task.
All programs are not created equal. Some programs that are critical to the operation of the computer itself must have a higher priority than others that are not so critical. In the UNIX scheme of things, this priority is indicated by a number that can vary from a -20 to a +19 and is known as the
nicenumber of the task. The programs with the highest priority have the lowestnicevalue, so a value of -20 makes a task important in the UNIX scheme. Contrary to that, a task with anicevalue of +19 is a nice, unselfish task that allows all other tasks to have a greater share of the CPU's precious time to run on than itself.UNIX provides many powerful tools for detailed viewing of what is running on the computer at any time, and the
pscommand was designed to give you those details. Start an xterm and enter the following command to see how nice the programs are:
The command produces output, as shown in Listing 1 below.
Listing 1. Output
PID S NI COMMAND 1 S 0 init [5] 2 S 19 [ksoftirqd/0] 3 S -10 [events/0] 4 S -10 [khelper] 5 S -10 [kblockd/0] 28 S 0 [kapmd] 30 S 0 [pdflush] 31 S 0 [pdflush] 33 S -10 [aio/0] 32 S 0 [kswapd0] 138 S 0 [kseriod] 176 S 0 [kjournald] 1080 S 0 [kjournald] 1081 S 0 [kjournald] 1082 S 0 [kjournald] 1564 S 0 /sbin/dhclient -1 -q -lf /var/lib/dhcp/dhclient-eth0... 1610 S 0 syslogd -m 0 1614 S 0 klogd -x 1632 S 0 portmap 1651 S 0 rpc.statd 1729 S 0 /usr/sbin/sshd 1744 S 0 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid 1760 S 0 ntpd -U ntp . . . 2364 S 0 konsole 2373 S 0 /bin/bash 2563 R 0 ps -eo pid,state,nice,args
On my workstation, 84 lines were generated. This means that at the time the
pstask was running, it was only one of 84 different tasks that were competing for time to run on the CPU. Now examine the parts of this command to better understand what the system is telling you. The-eo pid,state,nice,argsswitch tells thepstask to list the following information for each task running on the system:
- Process ID (pid)
- Whether the task is running or sleeping (state)
- Nice number (nice)
- Arguments when the task was invoked (args)
The
lesscommand with the-Sswitch creates a clean, good-looking list by limiting each line in the list to the width of the xterm.The majority of the tasks have a
nicevalue of "0," putting them right in the middle of the priority range. There are few tasks running withnicenumbers that make them high (-10) or low (19) priority. Most of the tasks are also sleeping; that is, they are waiting for some resource to become available. In fact, only thepscommand was running when I generated this list. Most tasks are designed to do what they need to do quickly and then exit or sleep.The
nicecommand executes a command specified within its argument list with the givennicenumber. Therenicecommand is used to change thenicenumber of the task. For command switch details, see the man pages for each command.
renice command
The
renicecommand enables you to alter the priority of currently running processes. The new priority number (the nice number) and the process ID (the PID) are the primary input for therenicecommand of the program to be changed.You can
reniceany of the processes that you own; however, you can only monotonically increase their priority within the range of 0 to 20, whereas only the superuser canreniceany currently running process over the full range of nice values.Two main classes of UNIX computers dominate the horizon: workstations and servers. Each requires careful attention to the processes that run on the machines to ensure their limited resources aren't wasted by repetitively performing tasks that aren't important to their designated purposes.
Because workstations can be used for many varied tasks, there are no fixed rules for tuning every workstation. Some workstations are used for programming, graphic artistry, heavy number crunching, and for data mining. In every case, it helps to see what processes are running while you are doing your preferred activity, and then tune your workstation accordingly.
For example, on a programmer's workstation, compiling and linking some programs can take many hours. A programmer who wants to speed it up -- at the expense of everything else -- can become a superuser and then start the compile with the following commands:
The
-n -15parameter lowers thenicenumber of themaketask by 15 -- this increases the priority so much that you can actually feel it when you move the mouse around the screen. On most systems, only the superuser account can make this type of priority change to a task. Nonetheless, for a workstation running a long process, it can be worthwhile.
The administrator of a system can use the configuration file associated with the Linux Pluggable Authentication Modules (PAM) in order to impose resource limits, including a default nice value, on users. This file is known as the limits.conf file and can be found in the /etc/limits or /etc/security directories. Although it is beyond the scope of this article to describe this file in detail, many articles can be found on the Internet describing it. Briefly, the line ...
is the same as running...
on all processes that the user runs.There are several other parameters for resource limiting to be found in the limits.conf file, but this covers the default nice value that user processes run with.
Another important way to tune a workstation's performance is to identify features and functions you don't use that might be running on your workstation. For example, many Linux® systems have a file called /etc/cron.daily/slocate.cron that runs the disk-intensive
dbupdateprogram on a daily basis. This program enables you to use thelocatecommand, rather than thefindcommand, to find files. If you never use thelocatecommand, you can edit the /etc/cron.daily/slocate.cron file so thedbupdateprogram doesn't run by becoming a superuser, starting your favorite editor, and commenting out the instructions, as shown in Listing 2 below.
Listing 2. /etc/cron.daily/slocate.cron file
Listing 3 indicates how the /etc/cron.daily/slocate.cron file should look after you put the comment character (
#) before each line, to prevent it from being executed.Note: Commenting out each line in this tiny script is a better way to prevent it from running than simply deleting the file. After all, you might change your mind at some future date and want to begin using the
slocatecommand. This will necessitate, allowing the cron task to run the updated program. All you need to do then is delete the comment characters before each line in the file.
Remember, this is an issue of personal preference too. If your machine belongs to your employer, I do not suggest making such changes without supervisory permission. After all, the system administrators might want to use the
locatecommand when you're not there.Unlike workstations, servers usually have precisely defined purposes and, therefore, are easier to tune. For example, the primary responsibility of a Web server is to receive and satisfy browser requests from the Internet. Similarly, a file server must quickly and accurately dispense the files being requested. In both cases, the server shouldn't have tasks that are normally assigned to workstations.
If a server is dedicated to one primary function, such as a Web server, edit out any other services from the configuration files. Often, a Web server runs the ftp, nfs, dhcp, dns, and other daemons that aren't necessary. The less that a machine must share, the more responsive its primary tasks are. As a bonus, there is also greater security, because there are fewer holes available to hack.
This article provides some general guidelines for tuning server performance. For more specific information, check out the links in the Resources section.
If you carefully tune the processes that run on your workstations and servers, including setting the appropriate task priorities and removing tasks that waste resources, your computers will continue to be the good and faithful servants that they're meant to be.
Google matched content |
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March 12, 2019
