Understanding Operating Systems Sixth Edition

1. Understanding Operating Systems Sixth Edition Chapter 12 System Management

2. Learning Objectives After completing this chapter, you should be able to describe: • The tradeoffs to be considered when attempting to improve overall system performance • The roles of system measurement tools such as positive and negative feedback loops • Two system monitoring techniques • The fundamentals of patch management • The importance of sound accounting practices by system administrators Understanding Operating Systems, Sixth Edition

3. System ManagementEvaluating an Operating System • Most OSs were designed to work with a certain piece of hardware, a category of processors, or specific groups of users. • Although most evolved over time to operate multiple systems, most still favor some users and some computing environments over others. • To evaluate an OS, you need to know: • Its design goals and history; • How it communicates with its users; • How its resources are managed; • What tradeoffs were made to achieve its goals. Understanding Operating Systems, Sixth Edition

4. System ManagementEvaluating an Operating System • An Operating system’s strengthsand weaknesses need to be weighed in relation to: • Who will be using the operating system; • On what hardware; • For what purpose. Understanding Operating Systems, Sixth Edition

5. System ManagementCooperation Among Components • The performance of any one resource depends on the performance of the other resources in the system. • Memory management is intrinsically linked with device management when memory is used to buffer data between a very fast processor and slower secondary storage devices. Understanding Operating Systems, Sixth Edition

6. System ManagementCooperation Among Components • If you managed an organization’s computer system and were allocated money to upgrade it, where would you put the investment to best use? • A faster CPU • Additional processors • More disk drives • A RAID system • New file management software • Or, if you bought a new system, what characteristics would you look for that would make it more efficient than the old one? Understanding Operating Systems, Sixth Edition

7. System ManagementCooperation Among Components • Any system improvement can be made only after extensive analysis of: • The needs of the system’s resources; • Requirements; • Managers; • Users. • Whenever changes are made to a system, often you’re trading one set of problems for another. • The key is to consider the performance of the entire system and not just the individual components. Understanding Operating Systems, Sixth Edition

8. System ManagementRole of Memory Management • Memory management schemes were discussed in Chapters 2 and 3. • If you increase memory or change to another memory allocation scheme, you must consider the actual operating environment in which the system will reside. • There’s a trade-off between memory use and CPU overhead. • As the memory algorithms grow more complex, the CPU overhead increases and overall performance can suffer. • However, some OS perform remarkably better with additional memory. Understanding Operating Systems, Sixth Edition

9. System ManagementRole of Processor Management • Processor management was covered in Chapters 4,5, and 6. • If you decide to implement a multiprogramming system to increase your processor’s utilization: • You’d have to remember that multiprogramming requires a great deal of synchronization between: • The Memory Manager; • The Processor Manager; • The I/O devices. Understanding Operating Systems, Sixth Edition

10. System ManagementRole of Processor Management • The tradeoff: • Better use of the CPU versus increased overhead; • Slower response time; • Decreased throughput. • Problems to watch for: • A system could reach a saturation point if the CPU is fully utilized but is allowed to accept additional jobs. • This would result in higher overhead and less time to run programs. Understanding Operating Systems, Sixth Edition

11. System ManagementRole of Processor Management • Problems to watch for: • Under heavy loads, the CPU time required to manage I/O queues (which under normal circumstances don’t require a great deal of time) could dramatically increase the time required to run jobs. • With long queues forming at the channels, control units, and I/O devices, the CPU could be idle waiting for processes to finish their I/O. • Likewise, increasing the number of processors necessarily increases the overhead required to manage multiple jobs among multiple processors. • The payoff can be faster turnaround time. Understanding Operating Systems, Sixth Edition

12. System ManagementRole of Device Management • Device management, covered in Chapter 7, contains several ways to improve I/O device utilization including: • Blocking, buffering, and rescheduling I/O requests to optimize access time. • Tradeoffs • Each of these options also increases CPUoverhead and uses additional memory space. • Blocking • Reduces the number of physical I/O requests (good). • But it’s the CPU’s responsibility to block and later. deblock the records, and that’s overhead (bad). Understanding Operating Systems, Sixth Edition

