在我之前的文章中有粉絲提到內存不足，需要頻繁清理系統緩存的問題，今天我們就來聊聊Page Cache相關的一系列問題。
怎么觀測Page Cache？
在Linux上直接查看Page Cache的方式有很多，包括free 、/proc/vmstat 命令等，它們的內容其實是一致的，這些性能查詢工具的數據來源都是/proc/meminfo，今天我們就用最常用的free命令的輸出解釋下。
free命令輸出
meminfo信息
我們觀察free命令的輸出，在結合/proc/meminfo的結果，你可以發現 buff/cache 包括下面這幾項：
buff/cache = Buffers + Cached + SReclaimable。
從這個公式中，你能看到 free 命令中的 buff/cache 是由Buffers、Cached 和 SReclaimable 這三項組成的，它強調的是內存的可回收性，也就是說，可以被回收的內存會統計在這一項。關于buff/cache的介紹，我在前面的文章中有詳細講過。這里的SReclaimable是指可以被回收的內核內存，包括 dentry 和 inode 等。
Page Cache有什么用？
- Buffer 是對磁盤數據的緩存，而 Cache 是文件數據的緩存，它們既會用在讀請求中，也會用在寫請求中（可以通過dd命令對磁盤和文件讀寫觀測緩存效果）。
- 從寫的角度來說，不僅可以優化磁盤和文件的寫入，對應用程序也有好處，應用程序可以在數據真正落盤前，就返回去做其他工作。
- 從讀的角度來說，既可以加速讀取那些需要頻繁訪問的數據，也降低了頻繁 I/O 對磁盤的壓力。
Page Cache操作不當的危害
如果你的業務對Page Cache比較敏感，比如說你的業務數據對延遲很敏感，或者再具體一點，你的業務指標對TP99（99 分位）要求較高，這種場景下，如果對Page Cache操作不當會產生的問題。
手工誤操作Page Cache導致業務性能下降
我們知道，對于Page Cache而言，是可以通過drop_cache來清掉的，很多人在看到系統中存在非常多的Page Cache時會習慣使用drop_cache來清理它們。
于是這樣就引入了一個容易被我們忽略的問題：當我們執行 echo 2 來 drop slab 的時候，它也會把 Page Cache 給 drop 掉，業務性能產生了明顯的下降。
- inode 是內存中對磁盤文件的索引，進程在查找或者讀取文件時就是通過 inode 來進行操作的。
- 進程會通過inode來找到文件的地址空間（address_space），然后結合文件偏移（會轉換成 page index）來找具體的Page,inode被清理需要去磁盤讀取。
內核機制引起Page Cache被回收導致業務性能下降
在內存緊張的時候會觸發內存回收，內存回收會嘗試去回收reclaimable（可以被回收的）內存，這部分內存既包含 Page Cache 又包含 reclaimable kernel memory(比如 slab)，我們可以通過/proc/vmstat 來觀察的內核回收的事件。
grep inodesteal /proc/vmstat
vmstat信息
這個行為對應的事件是 inodesteal，就是上面這兩個事件，其中：
- kswapd_inodesteal：是指在 kswapd 回收的過程中，因為回收 inode 而釋放的 pagecache page 個數。
- pginodesteal是指kswapd 之外其他線程在回收過程中，因為回收 inode 而釋放的 pagecache page 個數。
如何避免Page Cache 被回收而引起的性能問題？
從應用代碼層面來優化
從應用程序代碼層面來解決是相對比較徹底的方案，因為應用更清楚哪些 Page Cache 是重要的，哪些是不重要的，所以就可以明確地來對讀寫文件過程中產生的 Page Cache 區別對待。例如：
- 對于重要的數據，可以通過mlock(2)來保護它，防止被回收以及被 drop。
- 對于不重要的數據（比如日志），那可以通過madvise(2)告訴內核來立即釋放這些 Page Cache。
從系統層面來調整
在有些情況下，對應用程序而言，修改源碼是件比較麻煩的事，如果可以不修改源碼來達到目的那就最好不過了。Linux 內核同樣實現了這種不改應用程序的源碼而從系統層面調整來保護重要數據的機制，這個機制就是memory cgroup，它提供了幾個內存水位控制線 memory.{min, low, high, max}。
- memory.max：這是指 memory cgroup 內的進程最多能夠分配的內存，如果不設置的話，就默認不做內存大小的限制。
- memory.high：如果設置了這一項，當memory cgroup內進程的內存使用量超過了該值后就會立即被回收掉，所以這一項的目的是為了盡快的回收掉不活躍的Page Cache。
- memory.low：這一項是用來保護重要數據的，當memory cgroup內進程的內存使用量低于了該值后，在內存緊張觸發回收后就會先去回收不屬于該memory cgroup的Page Cache，等到其他的Page Cache都被回收掉后再來回收這些 Page Cache。
- memory.min：這一項同樣是用來保護重要數據的，只不過與 memoy.low 有所不同的是，當 memory cgroup 內進程的內存使用量低于該值后，即使其他不在該 memory cgroup 內的 Page Cache 都被回收完了也不會去回收這些 Page Cache，可以理解為這是用來保護最高優先級的數據的。
如果你想要保護你的Page Cache不被回收，你就可以考慮將你的業務進程放在一個memory cgroup中，然后設置 memory.{min,low} 來進行保護；與之相反，如果你想要盡快釋放你的Page Cache，那你可以考慮設置memory.high 來及時的釋放掉不活躍的Page Cache。
