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 Management Evaluating 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 Management Evaluating an Operating System
An Operating system’s strengths and 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 Management Cooperation 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 Management Cooperation 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 Management Cooperation 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 Management Role 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 Management Role 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 Management Role 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 Management Role 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 Management Role 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 CPU overhead 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 Management Role 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 Management Role 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 CPU and the I/O device must be weighed against the time it would take to execute the reordering algorithm.
Understanding Operating Systems, Sixth Edition

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

16. System Management Role 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: = 105 ms (Figure 12.2)
Understanding Operating Systems, Sixth Edition

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

18. System Management Role 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 : = 65 ms (Figure 12.3)
Understanding Operating Systems, Sixth Edition

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

20. System Management Role 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 ( ), 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 Management Role 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 Management Role 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 Management Role 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 Management Role 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 Management Role 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 Management Role 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 Management Role of File Management
File management related to device where files stored
Understanding Operating Systems, Sixth Edition

28. System Management Role 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 Management Role 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 Management Role of Network Management
The Network Manager also simplifies the process of updating data files and programs 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 Management Measuring System Performance
Total system performance can be defined as the efficiency with which a computer system meets 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 Performance Measurement 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 Performance Measurement 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 Performance Measurement 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 Performance Measurement 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 Performance Measurement Tools
Resource utilization
A measure of how much each unit is contributing to the overall operation.
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 Performance Measurement 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 Performance Measurement 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 it back in service.
Understanding Operating Systems, Sixth Edition

39. Measuring System Performance Measurement 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 = =
Understanding Operating Systems, Sixth Edition

40. Measuring System Performance Measurement 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 Performance Measurement 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 =
Understanding Operating Systems, Sixth Edition

42. Measuring System Performance Measurement 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 Performance Feedback 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 Performance Feedback 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 Performance Feedback Loops
Understanding Operating Systems, Sixth Edition

46. Measuring System Performance Feedback 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 Performance Feedback Loops
Understanding Operating Systems, Sixth Edition

48. Measuring System Performance Feedback 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 Performance Feedback 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 Performance Feedback 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

51. Measuring System Performance Patch Management
The systematic updating of the operating system and other system software.
A patch is a piece of programming code that replaces or changes code that make up the software.
Understanding Operating Systems, Sixth Edition

52. Measuring System Performance Patch Management
There are three primary reasons for the emphasis on software patches for sound system administration:
The need for vigilant security precautions against constantly changing system threats;
The need to assure system compliance with government regulations regarding privacy and financial accountability;
The need to keep systems running at peak efficiency.
Understanding Operating Systems, Sixth Edition

53. Measuring System Performance Patch Management
The task of keeping computing systems patched correctly has become a challenge because of the complexity of the entire system:
(The OS, network, various platforms, remote users);
The speed with which software vulnerabilities are exploited by worms, viruses, and other system assaults.
Overall responsibility lies with the CIO, the CSO, the network administrator or individual users.
It is only through rigorous patching that the system’s resources can reach top performance, and its information can be best protected.
Understanding Operating Systems, Sixth Edition

54. Measuring System Performance Patch Management
Manual and automatic patch technologies
Among top eight used by organizations
Understanding Operating Systems, Sixth Edition

55. Patch Management Patching Fundamentals
While the installation of the patch is the most public event, there are several essential steps that take place before that happens:
Identify the required patch;
Verify the patch’s source and integrity;
Test the patch in a safe environment;
Deploy the patch throughout the system;
Audit the system to gauge the success of the patch deployment.
Understanding Operating Systems, Sixth Edition

56. Patch Management Patching Fundamentals
All changes to the OS or other critical system must be undertaken in an environment that makes regular system backups, and tests restoration from backups.
Understanding Operating Systems, Sixth Edition

57. Patch Management Patching Fundamentals
Patch availability
Identify the criticality of the patch.
If the patch is critical it should be applied ASAP.
If the patch is not critical, you might choose to delay installation until a regular patch cycle begins.
Patch integrity
Authentic patches will have a digital signature or patch validation tool.
Before applying a patch, validate the digital signature used by the vendor to send the new software.
Understanding Operating Systems, Sixth Edition

58. Patch Management Patching Fundamentals
Patch testing
Before installation on a live system, test the new patch on a sample system or an isolated machine (development system) to verify its worth.
Tests
Test to see if the system restarts after the patch is installed.
Check to see if the patched software performs its assigned tasks.
The tested system should resemble the complexity of the target system as closely as possible.
Test the contingency plans to uninstall the patch and recover the old software if it becomes necessary to do so.
Understanding Operating Systems, Sixth Edition

59. Patch Management Patching Fundamentals
Patch deployment
Single-user computer
Install the software and reboot the computer.
Multiplatform system (many users)
Exceptionally complicated task
Maintain an accurate inventory of all hardware and software on those computers that need the patch.
On a large network, this information can be gleaned from network mapping software that surveys the network and takes a detailed inventory of the system.
Because its impossible to use the system during the patching process, schedule the patch deployment when system use is low (evenings or weekends).
Understanding Operating Systems, Sixth Edition

60. Patch Management Patching Fundamentals
Audit finished system
Confirm that the resulting system meets expectations:
Verify that all computers are patched correctly and perform fundamental tasks as expected.
Verify that no users had unexpected or unauthorized versions of software that may not accept the patch.
Verify that no users are left out of the deployment.
This process should include documentation of the changes made to the system and the success or failure of each stage of the process.
Get feedback from the users to verify the deployment’s success.
Understanding Operating Systems, Sixth Edition

61. Patch Management Software Options
Patches can be installed manually, one at a time, or via software that’s written to perform the task automatically.
Deployment software falls into two groups:
Those programs that require an agent (agent-based software);
Those programs that do not (agentless software).
Understanding Operating Systems, Sixth Edition

62. Patch Management Software Options
If the deployment software uses an agent (software that assists in patch installation):
The agent software must be installed on every target computer system before patches can be deployed.
On a very large or dynamic system, this can be a daunting task.
For administrators of large, complex networks, agentless software may offer some time-saving efficiencies.
Understanding Operating Systems, Sixth Edition

63. Patch Management Timing The Patch Cycle
While critical system patches must be applied immediately, less-critical patches can be scheduled at the convenience of the systems group.
These patch cycles can be based on calendar events or vendor events.
The advantage of having routine patch cycles is that they allow for thorough review of the patch and testing cycles before deployment.
Understanding Operating Systems, Sixth Edition

64. Measuring System Performance System Monitoring
Several techniques for measuring the performance of a working system have been developed as computer systems have evolved, which can be implemented using either hardware or software components.
Hardware monitors
More expensive but they have the advantage of having a minimum impact on the system because they’re outside of it and attached electronically.
Examples: Hard-wired counters, clocks, comparative elements.
Understanding Operating Systems, Sixth Edition

65. Measuring System Performance System Monitoring
Software monitors
Relatively inexpensive.
Because they become part of the system, they can distort the results of the analysis.
The software must use the resources it’s trying to monitor.
Software tools must be developed for each specific system, so it’s difficult to move them from system to system.
In early systems, performance was measured simply by timing the processing of specific instructions.
The system analysis might have calculated the number of times an ADD instruction could be done in one second.
Understanding Operating Systems, Sixth Edition

66. Measuring System Performance System Monitoring
They might have measured the processing time of a typical set of instructions.
These measurements monitored only the CPU speed because in those days the CPU was the most important resource, so the remainder of the system was ignored.
Today, system measurements must include the other hardware units as well as the OS, compilers, and other system software.
Measurements are made in a variety of ways.
Some are made using real programs, usually production programs that are used extensively by the users of the system, which are run with different configurations of CPUs, OS, and other components.
Understanding Operating Systems, Sixth Edition

67. Measuring System Performance System Monitoring
The results are called benchmarks and are useful when comparing systems that have gone through extensive changes.
Benchmarks are often used by vendors to demonstrate to prospective clients the specific advantages of a new CPU, OS, compiler, or piece of hardware.
Benchmark results are highly dependent upon:
The system’s workload;
The system’s design and implementation;
The specific requirements of the applications loaded on system.
Understanding Operating Systems, Sixth Edition

68. Measuring System Performance System Monitoring
Performance data is usually obtained in a rigorously controlled environment so results will probably differ in real-life operation.
Benchmarks offer valuable comparison data.
A place to begin a system evaluation.
If it’s not possible to experiment with the system itself, a simulation model can be used to measure performance.
A simulation model is a computerized abstraction of what is represented in reality.
The amount of detail built into the model is dictated by time and money.
Understanding Operating Systems, Sixth Edition

69. Measuring System Performance Accounting
The accounting function pays the bills and keeps the system financially operable.
Most computer system resources are paid for by the users.
In a single-user environment, it’s easy to calculate the cost of the system.
In a multiuser environment, computer costs are usually distributed among users based on how much each one uses the system’s resources.
Understanding Operating Systems, Sixth Edition

70. Measuring System Performance Accounting
To do this distribution, the OS must be able to:
Set up user accounts
Assign passwords
Identify which resources are available to each user
Define quotas for available resources (disk space or maximum CPU time allowed per job).
Understanding Operating Systems, Sixth Edition

71. Measuring System Performance Accounting
Pricing policies vary from system to system. Typical measurements include some or all of the following:
Total amount of time spent between job submission and completion. In interactive environments this is the time from logon to logoff (connect time).
CPU time is the time spent by the processor executing the job.
Main memory usage is represented in units of time, bytes of storage, or bytes of storage multiplied by units of time.
Understanding Operating Systems, Sixth Edition

72. Measuring System Performance Accounting
Pricing policy measurements
A job that requires 200K for 4 seconds followed by 120K for 2 seconds could be billed for 6 seconds of main memory usage, or 320K of memory usage or a combination of K/second of memory usage. [(200 * 4) + (120* 2)] = 1040K/second of memory usage
Secondary storage used during program execution, like main memory use, can be given in units of time, or space or both.
Secondary storage used during billing period is usually given in terms of the number of disk tracks allocated.
Understanding Operating Systems, Sixth Edition

73. Measuring System Performance Accounting
Pricing policy measurements
Use of system software includes utility packages, compilers, and/or databases.
Number of I/O operations is usually grouped by device class (line printer, terminal, disks).
Time spent waiting for I/O completion
Number of input records read usually grouped by type of input device.
Number of output records printed usually grouped by type of output device.
Number of page faults is reported in paging systems.
Understanding Operating Systems, Sixth Edition

74. Measuring System Performance Accounting
Pricing policies are sometimes used as a way to achieve specific operational goals.
By varying the price of system services, users can be convinced to distribute their workload to the system manager’s advantage.
By offering reduced rates during off-hours, some users might be persuaded to run long jobs in batch mode inexpensively overnight instead of interactively during peak hours.
Pricing incentives can also be used to encourage users to access more plentiful and cheap resources rather than those that are scarce and expensive.
By putting a high price on printer output, users might be encouraged to order a minimum of printouts.
Understanding Operating Systems, Sixth Edition

75. Measuring System Performance Accounting
Should the system give each user billing information at the end of each job or at the end of each online session?
Depends on the environment
Some systems only give information on resource usage.
Other systems also calculate the price of the most costly items (CPU utilization, disk storage use, supplies) at the end of each job.
This gives the user an up-to-date report of expenses and calculates how much is left in the user’s account.
Understanding Operating Systems, Sixth Edition

76. Measuring System Performance Accounting
The advantage of maintaining billing records online is that the status of each user can be checked before the user’s job is allowed to enter the READY state.
The disadvantage is overhead.
When billing records are kept online and an accounting program is kept active:
Memory space is used
CPU processing is increased.
One compromise is to defer the accounting program until off-hours, when the system is lightly loaded.
Understanding Operating Systems, Sixth Edition

77. Summary
The OS is more than the sum of its parts – it’s the orchestrated cooperation of every piece of hardware and every piece of software.
When one part of the system is favored, it’s often at the expense of the others.
The system’s managers must make sure they’re using the appropriate measurement tools and techniques to verify the effectiveness of the system before and after modification and then evaluate the degree of improvement.
Understanding Operating Systems, Sixth Edition