13. System ManagementRole of Device Management • Buffering • Helps the CPU match slower I/O device speeds and vice versa, but it requires memory space for the buffers, either dedicated space or a temporarily allocated section of main memory • This reduces the level of processing that can take place. • Tradeoff • Reduced multiprogramming versus better use of I/O devices. Understanding Operating Systems, Sixth Edition

14. System ManagementRole of Device Management • Rescheduling requests • A technique that can help optimize I/O times; • It’s a queue reordering technique. • It’s also an overhead function so the speed of both the CPUand the I/O device must be weighed against the time it would take to execute the reorderingalgorithm. Understanding Operating Systems, Sixth Edition

15. System ManagementRole of Device Management Understanding Operating Systems, Sixth Edition

16. System ManagementRole of Device Management • Let’s assume that a system consisting of CPU1 and Disk Drive A has to access Track 1, Track 9, Track 1, and then Track 9 and the arm is already located at Track 1. • Without reordering, Drive A requires approximately 35 ms for each access:35 + 25 + 35 = 105 ms (Figure 12.2) Understanding Operating Systems, Sixth Edition

17. System ManagementRole of Device Management • Example: without reordering • CPU 1 and disk drive A • Access track 1, track 9, track 1, track 9 • Arm already locatedat track 1 Understanding Operating Systems, Sixth Edition

18. System ManagementRole of Device Management • After reordering (which requires 30 ms), the arm can perform both accesses on Track 1 before traveling, in 35 ms, to Track 9 for the other two accesses, resulting in a speed nearly twice as fast :30 + 35 = 65 ms (Figure 12.3) Understanding Operating Systems, Sixth Edition

19. System ManagementRole of Device Management • Example: after reordering • Arm performs both accesses on Track1 before traveling Track 9 (35 ms) Understanding Operating Systems, Sixth Edition

20. System ManagementRole of Device Management • However, when the same situation is faced by CPU 1 and the much faster Disk Drive C, we find the disk will again begin at Track 1 and make all four accesses in 15 ms (5 + 5 + 5), but when it stops to reorder these accesses (which requires 30 ms), it takes 35 ms (30 + 5) to complete the task. • Therefore, reordering requests not always warranted. Understanding Operating Systems, Sixth Edition

21. System ManagementRole of Device Management • Remember that when the system is configured, the reordering algorithm is either always on or always off. • It can’t be changed by the systems operator without reconfiguration, so the initial setting, on or off, must be determined by evaluating the system based on average system performance. Understanding Operating Systems, Sixth Edition

22. System ManagementRole of File Management • The discussion of file management in Chapter 8 looked at how secondary storage allocation schemes help the user organize and access the files on the system. • Almost every factor discussed in that chapter can affect overall system performance. • File organization is an important consideration. • If a file is stored noncontiguously and has several sections residing in widely separated cylinders of a disk pack, sequentially accessing all of its records could be a time-consuming task. Understanding Operating Systems, Sixth Edition

23. System ManagementRole of File Management • Such a case would suggest that the files should be compacted (defragmented) so each section of the file resides near the others. • Recompaction, however, takes CPU time and makes the files unavailable to users while it’s being done. • Another file management issue that could affect retrieval time is the location of a volume’s directory. • Some systems read the directory into main memory and hold it there until the user terminates the session. Understanding Operating Systems, Sixth Edition

24. System ManagementRole of File Management • Looking at Figure 12.1: • The first retrieval would take 35 ms when the system retrieves the directory for Drive A and loads it into memory. • Every subsequent access would be performed at the CPU’s much faster speed without the need to access the disk. • This poses a problem if the system crashes before any modifications have been recorded permanently in secondary storage. • The I/O time that was saved by not having to access secondary storage every time the user requested to see the directory would be negated by not having current information in the user’s directory. Understanding Operating Systems, Sixth Edition

25. System ManagementRole of File Management • Similarly, the location of a volume’s directory on the disk might make a significant difference in the time it takes to access it. • If the directories are stored on the outermost track, then the disk drive arm has to travel farther to access each file than it would if the directories were kept in the center tracks. • File management is closely related to the device on which the files are stored. • Designers must consider both issues at the same time when evaluating or modifying computer systems. Understanding Operating Systems, Sixth Edition

26. System ManagementRole of File Management • Different schemes offer different flexibility, but the trade-off for increased file flexibility is increased CPU overhead. Understanding Operating Systems, Sixth Edition

