上一節，我們學習了內存性能中 Buffer 和 Cache 的概念。簡單復習一下，Buffer 和 Cache 的設計目的，是為了提升系統的 I/O 性能。它們利用內存，充當起慢速磁盤與快速 CPU 之間的橋梁，可以加速 I/O 的訪問速度。 Buffer 和 Cache 分別緩存的是對磁盤和文件系統的讀寫數據。 從寫的角度來說，不僅可以優化磁盤和文件的寫入，對應用程序也有好處，應用程序可以在數據真正落盤前，就返回去做其他工作。 從讀的角度來說，不僅可以提高那些頻繁訪問數據的讀取速度，也降低了頻繁 I/O 對磁盤的壓力。 既然 Buffer 和 Cache 對系統性能有很大影響，那我們在軟件開發的過程中，能不能利用這一點，來優化 I/O 性能，提升應用程序的運行效率呢？ 答案自然是肯定的。今天，我就用幾個案例幫助你更好地理解緩存的作用，并學習如何充分利用這些緩存來提高程序效率。 為了方便你理解，Buffer 和 Cache 我仍然用英文表示，避免跟“緩存”一詞混淆。而文中的“緩存”，通指數據在內存中的臨時存儲。

緩存命中率

在案例開始前，你應該習慣性地先問自己一個問題，你想要做成某件事情，結果應該怎么評估？比如說，我們想利用緩存來提升程序的運行效率，應該怎么評估這個效果呢？換句話說，有沒有哪個指標可以衡量緩存使用的好壞呢？ 我估計你已經想到了，緩存的命中率。所謂緩存命中率，是指直接通過緩存獲取數據的請求次數，占所有數據請求次數的百分比。 命中率越高，表示使用緩存帶來的收益越高，應用程序的性能也就越好。 實際上，緩存是現在所有高并發系統必需的核心模塊，主要作用就是把經常訪問的數據(也就是熱點數據)，提前讀入到內存中。這樣，下次訪問時就可以直接從內存讀取數據，而不需要經過硬盤，從而加快應用程序的響應速度。 這些獨立的緩存模塊通常會提供查詢接口，方便我們隨時查看緩存的命中情況。不過 Linux 系統中并沒有直接提供這些接口，所以這里我要介紹一下，cachestat 和 cachetop ，它們正是查看系統緩存命中情況的工具。

• cachestat 提供了整個操作系統緩存的讀寫命中情況。
• cachetop 提供了每個進程的緩存命中情況。

這兩個工具都是 bcc 軟件包的一部分，它們基于 Linux 內核的 eBPF(extended Berkeley Packet Filters)機制，來跟蹤內核中管理的緩存，并輸出緩存的使用和命中情況。 這里注意，eBPF 的工作原理不是我們今天的重點，記住這個名字即可，后面文章中我們會詳細學習。今天要掌握的重點，是這兩個工具的使用方法。 使用 cachestat 和 cachetop 前，我們首先要安裝 bcc 軟件包。比如，在 Ubuntu 系統中，你可以運行下面的命令來安裝： sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 4052245BD4284CDD echo "deb https://repo.iovisor.org/apt/xenial xenial main" | sudo tee /etc/apt/sources.list.d/iovisor.list sudo apt-get update sudo apt-get install -y bcc-tools libbcc-examples linux-headers-$(uname -r) 注意：bcc-tools 需要內核版本為 4.1 或者更新的版本，如果你用的是 CentOS，那就需要手動升級內核版本后再安裝。 操作完這些步驟，bcc 提供的所有工具就都安裝到 /usr/share/bcc/tools 這個目錄中了。不過這里提醒你，bcc 軟件包默認不會把這些工具配置到系統的 PATH 路徑中，所以你得自己手動配置： $ export PATH=$PATH:/usr/share/bcc/tools 配置完，你就可以運行 cachestat 和 cachetop 命令了。比如，下面就是一個 cachestat 的運行界面，它以 1 秒的時間間隔，輸出了 3 組緩存統計數據： $ cachestat 1 3TOTAL MISSES HITS DIRTIES BUFFERS_MB CACHED_MB2 0 2 1 17 2792 0 2 1 17 2792 0 2 1 17 279 你可以看到，cachestat 的輸出其實是一個表格。每行代表一組數據，而每一列代表不同的緩存統計指標。這些指標從左到右依次表示：

