CS10110 Introduction to personal computer equipment

CS10110 Introduction to personal computer equipment PRACTICAL 4 : Process, Task and Application Management In this practical you will: Use Unix shell commands to find out about the processes the operating system is running; Use the command line to control those processes Create processes on other machines and investigate the behaviour of X windows in this situation; Observe user and kernel scheduling of processes and tasks in the MS Windows environment; Apply knowledge of virtual memory and paging gained in lectures to understand a variety of the more sophisticated measurable performance indicators provided by the Task Manager; Observe the effect of changing process priority; Investigate how poorly written software can impact on the performance of a system. Part 1 Unix Log in to Wiked/Minted and obtain a bash shell terminal window. In this worksheet I have used Minted. If you are logged on to Wiked (or any other machine) then substitute that machine name wherever I have used Minted. Controlling a process 1. Running a process is easy and you have done it before - simply type a command at the command prompt and press return! xclock or xeyes are suitable simple little applications. You will notice that the command prompt does not reappear. I'll assume from here you're using xclock, but you don't have to. 2. Stop the application process by using <CTRL> z. Watch your chosen application! Try obscuring and uncovering it with another window. What happens? 3. To prevent the shell from waiting for the application process to finish, add an ampersand (&) to the end of the command to place it in the background (xclock &) and allow the shell to continue running. Create another clock in the background now. Notice the information the shell returns to you (look at the man page for bash under the section entitled job control for details). You might want to run xman in the background as well to look at this) Finding out what processes are running. First try using the ps command without any options to see what processes are running under the shell you are using. Unfortunately there are different versions of the ps command around with different command options. Check the man pages for the system you are using and find out Page 1

