作業系統面試：虛擬記憶體與缺頁例外如何運作？

題目與適用情境

一個 Linux 服務啟動時以 mmap 映射 20 GiB 唯讀索引，再 fork 出 8 個工作行程。監控顯示：

• 映射完成後，每個行程的虛擬記憶體很快增加約 20 GiB；
• RSS 沒有同步增加，而是隨查詢碰到更多索引區域逐步成長；
• 冷啟動後的首批請求延遲升高，同時 major page fault 增加；
• 相同查詢再次執行時更快，major page fault 明顯減少。

請解釋虛擬位址如何轉換成實體位址、TLB miss 與 page fault 有何差異、Linux 的 minor 與 major page fault 各代表什麼，以及為什麼直接加總 8 個行程的 RSS 可能高估實際實體記憶體用量。最後提出驗證瓶頸與降低冷啟動延遲的方法。

這是適用於後端、基礎設施、系統軟體、SRE 與效能工程職缺的作業系統題。20 GiB、8 個行程，以及下文採用的 4 KiB 分頁都是虛構練習假設，不代表來源中的正式環境資料。索引是唯讀檔案映射；若改成匿名記憶體、可寫的私有映射、容器記憶體限制或即時系統，診斷重點也會改變。

面試官評估重點

第一個訊號是能否拆開四層概念：虛擬位址空間描述行程「可以存取什麼」，頁表保存位址轉換與權限，TLB 快取近期轉換，實體分頁才是真正駐留在 RAM 的資料。一般回答只會說「虛擬記憶體可以大於實體記憶體」；強回答能沿著一次 load 指令說清楚命中、頁表走訪、可修復 fault 與非法存取。

第二個訊號是是否知道 TLB miss 不等於 page fault。轉換不在 TLB 裡，但頁表項目有效且分頁已駐留時，只要完成頁表走訪並補入 TLB。頁表項目無法滿足這次存取時才會觸發 page fault，例如分頁尚未駐留、首次寫入需要寫入時複製，或權限不允許。

第三個訊號是能否正確解釋 Linux 計數。minor fault 表示處理時不需要磁碟 I/O；分頁可能已在 page cache，只是目前行程還沒有對應映射，也可能是匿名分頁按需配置或寫入時複製。major fault 表示處理需要磁碟 I/O，它可能來自換入匿名分頁，也可能來自讀取尚未進入 page cache 的檔案映射，因此「major fault 就是 swap」並不正確。

最後看候選人是否能以證據完成閉環。強回答會把請求延遲、fault 增量、檔案分頁駐留、區塊裝置 I/O、RSS/PSS 與記憶體壓力放在同一時間區間比較，再決定要預熱、調整存取布局、給核心存取提示，或縮小工作集。

回答前需要釐清的問題

• 映射是檔案映射還是匿名映射，使用 MAPSHARED 或 MAPPRIVATE？ 唯讀檔案分頁可以透過 page cache 被多個行程共享；私有可寫分頁在寫入後可能觸發寫入時複製，變成各行程獨占。
• 20 GiB 中真正的熱門工作集多大，存取是循序還是隨機？ 若 95% 請求只碰到 2 GiB 熱區，預熱全部 20 GiB 會增加啟動時間與記憶體壓力；循序掃描與隨機點查也需要不同的 read-ahead 提示。
• mmap 在 fork 前還是後執行？ 兩種方式都能映射同一檔案，但在 fork 前建立映射較容易確保工作行程繼承相同設定；每個行程仍有自己的頁表與 TLB 狀態。
• major fault 是否與區塊裝置讀取及尾端延遲同時上升？ 只有時間相關性成立，才能把冷啟動緩慢主要歸因於按需讀取；CPU 飽和、鎖競爭、遠端儲存與索引初始化也可能同時存在。
• 機器是否有 swap、容器或 cgroup 記憶體限制，以及近期是否發生回收？ 沒有 swap 仍可能因檔案映射讀取產生 major fault；強烈記憶體壓力會讓剛讀入的檔案分頁被回收，導致反覆 fault。
• 啟動就緒的 SLO 是什麼？ 若服務必須在 10 秒內開始接流量，就不能無條件掃描 20 GiB；若允許較長初始化，則可把一部分 fault 成本移到 readiness 之前。

