性能分析一直是性能實(shí)施項(xiàng)目中的一個(gè)難點(diǎn)。對(duì)于只做性能測(cè)試不做性能分析的團(tuán)隊(duì)來說，總是不能把問題非常顯性地展示出來，不能給其他團(tuán)隊(duì)非常明確的引導(dǎo)。對(duì)于這種類型的測(cè)試實(shí)施，只能把問題拋出來，讓其他相關(guān)團(tuán)隊(duì)去查。溝通成本很高。
而一個(gè)成熟的性能團(tuán)隊(duì)?wèi)?yīng)該是要把問題點(diǎn)分析出來，給其他團(tuán)隊(duì)或責(zé)任人非常明確的瓶頸點(diǎn)，以加快問題的處理進(jìn)度。
從完整的分析思路上考慮。有兩個(gè)要點(diǎn)：分段和分層。

如上圖所示，分段就是要把 1-6 以及在 server1/2、DB 上消耗的時(shí)間都統(tǒng)計(jì)出來。分層就是要把上圖中各種不同顏色的層都分析到。

可以使用的方法在不同的項(xiàng)目中各不一樣，取決于應(yīng)用的架構(gòu)。

性能分析的深度要到什么程度為宜呢？主要是看組織的結(jié)構(gòu)和項(xiàng)目中涉及到的人的職責(zé)定義。要把握的深度就是讓各團(tuán)隊(duì)沒有技術(shù)上的 Gap。這一點(diǎn)非常重要。

從實(shí)際的操作層面來說，因?yàn)樾阅苤饕窃诖髩毫ο率欠衲鼙３肿r(shí)間的可接受性。所以主要把握如下幾點(diǎn)：

1.從響應(yīng)時(shí)間到具體的代碼；

2.從響應(yīng)時(shí)間到具體的 SQL；

3.從響應(yīng)時(shí)間到具體的配置

有了這幾個(gè)層面的分析，基本上就可以確定一個(gè)問題的瓶頸點(diǎn)了。

在數(shù)據(jù)理解上，有兩個(gè)階段：

1.知道計(jì)數(shù)器的含義：

這個(gè)階段看似簡(jiǎn)單，但能記得住那么多 performance counter 的人并不多，這個(gè)記不住倒是沒有太大關(guān)系，遇到就查，多遇幾次自然就記住了；

比如，對(duì)于上圖來說，要理解的計(jì)數(shù)器就是 await 和 svctm，await 高是肯定存在問題。如果要判斷問題是嚴(yán)重不嚴(yán)重還要看另一個(gè)計(jì)數(shù)器就是 avgqu-sz，它是隊(duì)列長度。svctm 是平均每次 io 的時(shí)間（單位：ms）。

再來看看 CPU 的計(jì)數(shù)器。

CPU 的計(jì)數(shù)器在 top 中有 8 個(gè)，在 mpstat 中多兩個(gè)。在上面的計(jì)數(shù)器中，通常的說法是，us CPU 是用戶態(tài)的，如果這部分高，通常是應(yīng)用代碼消耗的；sy CPU 是系統(tǒng)態(tài)的，如果這部分高，通常是 os 層的配置有問題。
這種說法在大部分情況下是合理的，但是不管是 us CPU 還是 sy CPU，高和低都只是問題的表現(xiàn)。分析到此并不是性能分析的結(jié)束，下面要找到的就是為什么這么高？這一步是非常關(guān)鍵的。一般情況下，分析路徑是：

所以下一步就很清晰了，就是找哪個(gè)進(jìn)程、線程消耗的 CPU 高，進(jìn)而查到代碼。
2.知道計(jì)數(shù)器的值之間的關(guān)系：
這個(gè)階段大部分人都需要好幾年的時(shí)間才能完全掌握常規(guī)的計(jì)數(shù)值，之所以說只能掌握常規(guī)的計(jì)數(shù)值是因?yàn)橛幸恍?shù)值的聯(lián)動(dòng)關(guān)系不是那么容易碰得到。
比如說 CPU 模式對(duì) TPS 和 RT 的影響，大部分人都是拿到硬件的時(shí)候都是 Full performance mode 了，并不關(guān)心還有沒有其他的模式；比如說網(wǎng)絡(luò)計(jì)數(shù)值導(dǎo)致的 TPS 有規(guī)律或無規(guī)律的抖動(dòng)。
這些場(chǎng)景都要求做性能分析的在看到某個(gè)計(jì)數(shù)值的時(shí)候能有直接的反應(yīng)，但是這一點(diǎn)非常難。因?yàn)閿?shù)值的高低對(duì)大部分人來說就是一個(gè)謎，經(jīng)常有人問這樣的問題，這個(gè)值是高還是低，應(yīng)該說只要不是一起工作的人都說不上來某個(gè)值是高還是低（當(dāng)然對(duì)一些非常清晰的場(chǎng)景是比較容易判斷的），合理還是不合理。

如上圖所示：procs 的 b 列很高，這個(gè)值的含義是等 io 的進(jìn)程數(shù)，它在上圖中和 CPU wa 列是對(duì)應(yīng)的。同時(shí)，也和 IO 的 bi、bo 列是對(duì)應(yīng)的，從這幾個(gè)值關(guān)聯(lián)來看下步是要看哪個(gè)進(jìn)程消耗的 IO 多了。

能經(jīng)過數(shù)據(jù)理解的這一層次，才算是到了中級(jí)性能分析工程師的能力。

4.1 壓力工具的曲線

做性能分析，看曲線是最直接了當(dāng)?shù)摹毫ぞ呖梢越o我們的明確的信息就是這個(gè)系統(tǒng)是不是有問題的，這也是壓力工具自身曲線可以明確顯示的唯一的信息。請(qǐng)看下面幾張圖：

TPS 圖：

響應(yīng)時(shí)間圖：

遞增線程圖：

怎么理解這幾張圖呢？

先看張線程圖?？梢灾蓝鄠€(gè)業(yè)務(wù)都有設(shè)置并發(fā)遞增線程。這個(gè)圖能給的信息就是這個(gè)且只有這個(gè)。

結(jié)合 TPS 圖可以知道，在第三個(gè)梯度的時(shí)候，TPS 到了峰值。在第四個(gè)梯度的時(shí)候，TPS 已經(jīng)開始下降了。

再結(jié)合響應(yīng)時(shí)間圖，在第三個(gè)梯度的時(shí)候，響應(yīng)時(shí)間是明顯地抬了頭。后面響應(yīng)時(shí)間在持續(xù)增加，每個(gè)梯度都有增加。

這時(shí)候有兩件動(dòng)作可做：

1.修改場(chǎng)景接著測(cè)試。

如何修改場(chǎng)景？把線程數(shù)降低。降到在梯度增加的過程中，響應(yīng)時(shí)間沒有明顯增加的趨勢(shì)之后再來看 TPS 是什么趨勢(shì)。對(duì)于一個(gè)系統(tǒng)來說，響應(yīng)時(shí)間有增加、TPS 沒有增加（或有下降）、線程數(shù)有增加，這幾個(gè)判斷就明確說明了系統(tǒng)是有瓶頸的，并且也僅能說明這一點(diǎn)。

2.在當(dāng)前場(chǎng)景下，分析瓶頸點(diǎn)，看時(shí)間消耗在哪個(gè)環(huán)節(jié)上。

這兩個(gè)動(dòng)作取決于目標(biāo)，如果 TPS 在第三個(gè)梯度上已經(jīng)達(dá)到了業(yè)務(wù)指標(biāo)，那可以不做優(yōu)化。所以第一個(gè)動(dòng)作的前提是 TPS 目標(biāo)已達(dá)到。

顯然，第二個(gè)動(dòng)作就是 TPS 目標(biāo)還未達(dá)到。

當(dāng)然有人提出 TPS 目標(biāo)達(dá)到了，有瓶頸也是需要優(yōu)化呀？在這一點(diǎn)上，就要看做決定的人怎么考慮了，因?yàn)閮?yōu)化是要付出成本的。接下來再說另一種曲線。

4.2 系統(tǒng)監(jiān)控曲線。

由于操作系統(tǒng)級(jí)的監(jiān)控有非常多的監(jiān)控曲線，這里拿一個(gè)內(nèi)存的來舉例子。

內(nèi)存曲線圖：

對(duì) linux 操作系統(tǒng)來說，操作系統(tǒng)的內(nèi)存會(huì)慢慢被分配掉，變成 caching memory。所以如果只看 available memory 的意義并不大，需要 -/+ buffer/cache 之后再看可用內(nèi)存。這一點(diǎn)大家都清楚。

那么上面是不是說內(nèi)存沒有問題呢？當(dāng)然不是。因?yàn)閮?nèi)存不僅被用光了，而且還斷了一段，后面又有了數(shù)據(jù)，接著又用光，又?jǐn)嗔艘欢螘r(shí)間。紅色的框中，是有問題的，因?yàn)檫@一段連數(shù)據(jù)都沒有抓到，抓數(shù)據(jù)的進(jìn)程應(yīng)該是沒了。

所以 available memory 的下降并不是要關(guān)注的重點(diǎn)，-/+ buffer/cache 之后的 available memory 才是要關(guān)注的重點(diǎn)。另外從上圖中看到的斷掉的時(shí)間點(diǎn)也是要分析的重點(diǎn)。

另外，上圖中，藍(lán)框內(nèi)內(nèi)存一直在很低的狀態(tài)，后面卻突然升高了那么多。這里也是要分析的重點(diǎn)。

JVM 圖

對(duì) JVM 曲線來說，也是要看趨勢(shì)的，基礎(chǔ)知識(shí)是 jvm gc 的邏輯。YGC 一直在做，heap 一直在增加，這個(gè)過程是不是正常的呢？對(duì)于沒有做過 Full GC 的 JVM 來說，heap 是有增加的趨勢(shì)是可以理解的，但是這個(gè) “理解” 需要一個(gè)前提，就是業(yè)務(wù)有沒有增量。

如果是有業(yè)務(wù)的增量，上圖就是正常的；如果沒有業(yè)務(wù)增量，上圖就是不正常的，那什么樣的才是沒有業(yè)務(wù)增量的正常呢？看下圖：

上圖就明顯是個(gè)非常正常的 JVM。

對(duì)于曲線的理解，首先要知道的是數(shù)據(jù)的來源和含義。在性能分析中，有很多曲線的趨勢(shì)都不是可以直接指明問題的，只能通過收集全部的信息來做完整的分析才能判斷問題存在點(diǎn)。

上面舉了兩個(gè)例子的角度分別是：壓力工具生成的曲線和后端服務(wù)器相應(yīng)的工具生成的曲線。就是為了說明一點(diǎn)：曲線分析是在關(guān)注所有的層面。

連續(xù)三天，晚上在執(zhí)行一個(gè)業(yè)務(wù)場(chǎng)景持續(xù)幾個(gè)小時(shí)之后，就開始連續(xù)報(bào)錯(cuò)。服務(wù)器連不上了。但在報(bào)錯(cuò)的一開始，并不是全部都報(bào)錯(cuò)，而是有部分是可以成功的，但是過一段時(shí)間之后，所有業(yè)務(wù)都報(bào)錯(cuò)了。次日來看，發(fā)現(xiàn)進(jìn)程不見了。

本來以為是進(jìn)程崩潰退出了，那日志中應(yīng)該留下來些證據(jù)。但是打開了日志查看了一下，沒有任何異常信息。連續(xù)三天都出現(xiàn)。就登錄 zabbix 上去看了一下主機(jī)資源。

紅框內(nèi)的是出現(xiàn)問題的時(shí)間段?？吹竭@里似乎明白了為什么并不是所有業(yè)務(wù)都失敗。因?yàn)閮?nèi)存還有上升的這個(gè)階段。但是為什么降到底之后又上去，再次降到底呢？先看一下拓?fù)鋱D。
兩個(gè)主機(jī)，四個(gè)進(jìn)程，既然進(jìn)程都沒了，應(yīng)該不是一塊沒的，要不然不會(huì)還有業(yè)務(wù)可以成功。
翻了一下應(yīng)用日志，確實(shí)沒有什么和進(jìn)程消失相關(guān)的錯(cuò)誤信息。
既然是進(jìn)程沒了，日志也沒信息，那下一步是什么呢？就是看 dmesg 了。系統(tǒng)日志總有些信息吧。進(jìn)程死了無非就那么幾個(gè)地方能看到。
4.應(yīng)用日志；
5.出 dump；
6.系統(tǒng)日志。

在這里提醒一下，最好直接運(yùn)行 dmesg 命令，而不是去看 /var/log/dmesg 文件。因?yàn)槊钪袝?huì)把其他 message 也放進(jìn)去，會(huì)全一點(diǎn)。
查看了 dmesg 之后，發(fā)現(xiàn)如下信息：

從時(shí)間上來算一下。系統(tǒng)運(yùn)行時(shí)間 41.45 天，確實(shí)和第一個(gè)圖上的 21：30 的時(shí)間對(duì)應(yīng)得上。從這里來看是 6341 進(jìn)程被殺了。
再看第二個(gè)圖：

再來算一下時(shí)間。41.55 天，和第一個(gè)圖上的 11：45 能對(duì)得上。
看來是 OOM Killer 主動(dòng)把這兩個(gè)進(jìn)程給殺了。從下面的信息來看是這兩個(gè)進(jìn)程消耗 linux 主機(jī)的物理內(nèi)存和虛擬內(nèi)存太大，以致于把內(nèi)存都給消耗光了，最后 OOM Killer 就站出來主持公道了：小子挺橫呀，老子分給你了一畝三分地，不好好呆著，敢來搶地盤，干它！
于是就真的被 kill 了。
既然知道了內(nèi)存消耗得多，那這個(gè)場(chǎng)景就好復(fù)現(xiàn)了。接著用原場(chǎng)景測(cè)試?？聪?Java 進(jìn)程的內(nèi)存，Java 的內(nèi)存分成堆內(nèi)堆外。因?yàn)槭遣僮飨到y(tǒng)的 OOM Killer 干掉的，所以基本上可以排除堆內(nèi)的內(nèi)存導(dǎo)致的。因?yàn)槎咽怯邢拗频穆铩?br>既然這樣，那就是堆外。打個(gè) threaddump 看看。

怎么這么多線程？并且也看到了開發(fā)的包名。
把這個(gè)路徑給了開發(fā)之后，讓他們翻翻這一段的源碼，看到類似如下內(nèi)容：Threadthread=newThread();（當(dāng)然還有調(diào)用的代碼，就不一一羅列了）開發(fā)這才知道是為啥有這么多新創(chuàng)建的線程。于是拿回去改去了。
用戶遞增圖：

TPS 圖：

通過查看網(wǎng)絡(luò)連接狀態(tài)，看到有大量的 TIME_WAIT 出現(xiàn)。

嘗試分析過程如下:

1.為 TIME_WAIT 修改 TCP 參數(shù)

通過檢查 sysctl.conf，看到所有的配置均為默認(rèn)，于是嘗試如下修改：

7. net.ipv4.tcp_tw_recycle = 1

8. net.ipv4.tcp_tw_reuse = 1

9. net.ipv4.tcp_fin_timeout = 3

10. net.ipv4.tcp_keepalive_time = 3

回歸測(cè)試，問題依舊。