• TOTAL ，表示總的 I/O 次數；
• MISSES ，表示緩存未命中的次數；
• HITS ，表示緩存命中的次數；
• DIRTIES， 表示新增到緩存中的臟頁數；
• BUFFERS_MB 表示 Buffers 的大小，以 MB 為單位；
• CACHED_MB 表示 Cache 的大小，以 MB 為單位。

接下來我們再來看一個 cachetop 的運行界面： $ cachetop 11:58:50 Buffers MB: 258 / Cached MB: 347 / Sort: HITS / Order: ascending PID UID CMD HITS MISSES DIRTIES READ_HIT% WRITE_HIT%13029 root python 1 0 0 100.0% 0.0% 它的輸出跟 top 類似，默認按照緩存的命中次數(HITS)排序，展示了每個進程的緩存命中情況。具體到每一個指標，這里的 HITS、MISSES 和 DIRTIES ，跟 cachestat 里的含義一樣，分別代表間隔時間內的緩存命中次數、未命中次數以及新增到緩存中的臟頁數。 而 READ_HIT 和 WRITE_HIT ，分別表示讀和寫的緩存命中率。

指定文件的緩存大小

除了緩存的命中率外，還有一個指標你可能也會很感興趣，那就是指定文件在內存中的緩存大小。你可以使用 pcstat 這個工具，來查看文件在內存中的緩存大小以及緩存比例。 pcstat 是一個基于 Go 語言開發的工具，所以安裝它之前，你首先應該安裝 Go 語言，你可以點擊這里下載安裝。 安裝完 Go 語言，再運行下面的命令安裝 pcstat： $ export GOPATH=~/go $ export PATH=~/go/bin:$PATH $ go get golang.org/x/sys/unix $ go get github.com/tobert/pcstat/pcstat 全部安裝完成后，你就可以運行 pcstat 來查看文件的緩存情況了。比如，下面就是一個 pcstat 運行的示例，它展示了 /bin/ls 這個文件的緩存情況： $ pcstat /bin/ls +---------+----------------+------------+-----------+---------+ | Name | Size (bytes) | Pages | Cached | Percent | |---------+----------------+------------+-----------+---------| | /bin/ls | 133792 | 33 | 0 | 000.000 | +---------+----------------+------------+-----------+---------+ 這個輸出中，Cached 就是 /bin/ls 在緩存中的大小，而 Percent 則是緩存的百分比。你看到它們都是 0，這說明 /bin/ls 并不在緩存中。 接著，如果你執行一下 ls 命令，再運行相同的命令來查看的話，就會發現 /bin/ls 都在緩存中了： $ ls $ pcstat /bin/ls +---------+----------------+------------+-----------+---------+ | Name | Size (bytes) | Pages | Cached | Percent | |---------+----------------+------------+-----------+---------| | /bin/ls | 133792 | 33 | 33 | 100.000 | +---------+----------------+------------+-----------+---------+ 知道了緩存相應的指標和查看系統緩存的方法后，接下來，我們就進入今天的正式案例。 跟前面的案例一樣，今天的案例也是基于 Ubuntu 18.04，當然同樣適用于其他的 Linux 系統。 機器配置：2 CPU，8GB 內存。 預先按照上面的步驟安裝 bcc 和 pcstat 軟件包，并把這些工具的安裝路徑添加到到 PATH 環境變量中。 預先安裝 Docker 軟件包，比如 apt-get install docker.io

案例一