30 秒回答框架

「mmap 建立檔案映射時不會立刻讀取全部 20 GiB，所以 VIRT 先變大，RSS 隨第一次存取成長。CPU 先查 TLB；若只是 TLB miss，而且頁表項目有效、分頁已駐留，完成頁表走訪即可，page fault 才需要核心修復。Linux 的 minor fault 不需要磁碟 I/O，major fault 需要，因此冷檔案分頁會同時拉高 major fault 與請求延遲，page cache 變熱後就會恢復。8 個行程可共享唯讀分頁，RSS 加總會重複計數，應看 PSS。驗證時對齊 fault 增量、RssFile/PSS、讀取 I/O 與 p99，再只預熱熱門範圍，或在啟動預算內測試 madvise 與 MAP_POPULATE。」

這個框架先解釋現象，再拆開兩個常見混淆，最後提出量測與決策。深入回答還需要說明 fault 的處理路徑，以及各種最佳化在哪些條件下會失效。

分步深入解答

第一步：先區分位址空間、映射與駐留分頁

虛擬記憶體讓每個行程擁有獨立位址空間。一個虛擬位址通常可視為「虛擬頁號 + 頁內位移」；頁表將虛擬頁號映射到實體頁框，並保存 present、讀寫、執行等狀態或權限。多層頁表只為真正使用的位址範圍配置下層結構，避免替有大量空洞的位址空間建立巨大的線性表。

mmap 20 GiB 檔案的直接結果是建立一段 20 GiB 虛擬記憶體區域。它描述這段位址如何對應檔案，不要求核心立即讀取全部內容。因此：

• VIRT 或 VmSize 可以立刻增加約 20 GiB；
• 尚未碰到的檔案分頁不必在 RAM；
• 查詢第一次讀到某分頁時，核心才可能把它載入 page cache 並建立頁表映射；
• RSS 只統計目前駐留的記憶體部分，所以會隨工作集被存取而成長。

假設分頁大小為 4 KiB，完整碰到 20 GiB 需要處理：

20 × 2^30 ÷ 4096 = 5,242,880 個分頁。

這個計算說明「全部預熱」不是免費開關。若真正熱門的只有一小部分，掃描超過 524 萬個分頁會把大量低價值資料帶入記憶體，並可能擠掉其他快取。

第二步：沿一次記憶體存取解釋 TLB 與頁表

CPU 執行 load、store 或取指時，需要把虛擬位址轉成實體位址：

1. 先用虛擬頁號查詢 TLB；
2. TLB 命中時，直接取得實體頁框，加上頁內位移完成存取；
3. TLB 未命中時，由硬體或作業系統查頁表；
4. 若頁表項目有效、權限允許且分頁已駐留，轉換會被放入 TLB，指令重試或繼續；
5. 若目前頁表項目無法完成存取，才進入 page fault 處理。

因此，TLB miss 是「轉換快取沒命中」，page fault 是「目前頁表狀態無法滿足存取」。前者可能只增加頁表走訪成本；後者必須進核心判斷存取是否合法以及如何修復。混淆兩者會誤判 huge page、預熱與儲存最佳化的作用。

第三步：把 page fault 分成可修復與不可修復

page fault 是例外，不會自動等同程式錯誤。核心先檢查位址與權限：

• 合法但分頁尚未駐留： 為檔案分頁發起讀取，或從既有 page cache 建立映射；
• 合法匿名分頁首次存取： 第一次讀取可映射共享零頁；第一次寫入會配置實際實體分頁；
• fork 後首次寫入私有分頁： 執行寫入時複製，為寫入行程建立私有副本；
• 位址未映射或權限違規： 無法修復時向行程送出 SIGSEGV 等訊號。

