空閒/後臺工作類別設計文件
目前,我們在空閒時的行為並不理想,它是為持續負載下的伺服器設計的,目的是將待處理的工作保持在“中等”水平,讓工作積累起來,以便我們能夠以更高效的批處理方式進行處理,同時也能為負載突增留出餘量。
但對於桌面或移動裝置——工作不太持續且功耗更重要的場景——我們希望以不同的方式執行,即“快速進入空閒”,以便系統可以進入休眠狀態。我們不希望在系統應該空閒時仍然零星地處理後臺工作。
複雜因素在於存在許多後臺任務,它們形成了一個層級結構(或一個有向圖,取決於你如何劃分)——一個後臺任務可能會為另一個任務生成工作。
因此,正確的空閒檢測需要對這種層級結構進行建模。
前臺寫入
頁快取回寫
Copygc, rebalance
日誌回收
當我們實現空閒檢測並快速進入空閒時,我們需要注意不要過多地擾亂系統在持續負載下執行良好(或在 rebalance 的情況下可能改進它,它目前沒有主動嘗試讓工作批次處理)的現有行為。
持續負載狀態¶
當系統處於持續負載下時,我們希望這些作業持續執行——這可能最好用 P/D 控制器來建模,它們會嘗試將目標值(即碎片化磁碟空間、可用日誌空間)大致保持在某個範圍的中間。
在持續負載下的目標是平衡我們處理負載峰值的能力,同時不耗盡 x 資源(空閒磁碟空間、日誌中的空閒空間),並讓一些工作積累起來進行批處理(或變得不必要)。
例如,我們不希望過於激進地執行 copygc,因為那樣它會清空那些無論如何都會變空(被覆蓋或刪除)的桶,我們也不希望等到幾乎沒有可用空間時才執行,因為那樣系統會表現得不可預測——突然我們需要做更多的工作來服務每次寫入,系統變得慢得多。
空閒狀態¶
當系統變為空閒時,我們應該開始更快地重新整理待處理的工作,以便系統可以進入休眠狀態。
請注意,“空閒”的定義取決於任務在層級結構中的位置——當任務上方的任務停止生成新工作時,該任務應開始更快地重新整理工作。
例如,當頁快取回寫空閒時,rebalance 應該開始更快地重新整理;只有當 copygc 和 rebalance 都空閒時,日誌回收才應該開始更快地重新整理。
當有更多工作正在進行中且我們仍有空間時,讓工作積累起來是很重要的,因為如果我們允許其批次處理,重新整理總是更高效的。新的寫入可能會在 rebalance 移動資料之前覆蓋它,並且任務可能會為日誌回收需要重新整理的 btree 節點生成更多更新。
在空閒時,我們在每個時間間隔內完成的工作量應與我們空閒的時間長度成比例。如果我們只空閒很短時間,我們不應該立即重新整理所有內容;系統可能很快就會喚醒並開始生成新工作,立即重新整理最終可能會做很多本來不必要的工作,如果我們允許更多地批次處理的話。
總而言之,我們將需要
一個生成工作的後臺任務類別列表,其中包括一個“前臺”類別。
對每個類別的跟蹤——“我正在工作,還是已經進入休眠狀態?”
並且每個類別在決定發出多少工作時,都應該檢查其上方的類別。