LINUX性能優化--利用緩存提升性能

原創

2020-07-03 13:21

在內存基礎篇講了一個概念就是存儲層次的概念，內存肯定是硬盤的存儲速度快。
然後上文也得出了一個結論：
Buffer 和 Cache 分別緩存的是對磁盤和文件系統的讀寫數據。
1 從寫的角度來說，不僅可以優化磁盤和文件的寫入，對應用程序也有好處，應用程序可以在數據真正落盤前，就返回去做其他工作。
2 從讀的角度來說，不僅可以提高那些頻繁訪問數據的讀取速度，也降低了頻繁 I/O 對磁盤的壓力
那麼是否可以利用Buffer和Cache來提升系統的性能呢？
答案是肯定的。
性能優化的，必須要有個量化的標準來評估的效果，那麼用什麼標準來評估結果呢？
緩存命中率
所謂緩存命中率，是指直接通過緩存獲取數據的請求次數，佔所有數據請求次數的百分比。
自然而然：
命中率越高，表示使用緩存帶來的收益越高，應用程序的性能也就越好。
在所有的高性能的系統中，肯定離不開緩存的影子。主要就是根據二八原則，把熱點數據放到內存裏面，減少訪問磁盤IO的次數。
所以必須要有查詢訪問緩存的次數的工具。
在LINUX上面有兩個工具提供了這個功能，分別是
cachestat 提供了整個操作系統緩存的讀寫命中情況。
cachetop 提供了每個進程的緩存命中情況
這兩個工具都是 bcc 軟件包的一部分，它們基於 Linux 內核的 eBPF（extended Berkeley Packet Filters）機制，來跟蹤內核中管理的緩存，並輸出緩存的使用和命中情況。
安裝：
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 提供的所有工具就都安裝到 /usr/share/bcc/tools 這個目錄中了
需要修改環境變量：
$ export PATH=$PATH:/usr/share/bcc/tools

HITS ，表示緩存命中的次數；
MISSES ，表示緩存未命中的次數；
DIRTIES，表示新增到緩存中的髒頁數；
HITRATIO, 緩存的命中率；
BUFFERS_MB 表示 Buffers 的大小，以 MB 爲單位；
CACHED_MB 表示 Cache 的大小，以 MB 爲單位。
在來看看cachetop的輸出

默認按照緩存的命中次數（HITS）排序，展示了每個進程的緩存命中情況。
具體到每一個指標，這裏的 HITS、MISSES 和 DIRTIES ，跟 cachestat 裏的含義一樣，分別代表間隔時間內的緩存命中次數、未命中次數以及新增到緩存中的髒頁數。
而 READ_HIT 和 WRITE_HIT ，分別表示讀和寫的緩存命中率。
指定文件在內存中的緩存大小
使用工具pcstat
安裝pcstat：
1 安裝go
2 go get golang.org/x/sys/unix
3 go get github.com/tobert/pcstat/pcstat
比如展示以下 ls的使用情況

pcstat /bin/ls
Cached 就是 /bin/ls 在緩存中的大小，而 Percent 則是緩存的百分比
使用dd測試
dd 作爲一個磁盤和文件的拷貝工具，經常被拿來測試磁盤或者文件系統的讀寫性能。
環境：
1 ubuntu 18.04
2 2核心4G
步驟：
1 生成一個512MB的臨時文件
dd if=/dev/sda1 of=file bs=1M count=512
2 清理緩存
echo 3 > /proc/sys/vm/drop_caches
3 運行 pcstat 命令，確認剛剛生成的文件不在緩存中

4 開啓一個終端，運行
cachetop 5
5 dd if=file of=/dev/null bs=1M

結果是1.3GB/S
在看看 cachetop

可以看到命中率只有50%
6 再次運行：
dd if=file of=/dev/null bs=1M

哇，這次到了5.4GB/S,整整提高了4倍
在看看cachetop

這次的讀的緩存命中率是 100.0%，也就是說這次的 dd 命令全部命中了緩存，所以纔會看到那麼高的性能。
再次看看pcstat file

可以看到的是，所有的file內容已經被緩存起來了
直接IO

內存以頁爲單位進行管理，而每個頁的大小是 4KB。所以，在 5 秒的時間間隔裏，命中的緩存爲 40960 * 4K/1024 = 80MB，再除以 5 秒，可以得到每秒讀的緩存是 16MB，顯然跟案例應用的 32 MB/s 相差一倍。
那麼，要判斷應用程序是否用了直接 I/O，最簡單的方法當然是觀察它的系統調用，查找應用程序在調用它們時的選項。使用什麼工具來觀察系統調用呢？自然還是 strace。

不知道用了直接IO，cachetop 算到的還是32MB，用到了緩存到底是什麼問題。。。。。
後面研究研究。。。。