第一個案例，我們先來看一下上一節提到的 dd 命令。 dd 作為一個磁盤和文件的拷貝工具，經常被拿來測試磁盤或者文件系統的讀寫性能。不過，既然緩存會影響到性能，如果用 dd 對同一個文件進行多次讀取測試，測試的結果會怎么樣呢？ 我們來動手試試。首先，打開兩個終端，連接到 Ubuntu 機器上，確保 bcc 已經安裝配置成功。 然后，使用 dd 命令生成一個臨時文件，用于后面的文件讀取測試： # 生成一個 512MB 的臨時文件 $ dd if=/dev/sda1 of=file bs=1M count=512 # 清理緩存 $ echo 3 > /proc/sys/vm/drop_caches 繼續在第一個終端，運行 pcstat 命令，確認剛剛生成的文件不在緩存中。如果一切正常，你會看到 Cached 和 Percent 都是 0: $ pcstat file +-------+----------------+------------+-----------+---------+ | Name | Size (bytes) | Pages | Cached | Percent | |-------+----------------+------------+-----------+---------| | file | 536870912 | 131072 | 0 | 000.000 | +-------+----------------+------------+-----------+---------+ 還是在第一個終端中，現在運行 cachetop 命令： # 每隔 5 秒刷新一次數據 $ cachetop 5 這次是第二個終端，運行 dd 命令測試文件的讀取速度： $ dd if=file of=/dev/null bs=1M 512+0 records in 512+0 records out 536870912 bytes (537 MB, 512 MiB) copied, 16.0509 s, 33.4 MB/s 從 dd 的結果可以看出，這個文件的讀性能是 33.4 MB/s。由于在 dd 命令運行前我們已經清理了緩存，所以 dd 命令讀取數據時，肯定要通過文件系統從磁盤中讀取。 不過，這是不是意味著， dd 所有的讀請求都能直接發送到磁盤呢？ 我們再回到第一個終端， 查看 cachetop 界面的緩存命中情況： PID UID CMD HITS MISSES DIRTIES READ_HIT% WRITE_HIT% \.\.\.3264 root dd 37077 37330 0 49.8% 50.2% 從 cachetop 的結果可以發現，并不是所有的讀都落到了磁盤上，事實上讀請求的緩存命中率只有 50% 。 接下來，我們繼續嘗試相同的測試命令。先切換到第二個終端，再次執行剛才的 dd 命令： $ dd if=file of=/dev/null bs=1M 512+0 records in 512+0 records out 536870912 bytes (537 MB, 512 MiB) copied, 0.118415 s, 4.5 GB/s 看到這次的結果，有沒有點小驚訝？磁盤的讀性能居然變成了 4.5 GB/s，比第一次的結果明顯高了太多。為什么這次的結果這么好呢？ 不妨再回到第一個終端，看看 cachetop 的情況： 10:45:22 Buffers MB: 4 / Cached MB: 719 / Sort: HITS / Order: ascending PID UID CMD HITS MISSES DIRTIES READ_HIT% WRITE_HIT% \.\.\.32642 root dd 131637 0 0 100.0% 0.0% 顯然，cachetop 也有了不小的變化。你可以發現，這次的讀的緩存命中率是 100.0%，也就是說這次的 dd 命令全部命中了緩存，所以才會看到那么高的性能。 然后，回到第二個終端，再次執行 pcstat 查看文件 file 的緩存情況： $ pcstat file +-------+----------------+------------+-----------+---------+ | Name | Size (bytes) | Pages | Cached | Percent | |-------+----------------+------------+-----------+---------| | file | 536870912 | 131072 | 131072 | 100.000 | +-------+----------------+------------+-----------+---------+ 從 pcstat 的結果你可以發現，測試文件 file 已經被全部緩存了起來，這跟剛才觀察到的緩存命中率 100% 是一致的。 這兩次結果說明，系統緩存對第二次 dd 操作有明顯的加速效果，可以大大提高文件讀取的性能。 但同時也要注意，如果我們把 dd 當成測試文件系統性能的工具，由于緩存的存在，就會導致測試結果嚴重失真。

案例二

