C語言中文網
首頁 > 編程筆記 > 操作系統筆記 閱讀:788

什么是系統抖動,系統抖動及解決方法詳解

如果低優先級進程所分配的幀數低于計算機體系結構所需的最小數量,那么必須暫停該進程執行。然后,應調出它的所有剩余頁面,以便釋放所有分配的幀。這個規定引入了中級 CPU 調度的換進換出層。

事實上,需要研究一下沒有“足夠”幀的進程。如果進程沒有需要支持活動使用頁面的幀數,那么它會很快產生缺頁錯誤。此時,必須置換某個頁面。然而,由于它的所有頁面都在使用中,所以必須立即置換需要再次使用的頁面。因此,它會再次快速產生缺頁錯誤,再一次置換必須立即返回的頁面,如此快速進行。

這種高度的頁面調度活動稱為抖動。如果一個進程的調頁時間多于它的執行時間,那么這個進程就在抖動。

系統抖動的原因

抖動導致嚴重的性能問題??紤]以下場景,這是基于早期調頁系統的實際行為。

操作系統監視 CPU 利用率。如果 CPU 利用率太低,那么通過向系統引入新的進程來增加多道程度。采用全局置換算法會置換任何頁面,而不管這些頁面屬于哪個進程。

現在假設進程在執行中進入一個新階段,并且需要更多的幀。它開始出現缺頁錯誤,并從其他進程那里獲取幀。然而,這些進程也需要這些頁面,因此它們也會出現缺頁錯誤,并且從其他進程中獲取幀。這些缺頁錯誤進程必須使用調頁設備以將頁面換進和換出。當它們為調頁設備排隊時,就緒隊列清空。隨著進程等待調頁設備,CPU 利用率會降低。

CPU 調度程序看到 CPU 利用率的降低,進而會增加多道程度。新進程試圖從其他運行進程中獲取幀來啟動,從而導致更多的缺頁錯誤和更長的調頁設備隊列。因此,CPU 利用率進一步下降,并且 CPU 調度程序試圖再次增加多道程度。這樣就出現了抖動,系統吞吐量陡降,缺頁錯誤率顯著增加。結果,有效內存訪問時間增加,沒有工作可以完成,因為進程總在忙于調頁。

系統抖動
圖 1 系統抖動

這種現象如圖 1 所示,這里 CPU 利用率是按多道程度來繪制的。隨著多道程度的增加,CPU 利用率也增加,雖然增加得更慢,直到達到最大值。如果多道程度還要進一步增加,那么系統抖動就開始了,并且 CPU 利用率急劇下降。此時,為了提高 CPU 利用率并停止抖動,必須降低多道程度。

通過局部置換算法或優先級置換算法,可以限制系統抖動。如果一個進程開始抖動,那么由于采用局部置換,它不能從另一個進程中獲取幀,而且也不能導致后者抖動。然而,這個問題并沒有完全解決。如果進程抖動,那么在大多數時間內會排隊等待調頁設備。由于調頁設備的平均隊列更長,缺頁錯誤的平均等待時間也會增加。因此,即使對于不再抖動的進程,有效訪問時間也會增加。

為了防止抖動,應為進程提供足夠多的所需幀數。但是如何知道進程“需要”多少幀呢?有多種技術。工作集策略研究一個進程實際使用多少幀。這種方法定義了進程執行的局部性模型。

局部性模型指出,隨著進程執行,它從一個局部移向另一個局部。局部性是最近使用頁面的一個集合(圖 2)。一個程序通常由多個不同的可能重疊的局部組成。

內存引用模式中的局部性
圖 2 內存引用模式中的局部性

例如,當一個函數被調用時,它就定義了一個新的局部。在這個局部里,內存引用可針對函數調用的指令、它的局部變量以及全局變量的某個子集。當退出函數時,進程離開該局部,因為這個函數的局部變量和指令已不再處于活動使用狀態。以后可能回到這個局部。

因此,可以看到局部是由程序結構和數據結構來定義的。局部性模型指出,所有程序都具有這種基本的內存引用結構。注意,局部性模型是目前為止緩存討論的背后原理。如果對任何數據類型的訪問是隨機的而沒有規律模式,那么緩存就沒有用了。

假設為進程分配足夠的幀以適應當前局部。該進程在其局部內會出現缺頁錯誤,直到所有頁面都在內存中;接著它不再會出現缺頁錯誤,除非改變局部。如果沒有能夠分配到足夠的幀來容納當前局部,那么進程將會抖動,因為它不能在內存中保留正在使用的所有頁面。

工作集模型

