Continuing your adventures into the wilderness of UNIX®, turn your attention to issues of multitasking. Modern computers, your fast and efficient servants, have so much high-speed memory available that they can contain hundreds of discrete programs in memory at the same time.

Programs in memory are known by many names, including threads, processes, daemons, kernels, libraries, shared objects, and so on. If you want to understand the underlying order amid the seeming chaos, grab your machete and hack away at the many vines and weeds that block your passage. You find that the programs in memory are all simple binary patterns in memory that share a common trait: they each have their own running context. For the sake of simplicity, I refer to them all as tasks in this article.

The operating system's task switcher, also known as the scheduler, is designed to do the following:

1. Load the context of a task into the Central Processing Unit (CPU) registers.
2. Let the task run for a short period of time.
3. 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.

It's all in the context

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.

Priority

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

UNIX provides many powerful tools for detailed viewing of what is running on the computer at any time, and the ps command was designed to give you those details. Start an xterm and enter the following command to see how nice the programs are:

$ ps -eo pid,state,nice,args | less -S

The command produces output, as shown in Listing 1 below.

  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 ps task 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,args switch tells the ps task 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 less command with the -S switch 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 nice value of "0," putting them right in the middle of the priority range. There are few tasks running with nice numbers 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 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.

Nice and renice

The nice command executes a command specified within its argument list with the given nice number. The renice command is used to change the nice number of the task. For command switch details, see the man pages for each command.

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.

Workstations

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:

$ su
Password:

# nice -n -15 make

The -n -15 parameter lowers the nice number of the make task 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.

@lusers hard priority 5

nice -n 5

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 dbupdate program on a daily basis. This program enables you to use the locate command, rather than the find command, to find files. If you never use the locate command, you can edit the /etc/cron.daily/slocate.cron file so the dbupdate program doesn't run by becoming a superuser, starting your favorite editor, and commenting out the instructions, as shown in Listing 2 below.

$ su
Password:

# cd /etc/cron.daily

# vi slocate.cron

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

#!/bin/sh
# renice +19 -p $$ >/dev/null 2>&1
# /usr/bin/updatedb -f "nfs,proc,devpts" -e "/tmp,/var/tmp,/usr/tmp,/afs,/net"

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 locate command when you're not there.

Servers

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.

Conclusion

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.

Resources

Learn

• AIX and UNIX articles: Check out other articles written by William Zimmerly.
  
  
• See Commands Reference, Volume 4, nice Command to learn more about the nice command specifically for the IBM AIX® environment.
  
  
• In "Setting Up a Linux Server," Mr. Windley describes many useful tips for setting up a Linux server.
  
  
• Read more about the basics of configuring Linux services, such as the Web server, telnet, ftp, and mysql in "Configuring Linux."
  
  
• "Linux Commands for Beginning Server Administrators" provides some of the important Linux commands for beginning administrators.
  
  
• Visit the developerWorks Linux zone to expand your Linux skills.
  
  
• Stay current with developerWorks technical events and Webcasts.
  
  

Get products and technologies

• Build your next development project with IBM trial software, available for download directly from developerWorks.
  
  

Discuss

• Participate in developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

Bill Zimmerly is a knowledge engineer, a low-level systems programmer with expertise in various versions of UNIX and Microsoft® Windows®, and a free thinker who worships at the altar of Logic. Bill is also known as an unreasonable person. Unreasonable as in, "Reasonable people adapt themselves to the world. Unreasonable people attempt to adapt the world to themselves. All progress, therefore, depends on unreasonable people" (George Bernard Shaw). Creating new technologies and writing about them are his passions. He resides in rural Hillsboro, Missouri, where the air is fresh, the views are inspiring, and good wineries are all around. There's nothing quite like writing an article on UNIX shell scripting while sipping on a crystal-clear glass of Stone Hill Blush. You can contact him at bill@zimmerly.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• It's all in the context
• Priority
• Nice and renice
• Workstations
• Servers
• Conclusion
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into AIX and UNIX on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers