資訊專欄INFORMATION COLUMN
摘要：針對應(yīng)用，性能診斷工具主要分為兩層層面和應(yīng)用層面包括應(yīng)用代碼診斷和診斷。診斷對于主要關(guān)注平均負載，使用率，上下文切換次數(shù)。常用的應(yīng)用診斷包括線程堆棧等方面的診斷。
性能診斷工具
性能診斷一種是針對已經(jīng)確定有性能問題的系統(tǒng)和代碼進行診斷，還有一種是對預(yù)上線系統(tǒng)提前性能測試，確定性能是否符合上線要求。本文主要針對前者，后者可以用各種性能壓測工具（例如 JMeter）進行測試，不在本文討論范圍內(nèi)。針對 Java 應(yīng)用，性能診斷工具主要分為兩層：OS 層面和 Java 應(yīng)用層面（包括應(yīng)用代碼診斷和 GC 診斷）。
OS 診斷
OS 的診斷主要關(guān)注的是 CPU、Memory、I/O 三個方面。
CPU 診斷
對于 CPU 主要關(guān)注平均負載（Load Average），CPU 使用率，上下文切換次數(shù)（Context Switch）。
通過 top 命令可以查看系統(tǒng)平均負載和 CPU 使用率，圖 2 為通過 top 命令查看某系統(tǒng)的狀態(tài)。
平均負載有三個數(shù)字：63.66，58.39，57.18，分別表示過去 1 分鐘、5 分鐘、15 分鐘機器的負載。按照經(jīng)驗，若數(shù)值小于 0.7*CPU 個數(shù)，則系統(tǒng)工作正常；若超過這個值，甚至達到 CPU 核數(shù)的四五倍，則系統(tǒng)的負載就明顯偏高。圖 2 中 15 分鐘負載已經(jīng)高達 57.18，1 分鐘負載是 63.66（系統(tǒng)為 16 核），說明系統(tǒng)出現(xiàn)負載問題，且存在進一步升高趨勢，需要定位具體原因了。
通過 vmstat 命令可以查看 CPU 的上下文切換次數(shù)，如圖 3 所示：
圖 3.vmstat 命令示例
for(Category c = this; c != null; c=c.parent) {
// Protected against simultaneous call to addAppender, removeAppender,…
synchronized(c) {
if (c.aai != null) {
write += c.aai.appendLoopAppenders(event);
}
…
}
}
Memory
從操作系統(tǒng)角度，內(nèi)存關(guān)注應(yīng)用進程是否足夠，可以使用 free –m 命令查看內(nèi)存的使用情況。通過 top 命令可以查看進程使用的虛擬內(nèi)存 VIRT 和物理內(nèi)存 RES，根據(jù)公式 VIRT = SWAP + RES 可以推算出具體應(yīng)用使用的交換分區(qū)（Swap）情況，使用交換分區(qū)過大會影響 Java 應(yīng)用性能，可以將 swappiness 值調(diào)到盡可能小。因為對于 Java 應(yīng)用來說，占用太多交換分區(qū)可能會影響性能，畢竟磁盤性能比內(nèi)存慢太多。
I/O
I/O 包括磁盤 I/O 和網(wǎng)絡(luò) I/O，一般情況下磁盤更容易出現(xiàn) I/O 瓶頸。通過 iostat 可以查看磁盤的讀寫情況，通過 CPU 的 I/O wait 可以看出磁盤 I/O 是否正常。如果磁盤 I/O 一直處于很高的狀態(tài)，說明磁盤太慢或故障，成為了性能瓶頸，需要進行應(yīng)用優(yōu)化或者磁盤更換。
除了常用的 top、 ps、vmstat、iostat 等命令，還有其他 Linux 工具可以診斷系統(tǒng)問題，如 mpstat、tcpdump、netstat、pidstat、sar 等。Brendan 總結(jié)列出了 Linux 不同設(shè)備類型的性能診斷工具，如圖 4 所示，可供參考。
圖 4.Linux 性能觀測工具
應(yīng)用代碼診斷
應(yīng)用代碼性能問題是相對好解決的一類性能問題。通過一些應(yīng)用層面監(jiān)控報警，如果確定有問題的功能和代碼，直接通過代碼就可以定位；或者通過 top+jstack，找出有問題的線程棧，定位到問題線程的代碼上，也可以發(fā)現(xiàn)問題。對于更復(fù)雜，邏輯更多的代碼段，通過 Stopwatch 打印性能日志往往也可以定位大多數(shù)應(yīng)用代碼性能問題。
常用的 Java 應(yīng)用診斷包括線程、堆棧、GC 等方面的診斷。
jstack
jstack 命令通常配合 top 使用，通過 top -H -p pid 定位 Java 進程和線程，再利用 jstack -l pid 輸出線程棧到控制臺 .jstack -l pid >> xxxfile.dump到文件。由于線程棧是瞬態(tài)的，因此需要多次 dump，一般 3 次 dump，一般每次隔 5s 就行。將 top 定位的 Java 線程 pid 轉(zhuǎn)成 16 進制，得到 Java 線程棧中的 nid，可以找到對應(yīng)的問題線程棧。
圖 5. 通過 top –H -p pid查看運行時間較長 Java 線程
如圖 5 所示，其中的線程 24985 運行時間較長，可能存在問題，轉(zhuǎn)成 16 進制后，通過 Java 線程棧找到對應(yīng)線程 0x6199 的棧如下，從而定位問題點，如圖 6 所示。
圖 6.jstack 查看線程堆棧
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://specialneedsforspecialkids.com/yun/71423.html
摘要：性能調(diào)優(yōu)概述性能優(yōu)化有風(fēng)險和弊端，性能調(diào)優(yōu)必須有明確的目標，不要為了調(diào)優(yōu)而調(diào)優(yōu)盲目調(diào)優(yōu)，風(fēng)險遠大于收益程序性能的主要表現(xiàn)點執(zhí)行速度程序的反映是否迅速，響應(yīng)時間是否足夠短內(nèi)存分配內(nèi)存分配是否合理，是否過多地消耗內(nèi)存或者存在內(nèi)存泄漏啟動時間程序 [TOC] Java性能調(diào)優(yōu)概述 性能優(yōu)化有風(fēng)險和弊端，性能調(diào)優(yōu)必須有明確的目標，不要為了調(diào)優(yōu)而調(diào)優(yōu)！??！盲目調(diào)優(yōu)，風(fēng)險遠大于收益！??！ 程序性...
摘要：原文鏈接本篇是專家系列的第三篇。但是，請記住調(diào)優(yōu)是不得已時的選擇?？s短耗時的單次執(zhí)行與相比，耗時有較明顯的增加。創(chuàng)建文件過程中，進程會中斷，因此不要在正常運行時系統(tǒng)上做此操作。因此校驗結(jié)果并根據(jù)具體的服務(wù)需要，決定是否要進行調(diào)優(yōu)。 原文鏈接：http://www.cubrid.org/blog/dev-platform/how-to-tune-java-garbage-collecti...
摘要：這就是我和大佬的差距嗎看看別人是怎么做性能調(diào)優(yōu)的性能調(diào)優(yōu)后來的幾年里，我又陸續(xù)參與過物流電商游戲支付系統(tǒng)的研發(fā)，這些項目都存在一個共性，就是經(jīng)常會運營一些大促以及搶購類活動。 先給大家講個故事吧。多年前我加入了一家大型互聯(lián)網(wǎng)公司，剛進入就以 996 標準，參與新品研發(fā)。公司業(yè)務(wù)發(fā)展急需互聯(lián)網(wǎng)產(chǎn)品，因此我們的時間很緊張，4 ...
摘要：垃圾回收調(diào)優(yōu)應(yīng)該是提升應(yīng)用吞吐量的最后一個選擇。在你發(fā)現(xiàn)應(yīng)用由于長時間垃圾回收導(dǎo)致了應(yīng)用性能下降出現(xiàn)超時的時候，應(yīng)該考慮垃圾收集調(diào)優(yōu)。全面垃圾收集調(diào)優(yōu)要花費大量的努力和時間，這里沒有一塵不變的硬性調(diào)優(yōu)規(guī)則。 Java垃圾回收調(diào)優(yōu)應(yīng)該是提升應(yīng)用吞吐量的最后一個選擇。在你發(fā)現(xiàn)應(yīng)用由于長時間垃圾回收導(dǎo)致了應(yīng)用性能下降、出現(xiàn)超時的時候，應(yīng)該考慮Java垃圾收集調(diào)優(yōu)。如果你在日志里看到 java...
閱讀 2985·2023-04-26 02:25
閱讀 2258·2023-04-25 18:05
閱讀 650·2021-09-30 09:57
閱讀 2946·2021-09-27 14:10
閱讀 1656·2019-08-30 15:44
閱讀 1005·2019-08-29 15:28
閱讀 2531·2019-08-29 14:10
閱讀 2265·2019-08-29 13:30
