是什么導致內核在 page_fault 上吃 CPU？

Question

硬件/操作系統：linux 4.9，64G 內存。

16 個守護進程正在運行。 每次讀取隨機短（100 字節）5GiB 文件，在守護程序啟動時將其作為通過 mmap() 映射的內存進行訪問。 每個守護進程讀取自己的文件，所以總共有 16 個 5GiB 文件。

每個守護進程每秒可能進行 10 次讀取。 不要太多，磁盤負載相當小。

有時（5 分鍾內發生 1 個事件，沒有周期，完全隨機）一些隨機守護進程卡在內核代碼中，並帶有后續堆棧（見圖）300 毫秒。 這與主要故障無關：主要故障以每秒約 100...200 的恆定速率運行。 磁盤讀取也是恆定的。

什么會導致這種情況？

圖片文字： __list_del_entry isolate_lru_pages.isra.48 shrink_inactive_list shrink_node_memcg shrink_node node_reclaim get_page_from_freelist enqueue_task_fair sched_clock __alloc_pages_nodemask alloc_pages_vma handle_mm_fault __do_page_fault page_fault

Answer 1

您的堆棧中有shrink_node 和node_reclaim 函數。 它們被調用以釋放內存（通過free命令行工具顯示為 buff/cache）： https : //www.kernel.org/doc/html/latest/admin-guide/mm/concepts.html#reclaim

釋放可回收物理內存頁面並重新利用它們的過程稱為（驚喜！）回收。 Linux 可以異步或同步回收頁面，這取決於系統的狀態。 當系統未加載時，大部分內存是空閑的，分配請求將立即從空閑頁面供應中得到滿足。 隨着負載的增加，空閑頁面的數量下降，當達到某個閾值（高水位線）時，分配請求將喚醒 kswapd 守護進程。 它將異步掃描內存頁，如果它們包含的數據在其他地方可用，則釋放它們，或者驅逐到后備存儲設備（還記得那些臟頁嗎？）。 隨着內存使用量增加更多並達到另一個閾值 - 最小水印 - 分配將觸發直接回收。 在這種情況下，分配將停止，直到回收足夠的內存頁面以滿足請求。

因此，您的 64 GB RAM 系統會出現沒有可用內存的情況。 這個內存量足以容納 12 個 5 GB 文件的副本，您的守護進程使用 16 個文件。 Linux 可能從文件中讀取的數據比使用預讀技術的應用程序所需的數據多（“Linux 預讀：更少的技巧”，ols 2007 pp273-284 ， man 2 readahead ）。 MADV_SEQUENTIAL 也可能開啟這個機制， https: //man7.org/linux/man-pages/man2/madvise.2.html

 MADV_SEQUENTIAL

期望按順序引用頁面。 （因此，給定范圍內的頁面可以被積極地提前讀取，並且可能會在它們被訪問后很快被釋放。）

 MADV_RANDOM

期望以隨機順序引用頁面。 （因此，提前閱讀可能不如平時有用。）

不確定你的守護進程是如何打開和讀取文件的，MADV_SEQUENTIAL 是否對它們有效（或者這個標志是由 glibc 或任何其他庫添加的）。 THP - 透明大頁面https://www.kernel.org/doc/html/latest/admin-guide/mm/transhuge.html也會產生一些影響。 正常的 4.9 內核是 2016 年的，文件系統的 thp 擴展計划在 2019 年https://lwn.net/Articles/789159/ ，但如果您使用 RHEL/CentOS，某些功能可能會向后移植到 4.9 內核的分支中。

您應該定期檢查free和cat /proc/meminfo輸出，以檢查您的守護進程和 linux 內核預讀如何使用內存。