how much memory and processor resources these processes are using. The l or the u options can be helpful, but there are lots of other useful ones. Look for the status column for each process. What is the difference in status between the stopped and working process you created above? Do this in a different terminal window so as not to confuse what you are doing. You could use an xterm & command to create another terminal (or you could use the GUI menus). There is a list of all the abbreviations for the process state codes on the man page. Also note that b or <CTRL> b allows you to go back a page when using man (or more) (Page Up and Page Down keys also work on some systems). You can also type /xxx to search for a phrase (i.e. xxx in this example). What about the stopped clock? There are several choices. You could either bring the clock to the foreground using the fg command, let it continue in the background (bg) or kill it off. Try bringing it to the foreground (check it starts again), stop it again, and then put it in the background. If a process is running in the foreground you can use <CTRL> c to kill the process. However if it is running in the background you need to tell the shell to kill off the process for you using the kill command. Get a process list (ps) and use this information (you need the process number) with the kill command to kill off one of your clocks now! Where are the rest of the processes So far you will probably only have seen the processes that are children of the shell you used the ps command from. Now use the ps command with appropriate options to find out: All of the processes you are running as a user All of the processes the system is running (hint: check man ps and take particular note of the e, f and u options) Is this what you expect there will probably be lots of xclocks, bash shells and ps processes being run by other users (especially if others are doing this worksheet at the same time as you)! Which processes are using the most cpu and memory resources? Don t forget that you can pipe output to more or even redirect it to a file if there is too much to see on the screen in one go or you want to keep it for later. Hopefully you remember the wc command? Type a command that will tell you how many processes you are running (use man wc if you've forgotten how to count lines). Now get a list of all processes running on the machine you are logged on to. Which process was created first when this machine was booted? Other than the date/time, how could you tell? Locate the first five Page 2

processes that were created. Do you recognise any of the important tasks the OS might be performing (think of io, swapping (virtual memory) etc). What is the oldest process that belongs to you? Is this what you expect? Watching things happen There are a number of ways of seeing how the system is performing dynamically. One of the simplest and most informative is the top command. It will display a variety of system statistics followed by the top most processor intensive activities. However, on the SUN computers, it is recommended that you use the command prstat instead. In fact, the top command is actually a symbolic link (see last practical) to prstat. Run the top command with no options and consider the number of processes running, the memory usage, load average for example. You might like to try this at some other time in the week when a CS10110 practical is not running and look at the difference. Please don t leave top running for a long time because it creates significant load on the machine. Remember this top command, if you're ever using your own UNIX/Linux PC, and it seems to be going slow. Maybe there's a bad process that needs to be killed. You can obtain the list of processes sorted in various ways, for example cpu usage, memory usage and runtime. Try these options and notice the difference in the results. Think about why this is so and remember the difficult job the scheduler/dispatcher is performing! Logging in to other machines So far we have only been considering processes running on a single machine. Of course there are many machines on the network and you will sometimes want to run a process on another machine. Reasons for this may be because the licence for some item of software may only exist on certain machines, the files you need to process are not locally accessible, or simply because there is more processing power available elsewhere. You remote login using the ssh (secure shell) command followed by the machine you want to log in to. You should have access to the information services machine called central. When you ssh to another machine for the first time, you will be asked if you want to trust this connection. Just say yes. This adds an appropriate key to the file ~/.ssh/known_hosts, so that if in the future another machine should try to pretend to be central (and, say, try to grab your password), it will fail. It also says to the ssh program that you trust the computer central.aber.ac.uk. Page 3

ssh to central and have a look at all the processes you are running on that machine. How many are there? and what are they? Ask a demonstrator if this is not what you expected. ssh is the preferred way of logging in to a remote machine; older machines may not have ssh. rlogin is an alternative method, as is telnet. These are safe enough to use within a closed network such as the university, but for more security you should use ssh. Running a process on a remote machine without logging in ssh <machine name>, followed by a command, will run a command on the remote machine, then exit. Try it; for example, try listing your central filestore from Wiked or Minted by typing: ssh central.aber.ac.uk ls Running Graphical programs on a remote machine Try running a graphical program on the central machine (eg xeyes or xterm) either in your remote login or as an ssh. You will probably get an error. The problem is that the remote machine does not know which X server to use. In other words it doesn t know which screen on the network the command should talk to! You can tell it by setting the DISPLAY environment variable. Environment variables hold useful information used by the shell and programs run from it. You can inspect all your environment variables under the bash shell by using the set command with no options. Look at the environment variables available in the shell running on central and also the shell running on wiked or minted. You might know (or make an educated guess) what information a few of the variables store for example PATH, MANPATH, and CLASSPATH. Are they the same? Returning to the display problem: you can set the display for the shell running on central once you know what it is called. Of course minted knows this so you can type echo $DISPLAY in a shell running on minted to show the value of the DISPLAY variable being used for the X server display you are sat in front of (this was set automatically when you logged in) and it should respond with something like: myserver.dcs.aber.ac.uk:0.0 (if it says something like localhost:0.0 then substitute wiked.dcs.aber.ac.uk or minted.dcs.aber.ac.uk in place of localhost). To set an environment variable in a bash shell use the export command. To achieve our aim of telling the shell on central where our Xserver is you can use export DISPLAY=myserver.dcs.aber.ac.uk:0.0 (substitute the correct display name and server name!) Page 4

Now try running a graphical application on central say, xclock, xeyes 1 or xterm and you should see it appear on your screen. Make sure you know what you have this is a process running on central and being displayed by an Xserver running on your machine. Minted is running a window environment manager to allow you to control the display, for example if you wish to use a menu. You can use ssh to run remote graphical applications but you must also make the Xserver known to the remote program. The easiest way of doing this is to give the display option to the remote program. All X Windows programs allow you to specify a display parameter, for example xterm display myserver:0.0 Now you can use this to start up a program on a remote machine using ssh and have the GUI displayed on your screen. Try it now. eg. something like: Minted~$ ssh central xclock display myserver.dcs.aber.ac.uk:0.0 (remember to substitute the server name and display name.) In case you are wondering about the 0:0 bit, it is included because it is possible for an X server to have several display devices you will only be likely to use one number 0! ssh actually has a smarter way of doing this: ssh -X (or ssh -Y if that fails which sometimes it does because of authentication) automatically sets an appropriate DISPLAY environment variable for you (though it may not look right to you just now!), so that the display comes to your screen. Try: ssh -X central xclock Part 2 - MS Windows Task manager Log into MS Windows and start the task manager. This is normally done by pressing <CTRL> <ALT> <DEL> and selecting Task manager. Initially you will see a list of the user programs that are running. This list may well be empty if you have just logged in. The other tabs on the Task manager show you process information and a graphical display of CPU and network activity. The system activity over time can be observed using the performance tab. Have a look at the information on the lower part of the task manager performance window. How much of the RAM is used by the kernel? To see something happen, start an application such as Word or PowerPoint and watch the system processor and memory activity. For something a bit more demanding try opening a multimedia player such as Windows media player (try running the sample movie for example). The task manager can separate the CPU time spent executing kernel code from the rest. Select View show kernel times. It is informative to consider the amount of time being used by the OS against the time spent 1 You might find xeyes doesn't work on central. It's on Minted and Wiked though; try it! Page 5

executing all other software. During the rest of this practical look back at these ratios as you put the system through some tests and think about what sort of OS activity the tasks might be causing to happen. Start by checking out Media Player it has to do a lot of calculations to decode a movie and therefore tends to generate a lot of non-kernel activity since the OS is not required to do the decoding. Compare this with other programs you will run later in the practical. Go to the list of tasks and quit any application programs you are running (except task manager!). Look at the process list and see how many processes are left and who owns them. These are all the programs that need to be running for the OS to operate (memory managers, schedulers etc), as well as all the other services that most users don t realise they need until they stop working such as network services, printer spooling, the file manager explorer etc. Which process is taking most of the CPU time? Bearing in mind that a microprocessor must continuously process instructions what do you think this process is doing? (Some processors have special sleep modes to save power but this is a special case) You can view a wide range of parameters associated with each process. In the process window the view Select columns tab will let you add new information to the list. Add page faults, paged pool and non paged pool to the list you will know already that pages are part of the virtual memory mechanism however you will need to check the help to find out exactly what Windows is telling you with these measures. Compare the amount of virtual memory your system has to access with the size of the RAM. Other measures include the numbers of interrupts caused by various sorts of I/O. These can be useful for identifying system performance problems and are worth knowing about. Look for the processes that seem to cause very many or very few of the various interrupts, try several different types of application and look at their processes, for example the windows calculator versus Media Player. Process Hierarchy You can use the task manager to forcibly end a process. This is useful when a process is no longer responding to the normal interface commands, for example if the program has crashed. The end process option in the task manager will only kill the process requested and not any children of this process. Since many programs create child processes, killing the parent will leave errant processes running on the system (often not visible on the GUI). Ending a task or a process tree will remove a hierarchy of processes. We can investigate the difference by noting that when you run commands from the command prompt they are separate processes, and the command prompt shell process waits for the child to finish. Run a command that does not complete without user input such as dir more Page 6

(run in a directory with lots of files in it) and find the cmd and more processes in the task manager. Kill the more process and observe what happens. Run the command again and kill the cmd process. Now what happens? What about when you let the more command finish? Repeat the experiment and use the end process tree instead of end process. What happens in both cases? Why? Priority Do not do this part of the practical on our UNIX machines! On the course web page under practicals you will find with this worksheet two short java programs called BusyCounter.java and Counter.java. Place these programs somewhere where you can compile them (D: or M:). You need to compile these two programs. If you know how to do this then go ahead then skip the next paragraph. Open a command prompt and change to the directory containing the two programs. To compile them into executable code type: javac BusyCounter.java javac Counter.java If all is well you will get no error messages and a command prompt. You can now run the busy counter program by typing java BusyCounter To investigate the effect of priority you need to run two processes that both require as much processor time as they can get. This is what BusyCounter does. Run BusyCounter and check the effect it has on CPU load and other system resources. Remember, you're running this program on a PC to which only you are logged in. Please don't run this program on a machine where others may also be logged in (such as Minted or Central)! Since the command prompt is an MS DOS emulator it does not allow you to run more than one command (process). Consequently there is no concept of background processes. You can run two command prompt windows however. Run the BusyCounter program in both command prompt windows and make sure you can see their output. Now find the processes in the task manager, get the task manager to display the priority of processes and consider the two BusyCounters (they should both be normal priority and taking a considerable chunk of the CPU). Try setting one of them to low priority (right click on the process) and observe the effects on the system resources being used by that process. Check also how it is performing on the screen. You can try other combinations of priority and see the effects. Have a look at the priority levels of the rest of the processes that are running. What do you notice about some of the system processes? Be careful if you change any of the priority settings for these because you can make the system act very strangely especially if you still have BusyCounter trying to take as much CPU as it can get! Page 7

A System Friendly Counter Quit all the counter programs and make sure the system load reduces to a low level. Now run the Counter program and observe its output and CPU load. Now run BusyCounter again and observe processor load. Is there any effect on Counter? Why should the two programs that perform the same task have such a different effect on the system? Use an editor to have a look at the source code determine the differences in the way the code operates. This is an extreme example, but it illustrates the importance of design decisions, especially for event driven programs that need to wait for (user) input and other events. System Calls in your program Try removing the line that includes the delay loop (for statement) from BusyCounter and recompile it. Run it and look at the difference on resource usage. Do any other processes increase their resource use? Why might this be? (hint: look at kernel usage). What happens if you minimize the DOS window to the taskbar. Can you explain these effects from your knowledge of operating systems? ais, November 2010 Updated: mfc5, September 2012 Page 8