接下來，我們再來看一個文件讀寫的案例。這個案例類似于前面學過的不可中斷狀態進程的例子。它的基本功能比較簡單，也就是每秒從磁盤分區 /dev/sda1 中讀取 32MB 的數據，并打印出讀取數據花費的時間。 為了方便你運行案例，我把它打包成了一個 Docker 鏡像。 跟前面案例類似，我提供了下面兩個選項，你可以根據系統配置，自行調整磁盤分區的路徑以及 I/O 的大小。

• -d 選項，設置要讀取的磁盤或分區路徑，默認是查找前綴為 /dev/sd 或者 /dev/xvd 的磁盤。
• -s 選項，設置每次讀取的數據量大小，單位為字節，默認為 33554432(也就是 32MB)。

這個案例同樣需要你開啟兩個終端。分別 SSH 登錄到機器上后，先在第一個終端中運行 cachetop 命令： # 每隔 5 秒刷新一次數據 $ cachetop 5 接著，再到第二個終端，執行下面的命令運行案例： $ docker run --privileged --name=app -itd feisky/app:io-direct 案例運行后，我們還需要運行下面這個命令，來確認案例已經正常啟動。如果一切正常，你應該可以看到類似下面的輸出： $ docker logs app Reading data from disk /dev/sdb1 with buffer size 33554432 Time used: 0.929935 s to read 33554432 bytes Time used: 0.949625 s to read 33554432 bytes 從這里你可以看到，每讀取 32 MB 的數據，就需要花 0.9 秒。這個時間合理嗎？我想你第一反應就是，太慢了吧。那這是不是沒用系統緩存導致的呢？ 我們再來檢查一下。回到第一個終端，先看看 cachetop 的輸出，在這里，我們找到案例進程 app 的緩存使用情況： 16:39:18 Buffers MB: 73 / Cached MB: 281 / Sort: HITS / Order: ascending PID UID CMD HITS MISSES DIRTIES READ_HIT% WRITE_HIT%21881 root app 1024 0 0 100.0% 0.0% 這個輸出似乎有點意思了。1024 次緩存全部命中，讀的命中率是 100%，看起來全部的讀請求都經過了系統緩存。但是問題又來了，如果真的都是緩存 I/O，讀取速度不應該這么慢。 不過，話說回來，我們似乎忽略了另一個重要因素，每秒實際讀取的數據大小。HITS 代表緩存的命中次數，那么每次命中能讀取多少數據呢？自然是一頁。 前面講過，內存以頁為單位進行管理，而每個頁的大小是 4KB。所以，在 5 秒的時間間隔里，命中的緩存為 1024*4K/1024 = 4MB，再除以 5 秒，可以得到每秒讀的緩存是 0.8MB，顯然跟案例應用的 32 MB/s 相差太多。 至于為什么只能看到 0.8 MB 的 HITS，我們后面再解釋，這里你先知道怎么根據結果來分析就可以了。 這也進一步驗證了我們的猜想，這個案例估計沒有充分利用系統緩存。其實前面我們遇到過類似的問題，如果為系統調用設置直接 I/O 的標志，就可以繞過系統緩存。 那么，要判斷應用程序是否用了直接 I/O，最簡單的方法當然是觀察它的系統調用，查找應用程序在調用它們時的選項。使用什么工具來觀察系統調用呢？自然還是 strace。 繼續在終端二中運行下面的 strace 命令，觀察案例應用的系統調用情況。注意，這里使用了 pgrep 命令來查找案例進程的 PID 號： # strace -p $(pgrep app) strace: Process 4988 attached restart_syscall(<\.\.\. resuming interrupted nanosleep \.\.\.>) = 0 openat(AT_FDCWD, "/dev/sdb1", O_RDONLY|O_DIRECT) = 4 mmap(NULL, 33558528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f448d240000 read(4, "8vq\213\314\264u\373\4\336K\224\25@\371\1\252\2\262\252q\221\n0\30\225bD\252\266@J"\.\.\., 33554432) = 33554432 write(1, "Time used: 0.948897 s to read 33"\.\.\., 45) = 45 close(4) = 0 從 strace 的結果可以看到，案例應用調用了 openat 來打開磁盤分區 /dev/sdb1，并且傳入的參數為 O_RDONLY|O_DIRECT(中間的豎線表示或)。 O_RDONLY 表示以只讀方式打開，而 O_DIRECT 則表示以直接讀取的方式打開，這會繞過系統的緩存。 驗證了這一點，就很容易理解為什么讀 32 MB 的數據就都要那么久了。直接從磁盤讀寫的速度，自然遠慢于對緩存的讀寫。這也是緩存存在的最大意義了。 找出問題后，我們還可以在再看看案例應用的源代碼，再次驗證一下： int flags = O_RDONLY | O_LARGEFILE | O_DIRECT; int fd = open(disk, flags, 0755); 上面的代碼，很清楚地告訴我們：它果然用了直接 I/O。 找出了磁盤讀取緩慢的原因，優化磁盤讀的性能自然不在話下。修改源代碼，刪除 O_DIRECT 選項，讓應用程序使用緩存 I/O ，而不是直接 I/O，就可以加速磁盤讀取速度。 app-cached.c 就是修復后的源碼，我也把它打包成了一個容器鏡像。在第二個終端中，按 Ctrl+C 停止剛才的 strace 命令，運行下面的命令，你就可以啟動它： # 刪除上述案例應用 $ docker rm -f app# 運行修復后的應用 $ docker run --privileged --name=app -itd feisky/app:io-cached 還是第二個終端，再來運行下面的命令查看新應用的日志，你應該能看到下面這個輸出： $ docker logs app Reading data from disk /dev/sdb1 with buffer size 33554432 Time used: 0.037342 s s to read 33554432 bytes Time used: 0.029676 s to read 33554432 bytes 現在，每次只需要 0.03 秒，就可以讀取 32MB 數據，明顯比之前的 0.9 秒快多了。所以，這次應該用了系統緩存。 我們再回到第一個終端，查看 cachetop 的輸出來確認一下： 16:40:08 Buffers MB: 73 / Cached MB: 281 / Sort: HITS / Order: ascending PID UID CMD HITS MISSES DIRTIES READ_HIT% WRITE_HIT%22106 root app 40960 0 0 100.0% 0.0% 果然，讀的命中率還是 100%，HITS (即命中數)卻變成了 40960，同樣的方法計算一下，換算成每秒字節數正好是 32 MB(即 40960*4k/5/1024=32M)。 這個案例說明，在進行 I/O 操作時，充分利用系統緩存可以極大地提升性能。 但在觀察緩存命中率時，還要注意結合應用程序實際的 I/O 大小，綜合分析緩存的使用情況。 案例的最后，再回到開始的問題，為什么優化前，通過 cachetop 只能看到很少一部分數據的全部命中，而沒有觀察到大量數據的未命中情況呢？這是因為，cachetop 工具并不把直接 I/O 算進來。這也又一次說明了，了解工具原理的重要。 cachetop 的計算方法涉及到 I/O 的原理以及一些內核的知識，如果你想了解它的原理的話，可以點擊這里查看它的源代碼。

總結

Buffers 和 Cache 可以極大提升系統的 I/O 性能。通常，我們用緩存命中率，來衡量緩存的使用效率。命中率越高，表示緩存被利用得越充分，應用程序的性能也就越好。 你可以用 cachestat 和 cachetop 這兩個工具，觀察系統和進程的緩存命中情況。其中，

• cachestat 提供了整個系統緩存的讀寫命中情況。
• cachetop 提供了每個進程的緩存命中情況。

不過要注意，Buffers 和 Cache 都是操作系統來管理的，應用程序并不能直接控制這些緩存的內容和生命周期。所以，在應用程序開發中，一般要用專門的緩存組件，來進一步提升性能。 比如，程序內部可以使用堆或者棧明確聲明內存空間，來存儲需要緩存的數據。再或者，使用 Redis 這類外部緩存服務，優化數據的訪問效率。

總結

以上是生活随笔為你收集整理的17 | 案例篇：如何利用系统缓存优化程序的运行效率？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。