可修復 fault 完成後，核心更新頁表，再重試觸發 fault 的指令。若需要儲存 I/O，行程會在等待期間阻塞，排程器可以執行其他可執行工作；這也是 major fault 容易拉高單次請求延遲的直接原因。

第四步：正確解釋 minor 與 major fault

Linux 的實務分類依據是「處理 fault 是否需要磁碟 I/O」：

• minor fault： 不需要磁碟 I/O。常見情況包括目標檔案分頁已在 page cache、目前行程只是第一次建立映射；匿名記憶體按需建立實體分頁；或寫入時複製可以直接在記憶體完成。
• major fault： 需要磁碟 I/O。就本題而言，冷啟動查詢第一次碰到尚未快取的索引分頁時，核心需要從索引檔讀取資料，因此可能計為 major fault。

兩個反例值得主動提出：

1. major fault 不要求系統啟用 swap，檔案映射缺頁同樣可能需要讀取磁碟；
2. minor fault 也不是零成本，它仍可能進核心、配置分頁、修改頁表並重試指令，只是沒有更慢的磁碟 I/O。

第五步：解釋為什麼 RSS 加總會誤導

8 個工作行程讀取同一個唯讀檔案映射時，底層檔案分頁可以由 page cache 共享。每個行程的 RSS 都會計入自己目前映射的駐留分頁，因此同一個實體分頁可能出現在多個行程的 RSS。直接加總 8 個 RSS 會重複計算共享分頁。

診斷時至少區分：

• VmSize：虛擬位址空間規模；
• VmRSS：該行程目前的駐留分頁總量；
• RssFile：駐留的檔案映射部分；
• RssAnon：駐留的匿名記憶體部分；
• PSS：共享分頁依共享行程數分攤後的比例用量；
• VmPTE：頁表本身用量；
• VmSwap：該行程匿名私有資料使用的 swap，不代表所有檔案映射狀態。

/proc/<pid>/smaps_rollup 能提供行程所有映射的 RSS 與 PSS 彙總。評估 8 個行程對機器的實際壓力時，PSS 總和通常比 RSS 總和更接近「應歸因給這些行程的實體記憶體」，同時仍要查看系統 page cache 與其他行程的競爭。

第六步：用一組可重現觀測驗證瓶頸

先建立同一時間軸，不憑單張 top 畫面下結論。可在 Linux 測試環境記錄：

grep -E 'VmSize|VmRSS|RssAnon|RssFile|VmPTE|VmSwap' /proc/$pid/status
cat /proc/$pid/smaps_rollup
perf stat -e page-faults,minor-faults,major-faults -p "$pid" -- sleep 30

接著執行兩輪完全相同的查詢集：

1. 冷啟動後記錄請求 p50、p95、p99、fault 增量、區塊裝置讀取與 RSS/PSS；
2. 立即重複查詢，保持資料、並行度與程式路徑不變；
3. 若第一輪 major fault、讀取 I/O 與尾端延遲同時上升，第二輪三者明顯下降，代表按需載入檔案分頁是主要因素；
4. 若 major fault 很少但延遲仍高，應繼續檢查 CPU、鎖、遠端呼叫與索引內部初始化；
5. 在可控環境製造記憶體壓力後再重複，判斷熱門分頁被回收時是否重新出現抖動。

fault 是累計計數，必須比較時間區間內的增量，不能只看行程生命週期總數。也要分工作行程觀察，避免把背景掃描行程的 fault 錯誤歸因到線上請求。

第七步：依工作集與 SLO 選擇最佳化

可選方案不是越積極越好：