27. System ManagementRole of File Management • File management related to device where files stored Understanding Operating Systems, Sixth Edition

28. System ManagementRole of Network Management • The discussion if network management in Chapters 9 and 10 examined the impact of adding networking capability to the OS and the overall effect on the system performance. • The Network Manager: • Routinely synchronizes the load among remote processors; • Determines message priorities; • Tries to select the most efficient communication paths over multiple data communication lines. Understanding Operating Systems, Sixth Edition

29. System ManagementRole of Network Management • When an application program requires data from a disk drive at a different location, the Network Manager attempts to provide this service seamlessly. • When networked devices (printers, plotters, disk drives) are required, the Network Manager has the responsibility of allocating and deallocating the required resources correctly. • In addition, the Network Manager allows a network administrator to monitor the use of individual computers and shared hardware, and ensure compliance with software license agreements. Understanding Operating Systems, Sixth Edition

30. System ManagementRole of Network Management • The Network Manager also simplifies the process of updating data files andprograms on networked computers by coordinating changes through a communications server instead of making the changes on each individual computer. Understanding Operating Systems, Sixth Edition

31. System ManagementMeasuring System Performance • Total system performance can be defined as the efficiency with which a computer systemmeets its goals – how well it serves its users. • System efficiency is affected by three major components: • User programs • Operating system programs • Hardware • In addition, system performance can be very subjective and difficult to quantify. • How can anyone objectively gauge ease of use. Understanding Operating Systems, Sixth Edition

32. Measuring System PerformanceMeasurement Tools • Throughput • A composite measure that indicates the productivity of the system as a whole. • Usually measured under steady-state conditions and reflects quantities such as : • The number of jobs processed per day; • The number of online transactions handled per hour. • Can also be a measure of the volume of work handled by one unit of the computer system. • An isolation that’s useful when analysts are looking for bottlenecks in the system. Understanding Operating Systems, Sixth Edition

33. Measuring System PerformanceMeasurement Tools • Capacity • Bottlenecks tend to develop when resources reach their capacity (maximum throughput level). • Thrashing is a result of a saturated disk. • Bottlenecks also occur when main memory has been overcommitted and the level of multiprogramming has reached a peak point. • The working sets for the active jobs can’t be kept in main memory, so the Memory Manager is continuously swapping pages between main memory and secondary storage. Understanding Operating Systems, Sixth Edition

34. Measuring System PerformanceMeasurement Tools • Capacity • Throughput and capacity can be monitored by either hardware or software. • Bottlenecks can be detected by monitoring the queues forming at each resource. • When a queue starts to grow rapidly, this is an indication that the arrival rate is greater than, or close to, the service rate and the resource is saturated. • Feedback Loop. • Once a bottleneck is detected, the appropriate action can be taken to resolve the problem. Understanding Operating Systems, Sixth Edition

35. Measuring System PerformanceMeasurement Tools • Response time (Online Interactive Users) • An important measure of system performance. • The interval required to process a user’s request: • From when the user presses the key to send the message until the system indicates receipt of the message. • Turnaround time (Batch Jobs) • The time from the submission of a job until its output is returned to the user. • Whether in an online or batch context, this measure depends on both the workload being handled by the system at the time of the request and the type of job or request being submitted. Understanding Operating Systems, Sixth Edition

36. Measuring System PerformanceMeasurement Tools • Resource utilization • A measure of how much each unit is contributing to the overalloperation. • Usually given as a percentage of time that a resource is actually in use. • CPU busy 60 percent of the time • The line printer busy 90 percent of the time • Terminal usage? • Seek mechanism on a disk? • This data helps determine whether there is balance among the units of a system or whether a system is I/O-bound or CPU-bound. Understanding Operating Systems, Sixth Edition

37. Measuring System PerformanceMeasurement Tools • Availability • Indicates the likelihood that a resource will be ready when a user needs it. • For online Users, it may mean the probability that a port is free or a terminal is available when they attempt to log on. • for those already on the system, it may mean the probability that one or several specific resources will be ready when their programs make requests. • A unit will be operational and not out of service when a user needs it. Understanding Operating Systems, Sixth Edition