如上所述,工作集模型是基于局部性假設的。這個模型采用參數 △ 定義工作集窗口。它的思想是檢查最近 △ 個頁面引用。這最近 △ 個頁面引用的頁面集合稱為工作集(如圖 3 所示)。

工作集模型
圖 3 工作集模型

如果一個頁面處于活動使用狀態,那么它處在工作集中。如果它不再使用,那么它在最后一次引用的 △ 時間單位后,會從工作集中刪除。因此,工作集是程序局部的近似。

例如,給定如圖 3 所示的內存引用序列,如果 △ 為 10 個內存引用,那么 t1 時的工作集為 {1,2, 5,6,7}。到 t2 時,工作集已經改變為 {3,4}。

工作集的精度取決于△的選擇。如果 △ 太小,那么它不能包含整個局部;如果 △ 太大,那么它可能包含多個局部。在極端情況下,如果 △ 為無窮大,那么工作集為進程執行所需的所有頁面的集合。

因此,最重要的工作集屬性是它的大小。如果系統內的每個工作集通過計算為 WSS,那么就得到:

D=ΣWSSi

這里 D 為幀的總需求量。每個進程都使用其工作集內的頁面。因此,進程 i 需要 WSSi 幀。如果總需求大于可用幀的總數(D>m),則將發生抖動,因此有些進程得不到足夠的幀數。

一旦選中了 △,工作集模型的使用就很簡單。操作系統監視每個進程的工作集,并為它分配大于其工作集的幀數。如果還有足夠的額外幀,那么可啟動另一進程。如果工作集大小的總和增加,以致超過可用幀的總數,則操作系統會選擇一個進程來掛起。該進程的頁面被寫出(交換),并且其幀可分配給其他進程。掛起的進程以后可以重啟。

這種工作集策略可防止抖動,同時保持盡可能高的多道程度。因此,它優化了 CPU 利用率。工作集模型的困難是跟蹤工作集。工作集窗口是一個移動窗口。對于每次內存引用,新的引用出現在一端,最舊的引用離開另一端。如果一個頁面在工作集窗口內的任何位置被引用過,那么它就在工作集窗口內。

通過定期時鐘中斷和引用位,我們能夠近似工作集模型。

例如,假設 △ 為 10 000 個引用,而且每 5000 個引用引起定時器中斷。當得到一個定時器中斷時,復制并清除所有頁面的引用位。如果發生缺頁錯誤,那么可以檢查當前的引用位和位于內存的兩個位,這兩位可以確定在過去的 10 000?15 000 個引用之間該頁面是否被使用過。如果使用過,那么這些位中至少有一位會被打開。如果沒有使用過,那么這些位會被關閉。至少有一位打開的頁面會被視為在工作集中。

注意,這種安排并不完全準確,這是因為并不知道在 5000 個引用內的什么位置出現了引用。通過增加歷史位的數量和中斷的頻率(例如,10 位和每 1000 個引用中斷一次),可以降低這一不確定性。然而,服務這些更為頻繁中斷的成本也會相應更高。

缺頁錯誤頻率

雖然工作集模型是成功的而且工作集的知識能夠用于預先調頁,但是用于控制抖動似乎有點笨拙。采用缺頁錯誤頻率(PFF)的策略是一種更為直接的方法。

這里的問題是防止抖動。抖動具有高缺頁錯誤率。因此,需要控制缺頁錯誤率。當缺頁錯誤率太高時,我們知道該進程需要更多的幀。相反,如果缺頁錯誤率太低,則該進程可能具有太多的幀。

缺頁錯誤頻率
圖 4 缺頁錯誤頻率

我們可以設置所需缺頁錯誤率的上下限(圖 4)。如果實際缺頁錯誤率超過上限,則可為進程再分配一幀;如果實際缺頁錯誤率低于下限,則可從進程中刪除一幀。因此,可以直接測量和控制缺頁錯誤率,以防止抖動。

與工作集策略一樣,也可能不得不換出一個進程。如果缺頁錯誤率增加并且沒有空閑幀可用,那么必須選擇某個進程并將其交換到后備存儲。然后,再將釋放的幀分配給具有高缺頁錯誤率的進程。

實際上,抖動及其導致的交換對性能的負面影響很大。目前處理這一問題的最佳實踐是,在可能的情況下提供足夠物理內存以避免抖動和交換。從智能手機到大型機,提供足夠內存,可以保持所有工作集都并發地處在內存中,并且提供最好的用戶體驗(除非在極端條件下)。

所有教程

優秀文章

精美而實用的網站,提供C語言、C++、STL、Linux、Shell、Java、Go語言等教程,以及socket、GCC、vi、Swing、設計模式、JSP等專題。

Copyright ?2011-2018 biancheng.net, 陜ICP備15000209號

底部Logo