1. 保留按需載入： 啟動最快、只占用真實工作集，適合冷流量可接受或熱門範圍變化大的服務；代價是第一次存取抖動。
2. 只預熱熱門範圍： 在 readiness 前執行代表性查詢，或依熱門清單碰觸分頁。它把有限成本前移，通常比循序掃描 20 GiB 更可控，但需要維護熱門定義。
3. 使用 madvise 提示存取模式： MADV_WILLNEED 表示近期會存取，核心可以預讀；循序與隨機模式也能分別提示。它是效能提示，不保證分頁一定駐留。
4. 使用 MAP_POPULATE： 建立映射時預填頁表，並對檔案映射觸發 read-ahead，可減少後續阻塞 fault；代價是 mmap 與啟動階段更慢、短時間 I/O 與記憶體壓力更高，而且預填不成功時呼叫也不一定失敗。
5. 調整索引布局與工作集： 把高頻中繼資料與冷資料分開、提高存取區域性、減少隨機跨頁，是比盲目預熱更持久的方案。
6. 設定流量閘門： 先預熱到已定義的熱門覆蓋或 fault 速率門檻，再開放全部流量；同時設定逾時，避免節點永遠無法就緒。

huge page 可能降低 TLB 壓力，但不能消除檔案分頁讀取，也不會自動修正錯誤工作集。只有證據顯示 TLB miss 是主要瓶頸，且記憶體粒度、碎片與部署環境允許時，才值得另外評估。

高品質示範回答

「我會先確認這 20 GiB 是唯讀檔案映射，而且 mmap 在 fork 前完成。mmap 建立的是虛擬位址區域與檔案的對應關係，不會立即把整個檔案讀進實體記憶體，所以每個工作行程的 VmSize 會立刻增加約 20 GiB，RSS 只在查詢真正碰到分頁後成長。

一次存取會先查 TLB。TLB miss 只代表近期位址轉換快取沒有這一項；如果頁表項目有效、權限允許、實體分頁已駐留，完成頁表走訪並補入 TLB 就能繼續，不會產生 page fault。只有頁表狀態無法滿足存取時才 fault，例如檔案分頁尚未駐留、fork 後第一次寫入需要寫入時複製，或存取權限非法。

對 Linux 計數，我會把 minor 定義為處理時不需要磁碟 I/O，major 定義為需要磁碟 I/O。冷啟動時，首批查詢使用的索引分頁還不在 page cache，核心需要從檔案讀取，所以 major fault 與請求尾端延遲一起上升；後續相同查詢命中 page cache，可能只發生 minor fault 或直接命中既有映射，延遲就會下降。major fault 不只來自 swap，即使機器沒有 swap，檔案映射也可能產生。

8 個行程可以共享唯讀檔案分頁，但每個行程的 RSS 都會計入自己映射的共享分頁，所以我不會直接加總 RSS。我會看 /proc/<pid>/smaps_rollup 的 PSS、RssFile、RssAnon 與 VmPTE，再把這些資料與區塊裝置讀取、minor/major fault 增量和請求 p99 放在同一個 30 秒區間。

驗證時我會執行同一查詢集兩次。若第一輪 major fault、讀取 I/O 與 p99 同時偏高，第二輪明顯下降，就能支持按需載入是主要原因。最佳化前先量真實熱門工作集；假如 20 GiB 中只有 2 GiB 熱點，我會在 readiness 前只做熱門預熱，並依循序或隨機存取使用合適的 madvise。如果 SLO 允許把更多成本移到啟動期，再對 MAP_POPULATE 做對照實驗。我不會預設掃描整個檔案，也不會把 huge page 當成 page fault 的通用解法。最後以啟動時間、首分鐘 p99、major fault 速率、PSS 和記憶體回收後的穩定性共同決定。」

這段回答把概念、觀測與選擇連成可驗證的鏈路。面試官即使改變映射類型、工作集或啟動 SLO，也能沿同一框架調整方案。

常見錯誤

