上一節，我們梳理了 Linux 內存管理的基本原理，並學會了用 free 和 top 等工具，來查看系統和進程的內存使用情況。
在今天的內容開始之前，我們先來回顧一下系統的內存使用情況，比如下面這個 free 輸出界面：
# 注意不同版本的 free 輸出可能會有所不同
$ free
total used free shared buff/cache available
Mem: 8169348 263524 6875352 668 1030472 7611064
Swap: 0 0 0
顯然，這個界面包含了物理內存 Mem 和交換分區 Swap 的具體使用情況，比如總內存、已用內存、緩存、可用內存等。其中緩存是 Buffer 和 Cache 兩部分的總和 。
這里的大部分指標都比較容易理解，但 Buffer 和 Cache 可能不太好區分。從字面上來說，Buffer 是緩沖區，而 Cache 是緩存，兩者都是數據在內存中的臨時存儲。那么，你知道這兩種“臨時存儲”有什么區別嗎？
注：今天內容接下來的部分，Buffer 和 Cache 我會都用英文來表示，避免跟文中的“緩存”一詞混淆。而文中的“緩存”，則通指內存中的臨時存儲。
free 數據的來源
在我正式講解兩個概念前，你可以先想想，你有沒有什么途徑來進一步了解它們？除了中文翻譯直接得到概念，別忘了，Buffer 和 Cache 還是我們用 free 獲得的指標。
還記得我之前講過的，碰到看不明白的指標時該怎么辦嗎？
估計你想起來了，不懂就去查手冊。用 man 命令查詢 free 的文檔，就可以找到對應指標的詳細說明。比如，我們執行 man free ，就可以看到下面這個界面。
buffers
Memory used by kernel buffers (Buffers in /proc/meminfo)
cache Memory used by the page cache and slabs (Cached and SReclaimable in /proc/meminfo)
buff/cache
Sum of buffers and cache
從 free 的手冊中，你可以看到 buffer 和 cache 的說明。
- Buffers 是內核緩沖區用到的內存，對應的是 /proc/meminfo 中的 Buffers 值。
- Cache 是內核頁緩存和 Slab 用到的內存，對應的是 /proc/meminfo 中的 Cached 與 SReclaimable 之和。
這里的說明告訴我們，這些數值都來自 /proc/meminfo，但更具體的 Buffers、Cached 和 SReclaimable 的含義，還是沒有說清楚。
要注意，網上的結論可能是對的，但是很可能跟你的環境並不匹配。最簡單來說，同一個指標的具體含義，就可能因為內核版本、性能工具版本的不同而有挺大差別。這也是為什么，我總在專欄中強調通用思路和方法，而不是讓你死記結論。對於案例實踐來說，機器環境就是我們的最大限制。
那么，有沒有更簡單、更准確的方法，來查詢它們的含義呢？
proc 文件系統
我在前面 CPU 性能模塊就曾經提到過，
/proc 是 Linux 內核提供的一種特殊文件系統，是用戶跟內核交互的接口。比方說，用戶可以從 /proc 中查詢內核的運行狀態和配置選項，查詢進程的運行狀態、統計數據等，當然，你也可以通過 /proc 來修改內核的配置。
proc 文件系統同時也是很多性能工具的最終數據來源。比如我們剛才看到的 free ，就是通過讀取 /proc/meminfo ，得到內存的使用情況。
繼續說回 /proc/meminfo，既然 Buffers、Cached、SReclaimable 這幾個指標不容易理解，那我們還得繼續查 proc 文件系統，獲取它們的詳細定義。
執行 man proc ，你就可以得到 proc 文件系統的詳細文檔。
注意這個文檔比較長，你最好搜索一下（比如搜索 meminfo），以便更快定位到內存部分。
Buffers %lu
Relatively temporary storage for raw disk blocks that shouldn't get tremendously large (20MB or so).
Cached %lu
In-memory cache for files read from the disk (the page cache). Doesn't include SwapCached.
...
SReclaimable %lu (since Linux 2.6.19)
Part of Slab, that might be reclaimed, such as caches.
SUnreclaim %lu (since Linux 2.6.19)
Part of Slab, that cannot be reclaimed on memory pressure.
通過這個文檔，我們可以看到：
- Buffers 是對原始磁盤塊的臨時存儲，也就是用來緩存磁盤的數據，通常不會特別大（20MB 左右）。這樣，內核就可以把分散的寫集中起來，統一優化磁盤的寫入，比如可以把多次小的寫合並成單次大的寫等等。
- Cached 是從磁盤讀取文件的頁緩存，也就是用來緩存從文件讀取的數據。這樣，下次訪問這些文件數據時，就可以直接從內存中快速獲取，而不需要再次訪問緩慢的磁盤。
- SReclaimable 是 Slab 的一部分。Slab 包括兩部分，其中的可回收部分，用 SReclaimable 記錄；而不可回收部分，用 SUnreclaim 記錄。
好了，我們終於找到了這三個指標的詳細定義。到這里，你是不是長舒一口氣，滿意地想着，總算弄明白 Buffer 和 Cache 了。不過，知道這個定義就真的理解了嗎？這里我給你提了兩個問題，你先想想能不能回答出來。
- 第一個問題，Buffer 的文檔沒有提到這是磁盤讀數據還是寫數據的緩存，而在很多網絡搜索的結果中都會提到 Buffer 只是對將要寫入磁盤數據的緩存。那反過來說，它會不會也緩存從磁盤中讀取的數據呢？
- 第二個問題，文檔中提到，Cache 是對從文件讀取數據的緩存，那么它是不是也會緩存寫文件的數據呢？
為了解答這兩個問題，接下來，我將用幾個案例來展示， Buffer 和 Cache 在不同場景下的使用情況。
案例
跟前面實驗一樣，今天的案例也是基於 Ubuntu 18.04，當然，其他 Linux 系統也適用。我的案例環境是這樣的。
機器配置：2 CPU，8GB 內存。
預先安裝 sysstat 包，如 apt install sysstat。
之所以要安裝 sysstat ，是因為我們要用到 vmstat ，來觀察 Buffer 和 Cache 的變化情況。雖然從 /proc/meminfo 里也可以讀到相同的結果，但畢竟還是 vmstat 的結果更加直觀。
另外，這幾個案例使用了 dd 來模擬磁盤和文件的 I/O，所以我們也需要觀測 I/O 的變化情況。
上面的工具安裝完成后，你可以打開兩個終端，連接到 Ubuntu 機器上。
准備環節的最后一步，為了減少緩存的影響，記得在第一個終端中，運行下面的命令來清理系統緩存：
# 清理文件頁、目錄項、Inodes 等各種緩存
$ echo 3 > /proc/sys/vm/drop_caches
這里的 /proc/sys/vm/drop_caches ，就是通過 proc 文件系統修改內核行為的一個示例，寫入 3 表示清理文件頁、目錄項、Inodes 等各種緩存。這幾種緩存的區別你暫時不用管，后面我們都會講到。
場景 1：磁盤和文件寫案例
我們先來模擬第一個場景。首先，在第一個終端，運行下面這個 vmstat 命令：
# 每隔 1 秒輸出 1 組數據
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 7743608 1112 92168 0 0 0 0 52 152 0 1 100 0 0
0 0 0 7743608 1112 92168 0 0 0 0 36 92 0 0 100 0 0
輸出界面里， 內存部分的 buff 和 cache ，以及 io 部分的 bi 和 bo 就是我們要關注的重點。
- buff 和 cache 就是我們前面看到的 Buffers 和 Cache，單位是 KB。
- bi 和 bo 則分別表示塊設備讀取和寫入的大小，單位為塊 / 秒。因為 Linux 中塊的大小是 1KB，所以這個單位也就等價於 KB/s。
正常情況下，空閑系統中，你應該看到的是，這幾個值在多次結果中一直保持不變。
接下來，到第二個終端執行 dd 命令，通過讀取隨機設備，生成一個 500MB 大小的文件：
$ dd if=/dev/urandom of=/tmp/file bs=1M count=500
然后再回到第一個終端，觀察 Buffer 和 Cache 的變化情況：
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 7499460 1344 230484 0 0 0 0 29 145 0 0 100 0 0
1 0 0 7338088 1752 390512 0 0 488 0 39 558 0 47 53 0 0
1 0 0 7158872 1752 568800 0 0 0 4 30 376 1 50 49 0 0
1 0 0 6980308 1752 747860 0 0 0 0 24 360 0 50 50 0 0
0 0 0 6977448 1752 752072 0 0 0 0 29 138 0 0 100 0 0
0 0 0 6977440 1760 752080 0 0 0 152 42 212 0 1 99 1 0
...
0 1 0 6977216 1768 752104 0 0 4 122880 33 234 0 1 51 49 0
0 1 0 6977440 1768 752108 0 0 0 10240 38 196 0 0 50 50 0
通過觀察 vmstat 的輸出，我們發現，在 dd 命令運行時， Cache 在不停地增長，而 Buffer 基本保持不變。
再進一步觀察 I/O 的情況，你會看到，
- 在 Cache 剛開始增長時，塊設備 I/O 很少，bi 只出現了一次 488 KB/s，bo 則只有一次 4KB。而過一段時間后，才會出現大量的塊設備寫，比如 bo 變成了 122880。
- 當 dd 命令結束后，Cache 不再增長，但塊設備寫還會持續一段時間，並且，多次 I/O 寫的結果加起來，才是 dd 要寫的 500M 的數據。
把這個結果，跟我們剛剛了解到的 Cache 的定義做個對比，你可能會有點暈乎。為什么前面文檔上說 Cache 是文件讀的頁緩存，怎么現在寫文件也有它的份？
這個疑問，我們暫且先記下來，接着再來看另一個磁盤寫的案例。兩個案例結束后，我們再統一進行分析。
不過，對於接下來的案例，我必須強調一點：
下面的命令對環境要求很高，需要你的系統配置多塊磁盤，並且磁盤分區 /dev/sdb1 還要處於未使用狀態。如果你只有一塊磁盤，千萬不要嘗試，否則將會對你的磁盤分區造成損壞。
如果你的系統符合標准，就可以繼續在第二個終端中，運行下面的命令。清理緩存后，向磁盤分區 /dev/sdb1 寫入 2GB 的隨機數據：
# 首先清理緩存
$ echo 3 > /proc/sys/vm/drop_caches
# 然后運行 dd 命令向磁盤分區 /dev/sdb1 寫入 2G 數據
$ dd if=/dev/urandom of=/dev/sdb1 bs=1M count=2048
然后，再回到終端一，觀察內存和 I/O 的變化情況：
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 7584780 153592 97436 0 0 684 0 31 423 1 48 50 2 0
1 0 0 7418580 315384 101668 0 0 0 0 32 144 0 50 50 0 0
1 0 0 7253664 475844 106208 0 0 0 0 20 137 0 50 50 0 0
1 0 0 7093352 631800 110520 0 0 0 0 23 223 0 50 50 0 0
1 1 0 6930056 790520 114980 0 0 0 12804 23 168 0 50 42 9 0
1 0 0 6757204 949240 119396 0 0 0 183804 24 191 0 53 26 21 0
1 1 0 6591516 1107960 123840 0 0 0 77316 22 232 0 52 16 33 0
從這里你會看到，雖然同是寫數據，寫磁盤跟寫文件的現象還是不同的。
寫磁盤時（也就是 bo 大於 0 時），Buffer 和 Cache 都在增長，但顯然 Buffer 的增長快得多。
這說明，
寫磁盤用到了大量的 Buffer，這跟我們在文檔中查到的定義是一樣的。
對比兩個案例，我們發現，
寫文件時會用到 Cache 緩存數據，而寫磁盤則會用到 Buffer 來緩存數據。所以，回到剛剛的問題，雖然文檔上只提到，Cache 是文件讀的緩存，但實際上，Cache 也會緩存寫文件時的數據。
場景 2：磁盤和文件讀案例
了解了磁盤和文件寫的情況，我們再反過來想，磁盤和文件讀的時候，又是怎樣的呢？
我們回到第二個終端，運行下面的命令。清理緩存后，從文件 /tmp/file 中，讀取數據寫入空設備：
# 首先清理緩存
$ echo 3 > /proc/sys/vm/drop_caches
# 運行 dd 命令讀取文件數據
$ dd if=/tmp/file of=/dev/null
然后，再回到終端一，觀察內存和 I/O 的變化情況：
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 1 0 7724164 2380 110844 0 0 16576 0 62 360 2 2 76 21 0
0 1 0 7691544 2380 143472 0 0 32640 0 46 439 1 3 50 46 0
0 1 0 7658736 2380 176204 0 0 32640 0 54 407 1 4 50 46 0
0 1 0 7626052 2380 208908 0 0 32640 40 44 422 2 2 50 46 0
觀察 vmstat 的輸出，你會發現讀取文件時（也就是 bi 大於 0 時），Buffer 保持不變，而 Cache 則在不停增長。這
跟我們查到的定義“Cache 是對文件讀的頁緩存”是一致的。
那么，磁盤讀又是什么情況呢？我們再運行第二個案例來看看。
首先，回到第二個終端，運行下面的命令。清理緩存后，從磁盤分區 /dev/sda1 中讀取數據，寫入空設備：
# 首先清理緩存
$ echo 3 > /proc/sys/vm/drop_caches
# 運行 dd 命令讀取文件
$ dd if=/dev/sda1 of=/dev/null bs=1M count=1024
然后，再回到終端一，觀察內存和 I/O 的變化情況：
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 7225880 2716 608184 0 0 0 0 48 159 0 0 100 0 0
0 1 0 7199420 28644 608228 0 0 25928 0 60 252 0 1 65 35 0
0 1 0 7167092 60900 608312 0 0 32256 0 54 269 0 1 50 49 0
0 1 0 7134416 93572 608376 0 0 32672 0 53 253 0 0 51 49 0
0 1 0 7101484 126320 608480 0 0 32748 0 80 414 0 1 50 49 0
觀察 vmstat 的輸出，你會發現讀磁盤時（也就是 bi 大於 0 時），Buffer 和 Cache 都在增長，但顯然 Buffer 的增長快很多。這說明讀磁盤時，數據緩存到了 Buffer 中。
當然，我想，經過上一個場景中兩個案例的分析，你自己也可以對比得出這個結論：讀文件時數據會緩存到 Cache 中，而讀磁盤時數據會緩存到 Buffer 中。
到這里你應該發現了，雖然文檔提供了對 Buffer 和 Cache 的說明，但是仍不能覆蓋到所有的細節。比如說，今天我們了解到的這兩點：
- Buffer 既可以用作“將要寫入磁盤數據的緩存”，也可以用作“從磁盤讀取數據的緩存”。
- Cache 既可以用作“從文件讀取數據的頁緩存”，也可以用作“寫文件的頁緩存”。
這樣，我們就回答了案例開始前的兩個問題。
簡單來說，
Buffer 是對磁盤數據的緩存，而 Cache 是文件數據的緩存，它們既會用在讀請求中，也會用在寫請求中。
小結
今天，我們一起探索了內存性能中 Buffer 和 Cache 的詳細含義。Buffer 和 Cache 分別緩存磁盤和文件系統的讀寫數據。
從寫的角度來說，不僅可以優化磁盤和文件的寫入，對應用程序也有好處，應用程序可以在數據真正落盤前，就返回去做其他工作。
從讀的角度來說，既可以加速讀取那些需要頻繁訪問的數據，也降低了頻繁 I/O 對磁盤的壓力。
思考
我們已經知道，可以使用 ps、top 或者 proc 文件系統，來獲取進程的內存使用情況。那么，如何統計出所有進程的物理內存使用量呢？
提示：要避免重復計算多個進程同時占用的內存，像是頁緩存、共享內存這類。如果你把 ps、top 得到的數據直接相加，就會出現重復計算的問題。
這里，我推薦從 /proc/< pid >/smaps 入手。前面內容里，我並沒有直接講過 /proc/< pid >smaps 文件中各個指標含義，所以，需要你自己動手查 proc 文件系統的文檔，解讀並回答這個問題。