38. Measuring System PerformanceMeasurement Tools • Availability • Is Influenced by two factors: • Mean time between failures (MTBF) • The average time that a unit is operational before it breaks down. • Mean time to repair (MTTR) • The average time needed to fix a failed unit and put itback in service. Understanding Operating Systems, Sixth Edition

39. Measuring System PerformanceMeasurement Tools • If you buy a terminal with an MTBF of 4,000 hours (Number given by the manufacturer), and you plan to use it for 4 hours a day for 20 days a month (or 80 hours per month), then you would expect it to fail every 50 months (4,000/80). • Assuming the MTTR is 2 hours: Availability (A) = Availability = 4000 = 0.9995 4000 + 2 Understanding Operating Systems, Sixth Edition

40. Measuring System PerformanceMeasurement Tools • On average, this unit would be available 9,995 out of every 10,000 hours. • Five failures out of 10,000 uses. Understanding Operating Systems, Sixth Edition

41. Measuring System PerformanceMeasurement Tools • Reliability • Similar to availability. • Measures the probability that a unit will not fail during a given time period (t) • It’s a function of MTBF • If you absolutely need to use the terminal for the 10 minutes before your upcoming deadline. • With time expressed in hours, the unit’s reliability is = 0.9999584 Understanding Operating Systems, Sixth Edition

42. Measuring System PerformanceMeasurement Tools • Performance measures can’t be taken in isolation from the workload being handled by the system unless you’re simply fine-tuning a specific portion of the system. • Overall system performance varies from time to time, so it’s important to define the actual working environment before making generalizations. Understanding Operating Systems, Sixth Edition

43. Measuring System PerformanceFeedback Loops • To prevent the processor from spending more time doing overhead than executing jobs, the OS must continuously monitor the system and feed this information to the Job Scheduler. • The Scheduler can either allow more jobs to enter the system or prevent new jobs from entering until some of the congestion has been relieved. • A Feedback Loop • It can be either negative or positive. Understanding Operating Systems, Sixth Edition

44. Measuring System PerformanceFeedback Loops • Negative feedback loop • Monitors the system and, when it becomes too congested, signals the Job Scheduler to slow down the arrival rate of the processes (Figure 12.4). • A negative feedback loop monitoring I/O devices would inform the Device Manager that Printer 1 has too many jobs in its queue, causing the Device Manager to direct all newly arriving jobs to Printer 2, which isn’t as busy. • The negative feedback helps stabilize the system and keeps queue lengths close to expected mean values. Understanding Operating Systems, Sixth Edition

45. Measuring System PerformanceFeedback Loops Understanding Operating Systems, Sixth Edition

46. Measuring System PerformanceFeedback Loops • Positive feedback loop • Monitors the system, and when the system becomes underutilized, causes the arrival rate to increase.(Figure 12.5). • Used in paged virtual memory systems • Must be used cautiously because they’re more difficult to implement than negative loops. Understanding Operating Systems, Sixth Edition

47. Measuring System PerformanceFeedback Loops Understanding Operating Systems, Sixth Edition

48. Measuring System PerformanceFeedback Loops • Positive feedback loop • How it works: • The positive feedback loop informs the Job Scheduler that the CPU is underutilized. • The Scheduler allows more jobs to enter the system to give more work to the CPU. • As more jobs enter, the amount of main memory allocated to each job decreases. • If too many jobs are allowed to enter the system, the result can be an increase in page faults • This may cause the CPU to deteriorate. • The monitoring mechanisms for positive feedback loops must be designed with great care. Understanding Operating Systems, Sixth Edition

49. Measuring System PerformanceFeedback Loops • Positive feedback loop • An algorithm for a positive feedback loop should monitor the effect of new arrivals in two places: • The Processor Manager’s control of the CPU; • The Device Manager’s read and write operations. • Both areas experience the most dynamic changes, which can lead to unstable conditions. • Such an algorithm should check to see whether the arrival produces the anticipated result and whether system performance is actually improved. Understanding Operating Systems, Sixth Edition

50. Measuring System PerformanceFeedback Loops • Positive feedback loop • If the arrival causes performance to deteriorate, then the monitoring algorithm could cause the OS to adjust its allocation strategies until a stable mode of operation has been reached again. Understanding Operating Systems, Sixth Edition