一文搞定 Perf 和 Gpertools
本文轉載自微信公眾號「小姐姐味道」，作者小姐姐養的狗。轉載本文請聯系小姐姐味道公眾號。
在Linux下開發是幸福的，尤其是在發生問題的時候。永遠忘不了在Windows下應用發生問題時那種無助的感覺。
Java提供了非常多的工具來應對故障排查、性能分析，比如jstat、jmap、jmc等。但大多數情況下，資源的瓶頸在操作系統上。如果宿主機并不能正常工作，那么在之上進行各種Java的應用分析就會變得沒有意義。皮之不存毛將焉附，就是這個道理。
要做性能分析，Linux下有一個非常好用的工具，叫做perf。幾乎每個發行版都有它的安裝包。perf誕生于2009年，是一個內核級的工具;另外，還有一個工具叫做gperftools，是google的產品，是一個應用級別的產品。
雖然它們都有perf字樣，但使用場景和處理的問題也是不一樣的。
1. perf：CPU暴漲問題排查
顧名思義，perf是做性能分析用的。perf支持兩種模式，計算模式和采樣模式。比如，perf stat使用的是計算模式，而perf record采用的是采樣模式。拿采樣來說，它的原理是這樣的：每隔一個固定的時間，產生一個中斷，然后統計對應的pid和函數。采樣就預示著與實際運行情況并不能保持一致，但如果一個函數運行的時間越長，被時鐘中斷的機會就越大。鑒于perf最終顯示的是統計值，所以它的測量結果是高度可信的。
通過包管理工具可以很容易的獲取perf。比如在centos下，直接通過yum install perf進行安裝。perf提供了非常多的命令，我們可以直接輸入perf輸出這些選項。
Perf的功能非常多，常用的有perf list、perf stat、perf top、perf record、perf report等。下面以幾個常見的例子，來說明它的應用場景。
使用下面的腳本，使得某一核CPU使用飆升到100%。
- cat /dev/zero > /dev/null
使用下面腳本，耗光CPU資源。(先取得cpu的核數，然后循環生成任務)。這段腳本將數據輸出到/dev/null，所以只占用CPU資源，沒有占用任何I/O資源。
- for i in `seq 1 $(cat /proc/cpuinfo |grep "physical id" |wc -l)`;
- do dd if=/dev/zero of=/dev/null &
- done
我們就拿下面的這個腳本來說明情況。從top的截圖中，可以看到sy和ni的占用，達到了100%，我的腳本起作用了!(溫馨提示：執行完腳本后，如果你想要殺死這些進程，除了重啟之外，還可以直接通過ps找到相應的進程，然后使用kill命令終止)。
接下來使用record指令來錄制CPU的使用情況。從上面的描述可以得知，統計結果是采樣結果。
- <># perf record -a -e cycles -o perf.perf -g sleep 10
- [ perf record: Woken up 55 times to write data ]
- [ perf record: Captured and wrote 14.282 MB perf.perf (160302 samples) ]
程序將會運行10秒鐘，然后將采樣結果輸出到perf.perf文件中。通過report命令可以展示統計結果。
- perf report -i perf.perf
可以看到大多數cpu的損耗都是在dd命令上，甚至里面的調用樹，也能夠清晰的展示。這在調試一些c++語言寫的程序，或者調試jvm的一些內部行為時，非常的有用，因為它可以直接跟蹤到系統調用層面。但有些細節，如果對Linux內核不是非常了解的話，下手就比較困難。所以通常情況下，我們只能通常粗略的定位到有問題的模塊，然后再深入進行調試。
perf還可以通過指定進程號進行性能追蹤，來獲取性能數據。
- perf top -g -p 2343
2. 示例代碼
了解到perf的基本用法，我們拿一個經常實際遇到的例子來說明一下perf的使用。堆外內存是通過JNI等類庫進行調用所產生的內存，在實際排查中定位非常困難。傳統的工具包括JMC，都不能快速有效的找到問題的元兇。黔驢技窮的時候，一般就到了perf上場的時候了。
為了演示這個過程，我特意做了一段非常精致的JAVA代碼。代碼片段較長，可以訪問下面的gist鏈接，下面只說明關鍵代碼。這段代碼是典型的堆外內存泄露問題。
- https://gist.github.com/lycying/70ff3897d8516011c7ffc702aa0d03c2
使用com.sun.net.httpserver.HttpServer自帶的簡易server，可以非常容的構造一個服務器，我們可以通過請求去改變一些應用行為。
使用下面的JVM參數啟動這段代碼。
- java -Xmx1G -Xmn1G \
- -XX:+AlwaysPreTouch \
- -XX:MaxMetaspaceSize=10M \
- -XX:MaxDirectMemorySize=10M \
- -XX:NativeMemoryTracking=detail LeakExample
程序將人為創建一個停頓狀態，具體測試步驟如下。
- 程序運行一小段時間，內存使用率迅速達到60%時，這時候程序將自動掛起
- 啟動perf進行采樣，相當于問題發生中進行切入 (perf record -g -p $pid)
- 訪問http://localhost:8888 端口，將會將內存閾值提高到85%，內存會迅速達到這個狀態
- 停止采樣，將生成perf數據
- 使用perf report進行分析 (perf report -i perf.data )
這將會得到下面的一張圖。
但我們不能從中得到有用的信息。是方法錯了么?是的。采樣內存，要使用perf mem record指令，但是這個指令在大多數機器上都不能工作，得到的信息也有限。
perf記錄的是CPU的性能數據，這里要特別說明一下。只要是使用率上5%的，我一般都會關注。一般情況下，占用的cpu時間片多，證明使用內存也比較多。但事情總有例外的時候，比如頻繁申請1byte的方法塊，和一次性申請1MB的方法塊，并不能同日而語。
所以perf能不能發現內存問題，要看運氣。
3. gperftools：找到堆外內存的元兇
要找到內存問題，要使用google的gperftools，我們主要用到它的 Heap Profiler，功能很強大。https://github.com/gperftools/gperftools
它的啟動方式有點特別，安裝成功之后，你只需要輸出兩個環境變量即可。
- mkdir -p /opt/test
- export LD_PRELOAD=/usr/lib64/libtcmalloc.so
- export HEAPPROFILE=/opt/test/heap
在同一個終端，再次啟動我們的應用程序，可以看到內存申請動作都被記錄到了 opt 目錄下的 test 目錄。
接下來，我們就可以使用 pprof 命令分析這些文件。
- cd /opt/test
- pprof -text *heap | head -n 200
使用這個工具，能夠一眼追蹤到申請內存最多的函數。Java_java_util_zip_Inflater_init 這個函數立馬就被發現了。
這就是我們模擬內存泄漏的整個過程，到此問題就解決了。
GZIPInputStream 使用 Inflater 申請堆外內存、Deflater 釋放內存，調用 close() 方法來主動釋放。如果忘記關閉，Inflater 對象的生命會延續到下一次 GC，有一點類似堆內的弱引用。在此過程中，堆外內存會一直增長。
問題發生在我們的decompress函數上。它在使用的時候，忘記關閉流了。我們可以看一下異常和正常情況的區別。
這段是忘了關閉流的函數。這種情況在編碼中經常會發生。
- public static String decompress(byte[] input) throws Exception {
- ByteArrayOutputStream out = new ByteArrayOutputStream();
- copy(new GZIPInputStream(new ByteArrayInputStream(input)), out);
- return new String(out.toByteArray());
- }
下面是修改后正常的函數。
- public static String decompress(byte[] input) throws Exception {
- ByteArrayOutputStream out = new ByteArrayOutputStream();
- GZIPInputStream gzip = new GZIPInputStream(new ByteArrayInputStream(input));
- try {
- copy(gzip, out);
- return new String(out.toByteArray());
- }finally {
- try{ gzip.close(); }catch (Exception ex){}
- try{ out.close(); }catch (Exception ex){}
- }
- }
4. 題外話
使用pprof，還可以輸出圖形化的分析報告，需要安裝圖形生成工具graphviz，可以說是非常nice了。
另外不得不提的一點是，perf和gperftools對性能的影響，雖然不是特別大，但也盡量不要在線上環境使用它們。據我實際使用的經驗判斷，這個性能損耗率大概在30%左右。如果你的問題可以復現，通過常規手法又無法解決的情況下，可以使用這些工具去分析。比如你的應用實例有5個，完全可以分20%的流量到專用的機器上，把profile打開，相信你會很快定位到問題。
作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高并發世界，給你不一樣的味道。我的個人微信xjjdog0，歡迎添加好友，進一步交流。
