在實際部署的生產(chǎn)環(huán)境能夠以較低的風險及成本實現(xiàn)對業(yè)務邏輯級別性能問題的追蹤。本文將介紹如何集成 Perf4j 到 Java 應用程序中并生成性能數(shù)據(jù)。
網(wǎng)站建設哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、成都微信小程序、集團企業(yè)網(wǎng)站建設等服務項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了民和免費建站歡迎大家使用！
系統(tǒng)日志是應用程序問題診斷及運行維護的重要工具。Logback、Log4j 是常用于 Java 平臺的日志記錄 API. 目前大部分產(chǎn)品只是將系統(tǒng)重要參數(shù)、狀態(tài)的變化及異常信息通過日志輸出。本文將要介紹的 Perf4j 是一款專
門用于 Java 服務器端代碼計時、記錄日志和監(jiān)控結(jié)果的開源工具包。Perf4j
對常用日志工具包進行了擴展，能夠?qū)⒌玫降脑夹阅軘?shù)據(jù)進行統(tǒng)計并發(fā)布到可定制的輸出源，如控制臺、日志文件、JMX 等。Perf4j
提供了多種方式與 Java 代碼集成，開發(fā)和系統(tǒng)維人員能夠靈活地將 Perf4j 的 API 嵌入到各種不同架構(gòu)的應用程序中。
Perf4j 目前依托于開源項目協(xié)作平臺 Codehaus 進行文檔及代碼管理，下一步該項目計劃遷移到 Github
平臺，以便更多的社區(qū)及開發(fā)人員可以參與到開發(fā)及維護中來。Perf4j 歡迎使用者提出新的功能需求并且鼓勵將定制或擴展的代碼貢獻到 Perf4j
源碼中。本文中示例代碼使用的 Perf4j 版本是 0.9.16，讀者需在下載類包或配置 Maven 時留意。
閱讀文章之前，您要對 Java 注解、JMX、面向方面編程有一些了解。特別是 JConsole 的使用及 Spring AOP 的配置方式要較為熟悉。
文章首先闡明在何種應用場景下應優(yōu)先考慮使用 Perf4j。然后是具體講解 Pef4j 與應用程序的集成方式。最后會介紹如何將收集的數(shù)據(jù)生成便于分析的可視化圖表。
應用場景
在 Java 平臺上遇到性能問題時，如 CPU 占用過高、系統(tǒng)響應緩慢，通常的分析方法是使用 JVM
剖析工具在系統(tǒng)瓶頸臨界點前一段時間抓取 CPU 占用分布，再對 CPU 占用率最高的幾個方法排查。Perf4j
的優(yōu)勢在于能夠持續(xù)跟蹤統(tǒng)計所關(guān)注功能代碼的執(zhí)行效率，對于前后兩個版本出現(xiàn)較大差異的方法進行深入分析，可以在開發(fā)周期中盡早發(fā)現(xiàn)問題。Perf4j 還可以用在產(chǎn)品環(huán)境中，從運營的早期開始，將其統(tǒng)計的數(shù)據(jù)做為系統(tǒng)的性能和健康指標長期監(jiān)測。
首選 Perf4j 的應用場景：
Java 本地代碼調(diào)用（JNI） 分布式系統(tǒng)、集群部署 面向服務體系結(jié)構(gòu)（SOA） 遠程方法調(diào)用（RMI）
開發(fā)人員必須將本地方法、遠程方法及 Web services 的性能問題隔離出來，以防干擾對 Java 應用程序本身的分析。通過日志記錄則是最簡單的方式；采用分布式架構(gòu)或集群部署的系統(tǒng)相對復雜，不同的網(wǎng)絡環(huán)境、基礎硬件和操作系統(tǒng)的差異、虛擬主機中資源與配置的差異等造成很難采用統(tǒng)一的工具來監(jiān)測代碼級別的性能指標。而日志記錄則可以輕松加入到各種程序中，且是資源與時間成本最低的方式。Perf4j 提供了 CSV 格式的轉(zhuǎn)換工具，開發(fā)人員可以借助第三方工具方便地將統(tǒng)計結(jié)果匯總分析。
集成到應用程序
下面將分兩種方式具體講述如何利用 Per4j 提供的 API。在實際的項目中，應根據(jù)現(xiàn)有的程序框架及監(jiān)測目的靈活選擇。另外，針對 WebSphere 應用服務器的自有日志系統(tǒng)，還必須采取額外的措施來確保 Perf4j 的正常工作。
對代碼段計時
Perf4j 中 org.perf4j.StopWatch 是整個 API 中的基礎工具。這是一個封裝良好的計時器?？梢园?/p>
StopWatch 嵌入到代碼中任何地方。這種方式往往使得復雜的方法得到分解，從而有利于精確定位問題的根源。以下通過清單 1 和清單 2
來介紹其具體用法。
清單 1.StopWacth 基本用法
public static void basicStopWatch() throws
InterruptedException{ // 創(chuàng)建 StopWacth 時開始計時，之后也可以用 stopWatch.start()
重新設定計時開始時間點 StopWatch stopWatch = new StopWatch("TransactionA"); //
執(zhí)行需要計時的代碼 Thread.sleep(2 * 1000L); String result = stopWatch.stop();
System.out.print(result); }
清單 1 中最后輸出的結(jié)果示例：start[1340442785756] time[1995]
tag[TransactionA]。在構(gòu)造函數(shù)中設定 tag[TransactionA]
用來區(qū)分不同的業(yè)務邏輯，可以把它看成是性能分析中的事務（Transaction）。
如果需要將多段代碼分開統(tǒng)計，可采用 LoggingStopWatch 類的 lap() 方法定義多個事務。
清單 2.LoggingStopWatch 用法
public static void loggingStopWacth()
throws InterruptedException{ LoggingStopWatch stopWatch = new
LoggingStopWatch(); // 設定閾值，小于此閾值的結(jié)果將不會被記錄下來
stopWatch.setTimeThreshold(1*1000L); Thread.sleep(2 * 1000L); //
停止當前計時，開始新的起始時間點 stopWatch.lap("TransactionB"); Thread.sleep(500L);
stopWatch.stop("TransactionC"); }
清單 2 中使用了 LoggingStopWatch 類，其 stop() 方法只是將執(zhí)行時間數(shù)據(jù)通過
System.err.println() 輸出。若與 Log4j 框架集成，則需要使用 LoggingStopWatch 的子類
Log4JStopWatch, 目前 Perf4j 還支持 Apache Commons
Logging、java.util.logginLogback，對應使用 CommonsLogStopWatch、
JavaLogStopWatch、Slf4JStopWatch。
通過使用一些輔助性工具來找到程序中的瓶頸，然后就可以對瓶頸部分的代碼進行優(yōu)化。一般有兩種方案：即優(yōu)化代碼或更改設計方法。我們一般會選擇后者，因為不去調(diào)用以下代碼要比調(diào)用一些優(yōu)化的代碼更能提高程序的性能。而一個設計良好的程序能夠精簡代碼，從而提高性能。 下面將提供一些在JAVA程序的設計和編碼中，為了能夠提高JAVA程序的性能，而經(jīng)常采用的一些方法和技巧。 1．對象的生成和大小的調(diào)整。 JAVA程序設計中一個普遍的問題就是沒有好好的利用JAVA語言本身提供的函數(shù)，從而常常會生成大量的對象（或?qū)嵗?。由于系統(tǒng)不僅要花時間生成對象，以后可能還需花時間對這些對象進行垃圾回收和處理。因此，生成過多的對象將會給程序的性能帶來很大的影響。 例1：關(guān)于String,StringBuffer，+和append JAVA語言提供了對于String類型變量的操作。但如果使用不當，會給程序的性能帶來影響。如下面的語句： Stringname=newString("HuangWeiFeng");System.out.println(name+"ismyname"); 看似已經(jīng)很精簡了，其實并非如此。為了生成二進制的代碼，要進行如下的步驟和操作： (1)生成新的字符串newString（STR_1);(2)復制該字符串; (3)加載字符串常量"HuangWeiFeng"（STR_2);(4)調(diào)用字符串的構(gòu)架器（Constructor）;(5)保存該字符串到數(shù)組中（從位置0開始）; (6)從java.io.PrintStream類中得到靜態(tài)的out變量; (7)生成新的字符串緩沖變量newStringBuffer(STR_BUF_1);(8)復制該字符串緩沖變量; (9)調(diào)用字符串緩沖的構(gòu)架器（Constructor）;(10)保存該字符串緩沖到數(shù)組中（從位置1開始）; (11)以STR_1為參數(shù)，調(diào)用字符串緩沖(StringBuffer)類中的append方法;(12)加載字符串常量"ismyname"(STR_3); (13)以STR_3為參數(shù)，調(diào)用字符串緩沖(StringBuffer)類中的append方法;(14)對于STR_BUF_1執(zhí)行toString命令; (15)調(diào)用out變量中的println方法，輸出結(jié)果。 由此可以看出，這兩行簡單的代碼，就生成了STR_1,STR_2,STR_3,STR_4和STR_BUF_1五個對象變量。這些生成的類的實例一般都存放在堆中。堆要對所有類的超類，類的實例進行初始化，同時還要調(diào)用類極其每個超類的構(gòu)架器。而這些操作都是非常消耗系統(tǒng)資源的。因此，對對象的生成進行限制，是完全有必要的。 經(jīng)修改，上面的代碼可以用如下的代碼來替換。 StringBuffername=newStringBuffer("HuangWeiFeng"); System.out.println(name.append("ismyname.").toString()); 系統(tǒng)將進行如下的操作： (1)生成新的字符串緩沖變量newStringBuffer(STR_BUF_1);(2)復制該字符串緩沖變量; (3)加載字符串常量"HuangWeiFeng"(STR_1);(4)調(diào)用字符串緩沖的構(gòu)架器（Constructor）;(5)保存該字符串緩沖到數(shù)組中（從位置1開始）; (6)從java.io.PrintStream類中得到靜態(tài)的out變量;(7)加載STR_BUF_1; (8)加載字符串常量"ismyname"(STR_2); (9)以STR_2為參數(shù)，調(diào)用字符串緩沖(StringBuffer)實例中的append方法;(10)對于STR_BUF_1執(zhí)行toString命令(STR_3);(11)調(diào)用out變量中的println方法，輸出結(jié)果。 由此可以看出，經(jīng)過改進后的代碼只生成了四個對象變量：STR_1,STR_2,STR_3和STR_BUF_1.你可能覺得少生成一個對象不會對程序的性能有很大的提高。但下面的代碼段2的執(zhí)行速度將是代碼段1的2倍。因為代碼段1生成了八個對象，而代碼段2只生成了四個對象。 代碼段1： Stringname=newStringBuffer("HuangWeiFeng");name+="ismy";name+="name"; 代碼段2： StringBuffername=newStringBuffer("HuangWeiFeng");name.append("ismy"); name.append("name.").toString(); 因此，充分的利用JAVA提供的庫函數(shù)來優(yōu)化程序，對提高JAVA程序的性能時非常重要的.其注意點主要有如下幾方面； (1)盡可能的使用靜態(tài)變量（StaticClassVariables）
如果類中的變量不會隨他的實例而變化，就可以定義為靜態(tài)變量，從而使他所有的實例都共享這個變量。 例： publicclassfoo{ SomeObjectso=newSomeObject();} 就可以定義為：publicclassfoo{ staticSomeObjectso=newSomeObject();} (2)不要對已生成的對象作過多的改變。 對于一些類(如：String類)來講，寧愿在重新生成一個新的對象實例，而不應該修改已經(jīng)生成的對象實例。例： Stringname="Huang";name="Wei";name="Feng"; 上述代碼生成了三個String類型的對象實例。而前兩個馬上就需要系統(tǒng)進行垃圾回收處理。如果要對字符串進行連接的操作，性能將得更差，因為系統(tǒng)將不得為此生成更多得臨時變量，如上例1所示。 (3)生成對象時，要分配給它合理的空間和大小JAVA中的很多類都有它的默認的空間分配大小。對于StringBuffer類來講，默認的分配空間大小是16個字符。如果在程序中使用StringBuffer的空間大小不是16個字符，那么就必須進行正確的初始化。 (4)避免生成不太使用或生命周期短的對象或變量。對于這種情況，因該定義一個對象緩沖池。以為管理一個對象緩沖池的開銷要比頻繁的生成和回收對象的開銷小的多。 (5)只在對象作用范圍內(nèi)進行初始化。JAVA允許在代碼的任何地方定義和初始化對象。這樣，就可以只在對象作用的范圍內(nèi)進行初始化。從而節(jié)約系統(tǒng)的開銷
必須ProductClass pc = productClassService.queryByAlias("product");
i f (pc != null) {
this.setProductClass(pc);
}
查出來的數(shù)據(jù)就算你不顯式的創(chuàng)建對象，他還是會返回一個對象的，他所作的只是一個小小的賦值操作，而你要查兩次數(shù)據(jù)庫來完成一個對象的操作，非常不可取，性能也很不好
使用java自帶的性能分析工具jvisualvm , 可以方便的查看內(nèi)存, 對象, 線程等多種信息.
win+R????然后輸入???jvisualvm??回車即可
效果如下圖
ava性能調(diào)試命令
java性能調(diào)試命令_性能測試--十個命令迅速發(fā)現(xiàn)性能問題
投機啟示錄
原創(chuàng)
關(guān)注
0點贊·85人閱讀
十個命令迅速發(fā)現(xiàn)性能問題
uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top
1. uptime
$ uptime
23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02
這是一種用來快速查看系統(tǒng)平均負載的方法，它表明了系統(tǒng)中有多少要運行的任務(進程)。在 Linux 系統(tǒng)中，這些數(shù)字包含了需要在 CPU 中運行的進程以及正在等待 I/O(通常是磁盤 I/O)的進程。它僅僅是對系統(tǒng)負載的一個粗略展示，稍微看下即可。你還需要其他工具來進一步了解具體情況。
這三個數(shù)字展示的是一分鐘、五分鐘和十五分鐘內(nèi)系統(tǒng)的負載總量平均值按照指數(shù)比例壓縮得到的結(jié)果。從中我們可以看到系統(tǒng)的負載是如何隨時間變化的。比方你在檢查一個問題，然后看到 1 分鐘對應的值遠小于 15 分鐘的值，那么可能說明這個問題已經(jīng)過去了，你沒能及時觀察到。
在上面這個例子中，系統(tǒng)負載在隨著時間增加，因為最近一分鐘的負載值超過了 30，而 15 分鐘的平均負載則只有 19。這樣顯著的差距包含了很多含義，比方 CPU 負載。若要進一步確認的話，則要運行 vmstat 或 mpstat 命令。
2. dmesg | tail
$ dmesg | tail
[1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0
[...]
[1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child
[1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB
[2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request. Check SNMP counters.
這條命令顯式了最近的 10 條系統(tǒng)消息，如果它們存在的話。查找能夠?qū)е滦阅軉栴}的錯誤。上面的例子包含了 oom-killer，以及 TCP 丟棄一個請求。
千萬不要錯過這一步！dmesg 命令永遠值得一試
3. vmstat 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
34 0 0 200889792 73708 591828 0 0 0 5 6 10 96 1 3 0 0
32 0 0 200889920 73708 591860 0 0 0 592 13284 4282 98 1 1 0 0
32 0 0 200890112 73708 591860 0 0 0 0 9501 2154 99 1 0 0 0
32 0 0 200889568 73712 591856 0 0 0 48 11900 2459 99 0 0 0 0
32 0 0 200890208 73712 591860 0 0 0 0 15898 4840 98 1 1 0 0
vmstat(8) 是虛擬內(nèi)存統(tǒng)計的簡稱，其是一個常用工具(幾十年前為了 BSD 所創(chuàng)建)。其在每行打印一條關(guān)鍵的服務器的統(tǒng)計摘要。
vmstat 命令指定一個參數(shù) 1 運行，來打印每一秒的統(tǒng)計摘要。(這個版本的 vmstat)輸出的第一行的那些列，顯式的是開機以來的平均值，而不是前一秒的值?，F(xiàn)在，我們跳過第一行，除非你想要了解并記住每一列。
檢查這些列：
r：CPU 中正在運行和等待運行的進程的數(shù)量。其提供了一個比平均負載更好的信號來確定 CPU 是否飽和，因為其不包含 I/O。解釋：“r”的值大于了 CPU 的數(shù)量就表示已經(jīng)飽和了。
free：以 kb 為單位顯式的空閑內(nèi)存。如果數(shù)字位數(shù)很多，說明你有足夠的空閑內(nèi)存?！癴ree -m” 命令，是下面的第七個命令，其可以更好的說明空閑內(nèi)存的狀態(tài)。
si, so：Swap-ins 和 swap-outs。如果它們不是零，則代表你的內(nèi)存不足了。
us, sy, id, wa, st：這些都是平均了所有 CPU 的 CPU 分解時間。它們分別是用戶時間(user)、系統(tǒng)時間(內(nèi)核)(system)、空閑(idle)、等待 I/O(wait)、以及占用時間(stolen)(被其他訪客，或使用 Xen，訪客自己獨立的驅(qū)動域)。
CPU 分解時間將會通過用戶時間加系統(tǒng)時間確認 CPU 是否為忙碌狀態(tài)。等待 I/O 的時間一直不變則表明了一個磁盤瓶頸；這就是 CPU 的閑置，因為任務都阻塞在等待掛起磁盤 I/O 上了。你可以把等待 I/O 當成是 CPU 閑置的另一種形式，其給出了為什么 CPU 閑置的一個線索。
對于 I/O 處理來說，系統(tǒng)時間是很重要的。一個高于 20% 的平均系統(tǒng)時間，可以值得進一步的探討：也許內(nèi)核在處理 I/O 時效率太低了。
在上面的例子中，CPU 時間幾乎完全花在了用戶級，表明應用程序占用了太多 CPU 時間。而 CPU 的平均使用率也在 90% 以上。這不一定是一個問題；檢查一下“r”列中的飽和度。
4. mpstat -P ALL 1
$ mpstat -P ALL 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
07:38:49 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
07:38:50 PM all 98.47 0.00 0.75 0.00 0.00 0.00 0.00 0.00 0.00 0.78
07:38:50 PM 0 96.04 0.00 2.97 0.00 0.00 0.00 0.00 0.00 0.00 0.99
07:38:50 PM 1 97.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00
07:38:50 PM 2 98.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00
07:38:50 PM 3 96.97 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 3.03
[...]
這個命令打印每個 CPU 的 CPU 分解時間，其可用于對一個不均衡的使用情況進行檢查。一個單獨 CPU 很忙碌則代表了正在運行一個單線程的應用程序。
5. pidstat 1
$ pidstat 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
07:41:02 PM UID PID %usr %system %guest %CPU CPU Command
07:41:03 PM 0 9 0.00 0.94 0.00 0.94 1 rcuos/0
07:41:03 PM 0 4214 5.66 5.66 0.00 11.32 15 mesos-slave
07:41:03 PM 0 4354 0.94 0.94 0.00 1.89 8 java
07:41:03 PM 0 6521 1596.23 1.89 0.00 1598.11 27 java
07:41:03 PM 0 6564 1571.70 7.55 0.00 1579.25 28 java
07:41:03 PM 60004 60154 0.94 4.72 0.00 5.66 9 pidstat
07:41:03 PM UID PID %usr %system %guest %CPU CPU Command
07:41:04 PM 0 4214 6.00 2.00 0.00 8.00 15 mesos-slave
07:41:04 PM 0 6521 1590.00 1.00 0.00 1591.00 27 java
07:41:04 PM 0 6564 1573.00 10.00 0.00 1583.00 28 java
07:41:04 PM 108 6718 1.00 0.00 0.00 1.00 0 snmp-pass
07:41:04 PM 60004 60154 1.00 4.00 0.00 5.00 9 pidstat
pidstat 命令有點像 top 命令對每個進程的統(tǒng)計摘要，但循環(huán)打印一個滾動的統(tǒng)計摘要來代替 top 的刷屏。其可用于實時查看，同時也可將你所看到的東西(復制粘貼)到你的調(diào)查記錄中。
上面的例子表明兩個 Java 進程正在消耗 CPU。%CPU 這列是所有 CPU 合計的；1591% 表示這個 Java 進程消耗了將近 16 個 CPU。
6. iostat -xz 1
$ iostat -xz 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
73.96 0.00 3.73 0.03 0.06 22.21
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda 0.00 0.23 0.21 0.18 4.52 2.08 34.37 0.00 9.98 13.80 5.42 2.44 0.09
xvdb 0.01 0.00 1.02 8.94 127.97 598.53 145.79 0.00 0.43 1.78 0.28 0.25 0.25
xvdc 0.01 0.00 1.02 8.86 127.79 595.94 146.50 0.00 0.45 1.82 0.30 0.27 0.26
dm-0 0.00 0.00 0.69 2.32 10.47 31.69 28.01 0.01 3.23 0.71 3.98 0.13 0.04
dm-1 0.00 0.00 0.00 0.94 0.01 3.78 8.00 0.33 345.84 0.04 346.81 0.01 0.00
dm-2 0.00 0.00 0.09 0.07 1.35 0.36 22.50 0.00 2.55 0.23 5.62 1.78 0.03
[...]
這是用于查看塊設備(磁盤)情況的一個很棒的工具，無論是對工作負載還是性能表現(xiàn)來說。查看個列：
r/s, w/s, rkB/s, wkB/s：這些分別代表該設備每秒的讀次數(shù)、寫次數(shù)、讀取 kb 數(shù)，和寫入 kb 數(shù)。這些用于描述工作負載。性能問題可能僅僅是由于施加了過大的負載。
await：以毫秒為單位的 I/O 平均消耗時間。這是應用程序消耗的實際時間，因為它包括了排隊時間和處理時間。比預期更大的平均時間可能意味著設備的飽和，或設備出了問題。
avgqu-sz：向設備發(fā)出的請求的平均數(shù)量。值大于 1 說明已經(jīng)飽和了(雖說設備可以并行處理請求，尤其是由多個磁盤組成的虛擬設備。)
%util：設備利用率。這個值是一個顯示出該設備在工作時每秒處于忙碌狀態(tài)的百分比。若值大于 60％，通常表明性能不佳(可以從 await 中看出)，雖然它取決于設備本身。值接近 100% 通常意味著已飽和。
如果該存儲設備是一個面向很多后端磁盤的邏輯磁盤設備，則 100% 利用率可能只是意味著當前正在處理某些 I/O 占用，然而，后端磁盤可能遠未飽和，并且可能能夠處理更多的工作。
請記住，磁盤 I/O 性能較差不一定是程序的問題。許多技術(shù)通常是異步 I/O，使應用程序不會被阻塞并遭受延遲(例如，預讀，以及寫緩沖)。
7. free -m
$ free -m
total used free shared buffers cached
Mem: 245998 24545 221453 83 59 541
-/+ buffers/cache: 23944 222053
Swap: 0 0 0
右邊的兩列顯式：
buffers：用于塊設備 I/O 的緩沖區(qū)緩存。
cached：用于文件系統(tǒng)的頁面緩存。
我們只是想要檢查這些不接近零的大小，其可能會導致更高磁盤 I/O(使用 iostat 確認)，和更糟糕的性能。上面的例子看起來還不錯，每一列均有很多 M 個大小。
比起第一行，-/+ buffers/cache 提供的內(nèi)存使用量會更加準確些。Linux 會把暫時用不上的內(nèi)存用作緩存，一旦應用需要的時候就立刻重新分配給它。所以部分被用作緩存的內(nèi)存其實也算是空閑的內(nèi)存。為了解釋這一點， 甚至有人專門建了個網(wǎng)站： linuxatemyram。
如果你在 Linux 上安裝了 ZFS，這一點會變得更加困惑，因為 ZFS 它自己的文件系統(tǒng)緩存不算入free -m。有時候發(fā)現(xiàn)系統(tǒng)已經(jīng)沒有多少空閑內(nèi)存可用了，其實內(nèi)存卻都待在 ZFS 的緩存里。
8. sar -n DEV 1
$ sar -n DEV 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
12:16:48 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:49 AM eth0 18763.00 5032.00 20686.42 478.30 0.00 0.00 0.00 0.00
12:16:49 AM lo 14.00 14.00 1.36 1.36 0.00 0.00 0.00 0.00
12:16:49 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
12:16:49 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:50 AM eth0 19763.00 5101.00 21999.10 482.56 0.00 0.00 0.00 0.00
12:16:50 AM lo 20.00 20.00 3.25 3.25 0.00 0.00 0.00 0.00
12:16:50 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
這個工具可以被用來檢查網(wǎng)絡接口的吞吐量：rxkB/s 和 txkB/s，以及是否達到限額。上面的例子中，eth0 接收的流量達到 22Mbytes/s，也即 176Mbits/sec(限額是 1Gbit/sec)
我們用的版本中還提供了 %ifutil 作為設備使用率(接收和發(fā)送的最大值)的指標。我們也可以用 Brendan 的 nicstat 工具計量這個值。一如 nicstat，sar 顯示的這個值是很難精確取得的，在這個例子里面，它就沒在正常的工作(0.00)。
9. sar -n TCP,ETCP 1
$ sar -n TCP,ETCP 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
12:17:19 AM active/s passive/s iseg/s oseg/s
12:17:20 AM 1.00 0.00 10233.00 18846.00
12:17:19 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:20 AM 0.00 0.00 0.00 0.00 0.00
12:17:20 AM active/s passive/s iseg/s oseg/s
12:17:21 AM 1.00 0.00 8359.00 6039.00
12:17:20 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:21 AM 0.00 0.00 0.00 0.00 0.00
這是一些關(guān)鍵的 TCP 指標的匯總視圖。這些包括：
active/s：每秒本地發(fā)起 TCP 連接數(shù)(例如，通過 connect())。
passive/s：每秒遠程發(fā)起的 TCP 連接數(shù)(例如，通過 accept())。
retrans/s：每秒重傳 TCP 次數(shù)。
active 和 passive 的連接數(shù)往往對于描述一個粗略衡量服務器負載是非常有用的：新接受的連接數(shù)(passive)，下行連接數(shù)(active)?？梢岳斫鉃?active 連接是對外的，而 passive 連接是對內(nèi)的，雖然嚴格來說并不完全正確(例如，一個 localhost 到 localhost 的連接)。
重傳是出現(xiàn)一個網(wǎng)絡和服務器問題的一個征兆。其可能是由于一個不可靠的網(wǎng)絡(例如，公網(wǎng))造成的，或許也有可能是由于服務器過載并丟包。上面的例子顯示了每秒只有一個新的 TCP 連接。
10. top
$ top
top - 00:15:40 up 21:56, 1 user, load average: 31.09, 29.87, 29.92
Tasks: 871 total, 1 running, 868 sleeping, 0 stopped, 2 zombie
%Cpu(s): 96.8 us, 0.4 sy, 0.0 ni, 2.7 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 25190241+total, 24921688 used, 22698073+free, 60448 buffers
KiB Swap: 0 total, 0 used, 0 free. 554208 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20248 root 20 0 0.227t 0.012t 18748 S 3090 5.2 29812:58 java
4213 root 20 0 2722544 64640 44232 S 23.5 0.0 233:35.37 mesos-slave
66128 titancl+ 20 0 24344 2332 1172 R 1.0 0.0 0:00.07 top
5235 root 20 0 38.227g 547004 49996 S 0.7 0.2 2:02.74 java
4299 root 20 0 20.015g 2.682g 16836 S 0.3 1.1 33:14.42 java
1 root 20 0 33620 2920 1496 S 0.0 0.0 0:03.82 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:05.35 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:06.94 kworker/u256:0
8 root 20 0 0 0 0 S 0.0 0.0 2:38.05 rcu_sched
top 命令包含了很多我們之前已經(jīng)檢查過的指標。可以方便的執(zhí)行它來查看相比于之前的命令輸出的結(jié)果有很大不同，這表明負載是可變的。
top 的一個缺點是，很難看到數(shù)據(jù)隨時間變動的趨勢。vmstat 和 pidstat 提供的滾動輸出會更清楚一些。如果你不以足夠快的速度暫停輸出(Ctrl-S 暫停，Ctrl-Q 繼續(xù))，一些間歇性問題的線索也可能由于被清屏而丟失。
重慶分公司
重慶分公司