2.修改 Nginx 的 proxyignoreclient_abort

考慮到當(dāng)客戶端主動(dòng)斷開時(shí)，服務(wù)器上也會(huì)出現(xiàn)大量的 TIME_WAIT，所以打開 proxy_ignore_client_abort，讓 Nginx 忽略客戶端主動(dòng)中斷時(shí)出現(xiàn)的錯(cuò)誤。proxy_ignore_client_abort on;修改后，重啟 Nginx，問題依舊。

3.修改 tomcat 參數(shù)

查看 tomcat 的 server.xml 時(shí)，看到只設(shè)置了 maxthreads。考慮到線程的分配和釋放也會(huì)消耗資源。所以在這里加入如下參數(shù)：maxKeepAliveRequests="256"minSpareThreads="100"maxSpareThreads=“200”。

重啟 tomcat，問題依舊。

4.換 Nginx 服務(wù)器

在分段測(cè)試的時(shí)候，看到通過 Nginx 就會(huì)出現(xiàn) TPS 上到 300 就會(huì)下降的情況，所以考慮是 Nginx 機(jī)器的配置問題，于是換了在另一臺(tái)機(jī)器上重新編譯了 Nginx，所有的操作系統(tǒng)都是一樣的配置。

通過新的 Nginx 做壓力，問題依舊，所以可以判斷這個(gè)問題是和操作系統(tǒng)的配置有關(guān)，和 Nginx 本身的配置無關(guān)。

5.停掉防火墻

和網(wǎng)絡(luò)連接有關(guān)的內(nèi)容，剩下的就只有防火墻了。于是執(zhí)行了：Serviceiptables stop。在執(zhí)行了之后，看到 TPS 立即就上去了。并且可以增加得非常高。從而定位，TPS 的下降和防火墻有關(guān)。

6.系統(tǒng)日志

進(jìn)到 /var/log，查看 messages，看到大量的如下信息：

11.Nov 4 11:35:48 localhost kernel: __ratelimit: 108 callbacks suppressed

12.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.

13.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.

14.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.

15.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.

16.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.

17.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.

18.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.

19.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.

20.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.

21.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.

22.Nov 4 11:35:53 localhost kernel: __ratelimit: 592 callbacks suppressed

23.Nov 4 11:35:53 localhost kernel: nf_conntrack: table full, dropping packet.

24.Nov 4 11:35:53 localhost kernel: nf_conntrack: table full, dropping packet.

25.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.

26.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.

27.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.

28.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.

29.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.

30.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.

31.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.

32.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.

33.Nov 4 11:35:58 localhost kernel: __ratelimit: 281 callbacks suppressed

34.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.

35.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.

36.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.

37.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.

38.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.

39.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.

40.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.

41.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.

42.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.

43.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.

44.Nov 4 11:36:14 localhost kernel: __ratelimit: 7 callbacks suppressed

7.參數(shù)修改

因?yàn)槌霈F(xiàn)大量的 nf_conntrack:table full,dropping packet。所以在 sysctl.conf 中加入了如下參數(shù)設(shè)置。

45.net.netfilter.nf_conntrack_max = 655350

46.net.netfilter.nf_conntrack_tcp_timeout_established = 1200

修改參數(shù)后，執(zhí)行：Serviceiptables start.可以看到，TPS 仍然可以很高，從而解決問題。

解決問題后的 TPS 圖：

上圖中有兩次 TPS 下降的過程是因?yàn)橛謬L試了修改防火墻的參數(shù)配置，重啟了兩次防火墻。

綜上，對(duì)于性能分析來說，不僅是現(xiàn)象的解釋，還有瓶頸的定位及問題的解決。這些工作所要求的基礎(chǔ)知識(shí)較多，一個(gè)人力不能及的時(shí)候，就需要一個(gè)團(tuán)隊(duì)來做。關(guān)鍵是要把問題分析得清晰透徹。(end)