• 把 VIRT 當成已占用的 RAM → 檔案映射可先占虛擬位址範圍而不讓所有分頁駐留 → 同時查看 VmSize、RSS、PSS 與映射類型。
• 把 TLB miss 等同 page fault → 頁表已有有效駐留映射時只需完成轉換 → 分別描述 TLB 查詢、頁表走訪與 fault 條件。
• 聲稱所有 page fault 都會讀取磁碟 → page cache 命中、匿名零頁與寫入時複製都可產生 minor fault → 以是否需要磁碟 I/O 區分 Linux 的 minor/major。
• 聲稱 major fault 只來自 swap → 尚未快取的檔案映射分頁也需要讀取儲存裝置 → 先判斷 fault 對應匿名分頁或檔案分頁。
• 直接加總 8 個行程的 RSS → 共享檔案分頁會被重複計數 → 使用 PSS 分攤共享分頁，並結合 RssFile/RssAnon。
• 只看行程生命週期的累計 fault → 無法證明 fault 與某批慢請求相關 → 比較同一時間區間內的 fault 增量、I/O 與延遲。
• 啟動時掃描完整 20 GiB → 可能浪費 I/O、拉長 readiness 並擠出更有價值的分頁 → 先量熱門工作集，只預熱滿足 SLO 所需範圍。
• 認為 MADVWILLNEED 或 MAPPOPULATE 保證沒有後續 fault → 前者是提示，後者也可能未完整預填，分頁之後仍可能被回收 → 以實驗驗證冷啟動及記憶體壓力下的結果。
• 直接啟用 huge page → 它主要改變轉換覆蓋與記憶體粒度，無法取代檔案 I/O 或工作集治理 → 先證明 TLB miss 是主要瓶頸。

追問與應對

追問一：機器完全沒有 swap，為什麼仍會出現 major page fault？

major 的判定是處理 fault 需要磁碟 I/O，不要求來源一定是 swap。本題的索引是檔案映射；第一次存取尚未進入 page cache 的檔案分頁時，核心需要從檔案系統讀取，因此仍可能產生 major fault。驗證時看 RssFile、映射路徑與區塊裝置讀取，不要只檢查 VmSwap。

追問二：同一個檔案分頁已被另一個工作行程讀入，目前行程首次存取會怎樣？

分頁可能已在系統 page cache，但目前行程還沒有對應頁表映射。此時通常不需要磁碟 I/O，可透過 minor fault 建立映射。之後該行程再次存取仍可能先發生 TLB miss，但只要頁表項目有效，就不屬於 page fault。

追問三：為什麼 fork 後寫入一小塊記憶體會讓 PSS 增加？

fork 初期可以透過寫入時複製共享私有分頁。某個工作行程第一次寫入時，核心為它建立私有副本並更新頁表；共享分頁變成該行程獨占分頁，PSS 因而上升。這類 fault 通常不需要磁碟 I/O，但仍有配置與複製成本。唯讀索引應避免意外寫入私有映射。

追問四：若存取模式完全隨機，MADV_SEQUENTIAL 會怎樣？

提示與真實模式不符可能觸發無效 read-ahead，把不會使用的分頁帶入記憶體並增加 I/O。隨機點查應先驗證 MADV_RANDOM 或預設策略，熱門範圍明確時優先按熱點預取。任何提示都要以 fault、I/O、PSS 與延遲實驗判斷，不能只看介面名稱。

追問五：什麼時候應使用 MAP_POPULATE？

當啟動階段允許較長時間與較高 I/O、線上首次存取延遲必須穩定，而且即將存取的映射範圍相對確定時，可以進行對照實驗。若映射遠大於熱門工作集、節點經常擴縮容，或記憶體壓力很快會回收分頁，完整預填可能得不償失。也要記得預填失敗不一定讓 mmap 失敗，必須量測實際駐留與後續 fault。

追問六：如何區分 page fault 抖動與真正的記憶體洩漏？

洩漏通常表現為匿名私有記憶體或不可回收物件隨時間持續成長，即使流量穩定也不回落；檔案映射工作集成長較多反映在 RssFile/page cache，並可能在回收後下降。比較 RssAnon、RssFile、PSS、VmSwap、物件或 heap 分析結果，再做穩定流量與記憶體壓力測試。只看 RSS 上升無法區分兩者。