Last Updated on December 22, 2023 by Ankit Kochar
In the realm of operating systems, the phenomenon of thrashing represents a critical challenge that can significantly impact system performance. Thrashing occurs when a computer’s virtual memory system is overwhelmed, leading to excessive paging and a continuous, futile struggle to meet the demands of running processes. Understanding the causes, effects, and mitigation strategies for thrashing is crucial for system administrators and developers to maintain optimal operating system performance. This exploration delves into the intricacies of thrashing, shedding light on its implications and the strategies employed to address this disruptive phenomenon.
Small fixed-size chunks of the program are called pages and these pages are mapped to the frames in the main memory. Each program page has a fixed size that is equal to the frame size in the main memory. To realize the concept of virtual memory, we use demand paging, which includes loading a page containing the code that is currently required. A process is a program that is stored in the main memory. When a running process’s requested page is not present in the main memory, a page fault exception is elevated, requesting an IO operation (page fault service) to load the requested page from the secondary memory to the main memory.
What is Thrashing in Operating System
Thrashing in operating systems is a computing phenomenon that occurs when virtual memory is used. It occurs when a computer’s virtual memory rapidly exchanges data for data on the hard drive, to the exclusion of most application-level operations. If the CPU spends more time serving page faults than executing pages, the process is said to be thrashing. This results in low CPU utilization, and the operating system responds by attempting to increase the degree of multiprogramming.
Following the visualization of the graphical representation
The underlying idea is that if a process is given too few frames, too many and frequent page faults will occur. As a result, the CPU would do no useful work and CPU utilization would plummet significantly.
The long-term scheduler would then try to improve CPU usage by loading more processes into memory, thereby increasing the degree of multiprogramming. Unfortunately, this would result in even lower CPU utilization, which would set off a chain reaction of larger page faults, followed by an increase in the degree of multiprogramming, a phenomenon known as Thrashing.
Page Replacement Algorithms and Effect of Thrashing
To deal with page faults, the operating system uses either the global frames replacement algorithm or the local frames replacement algorithm to bring in enough pages in the main memory. Let’s see how these replacement algorithms affect thrashing.
1. Global Page Replacement
The Global Page replacement has the ability to bring any page, and once Thrashing in the operating system is detected, it attempts to bring more pages. As a result, no process can acquire enough frames, and the thrashing in the operating system worsens. To summarise, when Thrashing occurs in the operating system, the global page replacement technique is ineffective.
2. Local Page Replacement
In contrast to the Global Page Replacement, the Local Page Replacement will select pages that are part of that process. As a result, there is a chance that the operating system’s thrashing will be reduced. As previously demonstrated, there are several disadvantages to using Local Page replacement. As a result, local page replacement is simply an alternative to global page replacement.
Causing of Thrashing in OS
Thrashing in the operating system has an effect on the execution performance of the operating system. Furthermore, thrashing degrades the operating system’s performance.
When CPU usage is low, the process scheduling mechanism attempts to load many processes into memory, increasing the degree of Multiprogramming. In this case, there are more processes in memory than there are memory frames available. When a high-priority process enters memory, if the frame is not already occupied by another process, the other process will be moved to secondary storage, and the free frame will be assigned to a higher-priority process.
How to Overcome Thrashing in OS?
Thrashing in the OS is harmful to hard disc health and system performance. As a result, some precautions are required. Thrashing in the operating system can be avoided by allocating as many frames as each process requires during execution. A process’s number of frames can be determined using the locality model. A locality is a grouping of pages that are commonly used together. A process switches from one locality to another during execution, and these localities may overlap, according to the locality model. We must provide a process with enough frames to prevent page faulting in the current location. The Working-set model goes into greater detail on this.If the system is already thrashing, the process scheduler can be told to stop some of the processes.
Technique to Prevent Thrashing in OS
Given below are the Techniques to prevent thrashing in OS:
1) Working Set Model
This model is based on the above-mentioned Locality Model concept.
The basic principle states that if we give a process enough frames to accommodate its current locality, it will only fail when it moves to a new locality. However, if the allocated frames are smaller than the size of the current locality, the process will thrash.
According to this model, the working set is defined as the set of pages in the most recent ‘A’ page references based on parameter A. As a result, all actively used pages would always become a part of the working set. The working set’s accuracy is determined by the value of parameter A. Working sets may overlap if A is too large. However, for smaller values of A, the locality may not be completely covered.
If D represents the total demand for frames and WSSi represents the working set size for the process I then
D = ⅀ WSSiIf’m’ is the number of frames available in memory, there are two options:
When D>m, i.e., total demand exceeds the number of frames, thrashing occurs because some processes do not receive enough frames.
If D<=m, there would be no thrashing.
More processes can be loaded into memory if there are enough extra frames. However, if the sum of working set sizes exceeds the availability of frames, some processes must be suspended (swapped out of memory).
This method prevents thrashing while also ensuring the greatest degree of multiprogramming possible. As a result, it optimises CPU utilisation.
2) Page Fault Frequency
The Page-Fault Frequency concept is a more direct approach to dealing with thrashing.
The high page fault rate is associated with thrashing, so the concept here is to control the page fault rate.
If the page fault rate is too high, it indicates that the process is receiving too few frames. A low page fault rate, on the other hand, indicates that the process has too many frames.
As shown in the diagram, upper and lower limits on the desired page fault rate can be set.
Frames can be removed from the process if the page fault rate falls below the lower limit. Similarly, if the rate of page faults exceeds the maximum, more frames can be allocated to the process.
In other words, the system's graphical state should be restricted to the rectangular region defined by the given diagram.If the page fault rate is high and there are no available frames, some processes can be suspended and the resources allocated to them reallocated to other processes. The suspended processes can be resumed at a later time.
Conclusion
In conclusion, thrashing poses a significant challenge in the realm of operating systems, impacting system performance and user experience. Understanding the factors that contribute to thrashing and implementing effective mitigation strategies are crucial for maintaining a stable and responsive computing environment. System administrators and developers must stay vigilant, employing proactive measures to monitor system performance and address the root causes of thrashing to ensure optimal operation and resource utilization.
Frequently Asked Questions(FAQs) related to Thrashing in OS
Here are some FAQs on thrashing in os :
1. What is thrashing in the context of operating systems?
Thrashing is a situation in an operating system where excessive paging activity occurs, leading to a severe decline in system performance. It typically happens when the system is overwhelmed by the demand for more memory than is physically available, causing the operating system to spend a significant amount of time swapping data between the RAM and the disk.
2. What causes thrashing in an operating system?
Thrashing is often caused by a high degree of multiprogramming or excessive demand for memory by running processes. When the system attempts to satisfy the demands of too many processes simultaneously, and the sum of their memory requirements exceeds the available physical memory, constant page swapping occurs, resulting in thrashing.
3. How can one detect thrashing in an operating system?
Signs of thrashing include a sudden and severe decline in system performance, a spike in the disk activity related to paging, and a decrease in the throughput of the CPU. Monitoring tools, such as performance counters or system resource usage metrics, can help detect the onset of thrashing.
4. What are the consequences of thrashing on system performance?
Thrashing leads to a significant degradation in system performance as the excessive paging activity consumes valuable CPU cycles and disk I/O bandwidth. This results in slower response times for user applications, increased latency, and an overall decline in the system's ability to execute processes efficiently.
5. How can thrashing be mitigated in an operating system?
Mitigating thrashing involves addressing the root causes, such as reducing the degree of multiprogramming, optimizing the memory allocation strategy, or adding more physical memory to the system. Additionally, employing efficient page replacement algorithms, like the Least Recently Used (LRU) algorithm, can help alleviate thrashing by making intelligent decisions about which pages to keep in physical memory