后端服務(wù)性能壓測(cè)實(shí)踐-創(chuàng)新互聯(lián)

后端服務(wù)性能壓測(cè)實(shí)踐

標(biāo)簽： 性能 壓測(cè) 后端服務(wù) 壓測(cè)實(shí)踐

成都創(chuàng)新互聯(lián)公司2013年成立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計(jì)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命，1280元繁峙做網(wǎng)站,已為上家服務(wù),為繁峙各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:028-86922220

作者：王清培(Plen wang)

---

• 背景
• 環(huán)境檢測(cè)
  • 壓力機(jī)及壓力工具檢測(cè)
  • Linux openfiles limit 設(shè)置
  • 排查周邊依賴
  • 空接口壓測(cè)檢測(cè)
  • 聚合報(bào)告中 throughput 計(jì)算
• 壓測(cè)及性能排查方法
  • 關(guān)注各緯度 log
  • Linux 常規(guī)命令
  • 性能排查兩種方式（從上往下、從下往上）
• 總結(jié)

背景

最近大半年內(nèi)有過兩次負(fù)責(zé)性能壓測(cè)的一些工作。一件事情做了一次可能還無(wú)法總結(jié)出一些東西，兩次過后還是能發(fā)現(xiàn)一些共性問題，所以總結(jié)下性能壓測(cè)的一般性實(shí)踐。但是問題肯定不止這些，還有更多深層次的問題等著發(fā)現(xiàn)，等我們遇到了在逐個(gè)解決再來總結(jié)分享。

做性能壓測(cè)的原因就不多說了，一般兩個(gè)時(shí)間點(diǎn)是必須要做的，大促前、新系統(tǒng)上線。壓測(cè)都是為了系統(tǒng)在線上的處理能力和穩(wěn)定性維持在一個(gè)標(biāo)準(zhǔn)范圍內(nèi)，做到心中有數(shù)。

從整個(gè)行業(yè)來看，拋開一些大廠不說，全自動(dòng)化的性能壓測(cè)環(huán)境還是比較少的，要想建設(shè)好一套全自動(dòng)化的性能壓測(cè)環(huán)境起碼涉及到幾個(gè)問題，CI\CD、獨(dú)立、隔離的壓測(cè)環(huán)境，自動(dòng)化壓測(cè)工具、日常壓測(cè)性能報(bào)警、性能報(bào)表分析、排查/解決性能問題流程等等。這樣才能將性能壓測(cè)常規(guī)化，一旦不是常規(guī)化性能壓測(cè)，就會(huì)有代碼、中間件配置滯后于生產(chǎn)環(huán)境的問題。時(shí)間一長(zhǎng)，就等于要重新開始搭建、排查壓測(cè)環(huán)境。

如果性能壓測(cè)的環(huán)境是全自動(dòng)化的，那么就可以把性能壓測(cè)工作常規(guī)化變成研發(fā)過程中的一個(gè)例行的事項(xiàng)，執(zhí)行起來效率就會(huì)非常高，壓測(cè)的時(shí)候也會(huì)比較輕松，好處也是比較明顯的。

但是大多數(shù)的時(shí)候我們還是需要從零開始進(jìn)行性能壓測(cè)的工作。畢竟搭建這樣一套環(huán)境給企業(yè)帶來的成本也是巨大的。性能壓測(cè)對(duì)環(huán)境敏感，必須劃分獨(dú)立的部署、隔離單元，才能在后續(xù)的常規(guī)壓測(cè)流程中直觀的閱讀壓測(cè)報(bào)告。

題外話，如果有了自動(dòng)化的壓測(cè)環(huán)境，也還是需要去了解下整個(gè)壓測(cè)環(huán)境的基本架構(gòu)，畢竟壓測(cè)環(huán)境不是真實(shí)的生產(chǎn)環(huán)境，有些問題我們需要知道是正常的還是不正常的。

環(huán)境檢測(cè)

當(dāng)我們需要進(jìn)行性能壓測(cè)時(shí)首先要面對(duì)的問題就是環(huán)境問題，環(huán)境問題包含了常見的幾個(gè)點(diǎn)：

1.機(jī)器問題（實(shí)體機(jī)還是虛擬機(jī)、CPU、內(nèi)存、網(wǎng)絡(luò)適配器進(jìn)出口帶寬、硬盤大小，硬盤是否SSD、內(nèi)核基本參數(shù)配置）

2.網(wǎng)絡(luò)問題（是否有跨網(wǎng)段問題、網(wǎng)段是否隔離、如果有跨網(wǎng)段機(jī)器，是否能訪問、跨網(wǎng)段是否有帶寬限速）

3.中間件問題（程序里所有依賴的中間件是否有部署，中間件的配置是否初始化、中間件cluster結(jié)構(gòu)什么樣、這些中間件是否都進(jìn)行過性能壓測(cè)、壓測(cè)的緯度是什么，是benchmark還是針對(duì)特定業(yè)務(wù)場(chǎng)景的壓測(cè)）

這些環(huán)境問題第一次排查的時(shí)候會(huì)有點(diǎn)累，但是掌握了一些方法、工具、流程之后剩下的也就是例行的事情，只不過人工參與的工作多點(diǎn)。

上面的問題里，有些問題查看是比較簡(jiǎn)單的，這里就不介紹了，比如機(jī)器的基本配置等。有些配置只需要你推動(dòng)下，走下相關(guān)流程回頭驗(yàn)收下，比如網(wǎng)段隔離等，也還是比較簡(jiǎn)單的。

比較說不清楚的是中間件問題，看上去都是能用的，但是就是壓不上去，這時(shí)候就需要你自己去進(jìn)行簡(jiǎn)單的壓測(cè)，比如db的單表插入、cache的并發(fā)讀取、mq的落地寫入等。這時(shí)候就涉及到一個(gè)問題，你需要對(duì)這些中間件都有一定深度的了解，要知道內(nèi)在的運(yùn)行機(jī)制，要不然出現(xiàn)異常情況排查起來確實(shí)很困難。

其實(shí)沒有人能熟悉市面上所有的中間件，每一個(gè)中間件都很復(fù)雜，我們也不可能掌握一個(gè)中間件的所有點(diǎn)，但是常用的一些我們是需要掌握的，至少知道個(gè)大概的內(nèi)部結(jié)構(gòu)，可以順藤摸瓜的排查問題。

但是事實(shí)上總有你不熟悉的，這個(gè)時(shí)候求助下大家的力量互相探討再自己摸索找點(diǎn)資料，我們沒遇到過也許別人遇到過，學(xué)技術(shù)其實(shí)就是這么個(gè)過程。

壓力機(jī)及壓力工具檢測(cè)

既然做性能壓測(cè)就需要先對(duì)壓測(cè)機(jī)、壓力工具先進(jìn)行了解，壓測(cè)工具我們主要有locust、jmeter、ab，前兩者主要是壓測(cè)同事進(jìn)行準(zhǔn)出驗(yàn)收測(cè)試使用的。

后兩者主要是用來提交壓測(cè)前的自檢使用，就是開發(fā)自己用來檢查和排錯(cuò)使用的。這里需要強(qiáng)調(diào)下ab其實(shí)是做基準(zhǔn)測(cè)試的，不同于jmeter的作用。

需要知道壓力機(jī)是否和被壓測(cè)機(jī)器服務(wù)器在一個(gè)網(wǎng)段，且網(wǎng)段之間沒有任何帶寬限制。壓力機(jī)的壓測(cè)工具配置是否有瓶頸，一般如果是jmeter的話需要檢查java的一些基本配置。

但是一般如果壓力機(jī)是固定不變的，一直在使用的，那么基本不會(huì)有什么問題，因?yàn)閴毫C(jī)壓測(cè)同事一直維護(hù)者，反而是自己使用的壓測(cè)工具的參數(shù)要做好配置和檢測(cè)。

用jmeter壓測(cè)的時(shí)候，如果壓測(cè)時(shí)間過長(zhǎng)，記得關(guān)掉監(jiān)聽器->圖形結(jié)果面板，因?yàn)槟莻€(gè)渲染如果時(shí)間太長(zhǎng)基本會(huì)假死，誤以為會(huì)是內(nèi)存的問題，其實(shí)是渲染問題。

在開發(fā)做基準(zhǔn)壓測(cè)的時(shí)候有一個(gè)問題就是辦公網(wǎng)絡(luò)與壓測(cè)服務(wù)器的網(wǎng)絡(luò)之間的帶寬問題，壓力過大會(huì)導(dǎo)致辦公網(wǎng)絡(luò)出現(xiàn)問題。所以需要錯(cuò)開時(shí)間段。

大致梳理好后，我們需要通過一些工具來查看下基本配置是否正常。比如，ethtool網(wǎng)絡(luò)適配器信息、nload流量情況等等，當(dāng)然還有很多其他優(yōu)秀的工具用來查看各項(xiàng)配置，這里就不羅列了。

使用ethtool查看網(wǎng)絡(luò)適配器信息前需要先確定當(dāng)前機(jī)器有幾個(gè)網(wǎng)絡(luò)適配器，最好的辦法是使用ifconfig找到你正在使用的網(wǎng)絡(luò)適配器。

排除127.0.0.1的適配器外，還有三個(gè)適配器信息，只有第一個(gè)bond0才是我們正在使用的，然后使用ethtool查看當(dāng)前bond0的詳細(xì)適配器信息。重點(diǎn)關(guān)注下speed域，它表示當(dāng)前網(wǎng)絡(luò)適配器的帶寬。

雖然網(wǎng)絡(luò)適配器可能配置的沒有問題，但是整個(gè)網(wǎng)絡(luò)是否沒問題還需要咨詢相關(guān)的運(yùn)維同事進(jìn)行排查下，中間還可能存在限速問題。

要確定網(wǎng)絡(luò)帶寬確實(shí)沒有問題，我們還需要一個(gè)實(shí)時(shí)的監(jiān)控網(wǎng)絡(luò)流量工具，這里我們使用nload來監(jiān)控下進(jìn)出口流量問題。

這個(gè)工具還是很不錯(cuò)的，尤其是在壓測(cè)的過程中可以觀察流量的進(jìn)出口情況，尤其是排查一些間隙抖動(dòng)情況。

如果發(fā)現(xiàn)進(jìn)口流量一直很正常，出口流量下來了有可能系統(tǒng)對(duì)外調(diào)用再放慢，有可能是下游調(diào)用block，但是request線程池還未跑滿，也有可能內(nèi)部是純async，request線程根本不會(huì)跑滿，也有可能是壓測(cè)工具本身的壓力問題等等。但是我們至少知道是自己的系統(tǒng)對(duì)外調(diào)用這個(gè)邊界出了問題。

Linux openfiles limit 設(shè)置

工作環(huán)境中，一般情況下linux打開文件句柄數(shù)上限是不需要我們?cè)O(shè)置的，這些初始化的值運(yùn)維同事一般是設(shè)置過的，而且是符合運(yùn)維統(tǒng)一標(biāo)準(zhǔn)的。但是有時(shí)候關(guān)于大連接數(shù)設(shè)置還要根據(jù)后端系統(tǒng)的使用場(chǎng)景來決定。

以防萬(wàn)一我們還是需要自己檢查下是否符合當(dāng)前系統(tǒng)的壓測(cè)要求。

在Linux中一切都是文件，socket也是文件，所以需要查看下當(dāng)前機(jī)器對(duì)于文件句柄打開的限制，查看ulimit -a的open files域，也可以直接查看ulimit -n。

如果覺得配置的參數(shù)需要調(diào)整，可以通過編輯/etc/security/limits.conf配置文件。

排查周邊依賴

要想對(duì)一個(gè)服務(wù)進(jìn)行壓測(cè)，就需要對(duì)這個(gè)服務(wù)周邊依賴進(jìn)行一個(gè)排查，有可能你所依賴的服務(wù)不一定具備壓測(cè)條件。并不是每個(gè)系統(tǒng)的壓測(cè)都在一個(gè)時(shí)間段內(nèi)，所以你在壓測(cè)的時(shí)候別人的服務(wù)也許并不需要壓測(cè)等等。

還有類似中間件的問題，比如，如果我們依賴中間件cache，那么是否有本地一級(jí)cache，如果有的話也許對(duì)壓測(cè)環(huán)境的中間件cache依賴不是太大。如果我們依賴中間件mq，是不是在業(yè)務(wù)上可以斷開對(duì)mq的依賴，因?yàn)槲覀儺吘共皇菍?duì)mq進(jìn)行壓測(cè)。還有我們所依賴服務(wù)也不關(guān)心我們的壓測(cè)波動(dòng)。

整理出來之后最好能畫個(gè)草圖，再重新git branch -b重新拉一個(gè)性能壓測(cè)的branch出來根據(jù)草圖進(jìn)行調(diào)整代碼依賴。然后壓測(cè)的時(shí)候觀察流量和數(shù)據(jù)的走向，是否符合我們梳理之后的路線。

空接口壓測(cè)檢測(cè)

為了快速驗(yàn)證壓測(cè)服務(wù)一個(gè)簡(jiǎn)單的辦法，就是通過壓測(cè)一個(gè)空接口，查看下整個(gè)網(wǎng)絡(luò)是否通暢，各個(gè)參數(shù)是否大體上正常。

一般在任何一個(gè)后端服務(wù)中，都有類似 __health_check的endpoint，方便起見可以直接找一個(gè)沒有任何下游依賴的接口進(jìn)行壓測(cè)，這類接口主要是為了驗(yàn)證服務(wù)器的online、offline__ 狀態(tài)。

如果當(dāng)前服務(wù)沒有類似 __health_check__ 新建一個(gè)空接口也可以，而且實(shí)踐證明，一個(gè)服務(wù)在生產(chǎn)環(huán)境非常需要這么一個(gè)接口，必要情況下可以幫助來排查調(diào)用鏈路問題。

《發(fā)布！軟件的設(shè)計(jì)與部署》Jolt 大獎(jiǎng)圖書 第17章 透明性 介紹了架構(gòu)的透明性設(shè)計(jì)作用。

聚合報(bào)告中 throughput 計(jì)算

我們?cè)谟?strong>jmeter進(jìn)行壓測(cè)的時(shí)候關(guān)于聚合報(bào)告中的throughput理解需要統(tǒng)一下。

正常情況下在使用jmeter壓測(cè)的時(shí)候會(huì)仔細(xì)觀察throughput這一列的變化情況，但是沒有搞清楚thourghput的計(jì)算原理的時(shí)候就會(huì)誤以為是tps／qps下來了，其實(shí)有時(shí)候是整個(gè)遠(yuǎn)程服務(wù)器根本就沒有response了。

throughput=samples/壓測(cè)時(shí)間

throughput(吞吐量)是單位時(shí)間內(nèi)的請(qǐng)求處理數(shù)，一般是按second計(jì)算，如果是壓測(cè)write類型的接口，那么就是tps指標(biāo)。如果壓測(cè)read類型的接口，那么就是qps指標(biāo)。這兩種類型的指標(biāo)是完全不一樣的，我們不能搞混淆了。

200(throughput) tps=1000(write)/5(s)
1000(throughput) qps=2000(read)/2(s)

當(dāng)我們發(fā)現(xiàn)throughput逐漸下來的時(shí)候要考慮一個(gè)時(shí)間的緯度。

也就是說我們的服務(wù)有可能已經(jīng)不響應(yīng)了，但是隨著壓測(cè)時(shí)間的積累，整個(gè)吞吐量的計(jì)算自然就在緩慢下滑，像這種刺尖問題是發(fā)現(xiàn)不了的。

這一點(diǎn)用ui版本的jmeter尤其明顯，因?yàn)樗谋憩F(xiàn)方式就是在歡歡放慢。用Linux版本的jmeter還好點(diǎn)，因?yàn)樗妮敵龃蛴∈歉魯鄷r(shí)間才打印。

關(guān)于這個(gè)點(diǎn)沒有搞清楚非常影響我們對(duì)性能壓測(cè)的結(jié)果判斷。所以我們?cè)趬簻y(cè)的時(shí)候一定要有監(jiān)控報(bào)表，才能知道在整個(gè)壓測(cè)過程中服務(wù)器的各項(xiàng)指標(biāo)是否出現(xiàn)過異常情況。

大多數(shù)的時(shí)候我們還會(huì)使用apache ab做下基本的壓測(cè)，主要是用來與jmeter對(duì)比下，兩個(gè)工具壓測(cè)的結(jié)果是否相差不大，主要用來糾偏一些性能虛高問題。

apache ab與jmeter各有側(cè)重，ab可以按固定請(qǐng)求數(shù)來壓，jmeter可以按時(shí)間來壓，最后計(jì)算的時(shí)候需要注意兩者區(qū)別。ab好像是沒有請(qǐng)求錯(cuò)誤提示和中斷的，jmeter是有錯(cuò)誤提示，還有各個(gè)緯度斷言設(shè)置。

我們?cè)谑褂脡簻y(cè)工具的時(shí)候，大致了解下工具的一些原理有助于準(zhǔn)確的使用這款工具。

壓測(cè)及性能排查方法

在文章的前面部分講到了排查周邊依賴的環(huán)境檢查步驟。其實(shí)要想順利的進(jìn)行壓測(cè)，這一步是必須要有的。經(jīng)過這一步分析我們會(huì)有一個(gè)基本的系統(tǒng)依賴 roadmap。

基于這份系統(tǒng)依賴 roadmap我們將進(jìn)行性能壓測(cè)和問題定位及性能優(yōu)化。

合理的系統(tǒng)架構(gòu)應(yīng)該是上層依賴下層，在沒有確定下游系統(tǒng)性能的情況下，是沒辦法確定上游系統(tǒng)性能的瓶頸在哪里。

所以壓測(cè)的順序應(yīng)該盡可能的從下往上依次進(jìn)行，這樣可以避免無(wú)意義的排查由于下游吞吐量不夠帶來的性能問題。越是下游系統(tǒng)性能要求越高，因?yàn)樯嫌蜗到y(tǒng)的性能瓶頸直接依賴下游系統(tǒng)。

比如，商品系統(tǒng)的v1/product/{productid}前臺(tái)接口，吞吐量為qps 8000，那么所有依賴這個(gè)接口的上游服務(wù)在這個(gè)代碼路徑上最高吞吐量瓶頸就是8000，代碼路徑不管是tps還是qps都是一樣的瓶頸。

上層服務(wù)可以使用async方式來提高request并發(fā)量，但是無(wú)法提高代碼路徑在v1/product/{productid}業(yè)務(wù)上的吞吐量。

我們不能將并發(fā)和吞吐量搞混淆了，系統(tǒng)能扛住多少并發(fā)不代表吞吐量就很高?？梢杂泻芏喾绞絹硖岣卟l(fā)量，threadpool提高線程池大小 、socket類c10k 、nio事件驅(qū)動(dòng)，諸如此類方法。

關(guān)注各緯度 log

當(dāng)在壓測(cè)的過程中定位性能問題的性價(jià)比較高的方法就是請(qǐng)求處理的log，請(qǐng)求處理時(shí)長(zhǎng)log，對(duì)外接口調(diào)用時(shí)長(zhǎng)log，這一般能定位大部分比較明顯的問題。當(dāng)我們用到了一些中間件的時(shí)候都會(huì)輸出相應(yīng)的執(zhí)行l(wèi)og。

如下所示，在我們所使用的開發(fā)框架中支持了很多緯度的執(zhí)行l(wèi)og，這在排查問題的時(shí)候就會(huì)非常方便。

slow.log類型的慢日志還是非常有必要記錄下來的，這不僅在壓測(cè)的時(shí)候需要，在生產(chǎn)上我們也是非常需要。

如果我們使用了各種中間件，那就需要輸出各種中間件的處理日志，mq.log、cache.log、search.log諸如此類。

除了這些log之外，我們還需要重點(diǎn)關(guān)注運(yùn)行時(shí)的gc log。

我們主要使用Java平臺(tái)，在壓測(cè)的時(shí)候關(guān)注gc log是正常的事。哪怕不是Java程序，類似基于vm的語(yǔ)言都需要關(guān)注gc log。根據(jù)jvm gcer配置的不同，輸出的日志也不太一樣。

一般電商類的業(yè)務(wù)，以響應(yīng)為優(yōu)先時(shí)gc主要是使用cms+prenew，關(guān)注full gc頻次，關(guān)注cms初始標(biāo)記、并發(fā)標(biāo)記、重新標(biāo)記、并發(fā)清除各個(gè)階段執(zhí)行時(shí)間，gc執(zhí)行的real time，pernew執(zhí)行時(shí)的內(nèi)存回收大小等 。

java gc比較復(fù)雜涉及到的東西也非常多，對(duì)gc log的解讀也需要配合當(dāng)前的內(nèi)存各個(gè)代的大小及一系列gc的相關(guān)配置不同而不同。

《Java性能優(yōu)化權(quán)威指南》 java之父gosling推薦，可以長(zhǎng)期研究和學(xué)習(xí)。

Linux 常規(guī)命令

在壓測(cè)的過程中為了能觀察到系統(tǒng)的各項(xiàng)資源消耗情況我們需要借助各種工具來查看，主要包括網(wǎng)絡(luò)、內(nèi)存、處理器、流量。

###netstat
主要是用來查看各種網(wǎng)絡(luò)相關(guān)信息。

比如，在壓測(cè)的過程中，通過netstat wc看下tcp連接數(shù)是否和服務(wù)器threadpool設(shè)置的匹配。

netstat -tnlp | grep ip | wc -l

如果我們服務(wù)器的threadpool設(shè)置的是50，那么可以看到tcp連接數(shù)應(yīng)該是50才對(duì)。然后再通過統(tǒng)計(jì)jstack服務(wù)器的requestruning狀態(tài)的線程數(shù)是不是>=50。

request線程數(shù)的描述信息可能根據(jù)使用的nio框架的不同而不同。

還有使用頻率最高的查看系統(tǒng)啟動(dòng)的端口狀態(tài)、tcp連接狀態(tài)是establelished還是listen狀態(tài)。

netstat -tnlp

再配合ps命令查看系統(tǒng)啟動(dòng)的狀態(tài)。這一般用來確定程序是否真的啟動(dòng)了，如果啟動(dòng)了是不是listen的端口與配置中指定的端口不一致。

ps aux | grep ecm-placeorder

netstat 命令很強(qiáng)大有很多功能，如果我們需要查看命令的其他功能，可以使用man netstat 翻看幫助文檔。

vmstat

主要用來監(jiān)控虛擬處理器的運(yùn)行隊(duì)列統(tǒng)計(jì)信息。

vmstat 1

在壓測(cè)的時(shí)候可以每隔1s或2s打印一次，可以查看處理器負(fù)載是不是過高。procs列r子列就是當(dāng)前處理器的處理隊(duì)列，如果這個(gè)值超高當(dāng)前cpu core數(shù)那么處理器負(fù)載將過高?？梢院拖旅鎸⒔榻B的top命令搭配著監(jiān)控。

同時(shí)此命令可以在處理器過高的時(shí)候，查看內(nèi)存是否夠用是否出現(xiàn)大量的內(nèi)存交換，換入換出的量多少swap si換入swap so換出。是否有非常高的上下文切換system cs每秒切換的次數(shù)，system us用戶態(tài)運(yùn)行時(shí)間是否很少。是否有非常高的io wait等等。

關(guān)于這個(gè)命令網(wǎng)上已經(jīng)有很多優(yōu)秀的文章講解，這里就不浪費(fèi)時(shí)間重復(fù)了。同樣可以使用man vmstat命令查看各種用法。

mpstat

主要用來監(jiān)控多處理器統(tǒng)計(jì)信息

mpstat -P ALL 1

我這是一個(gè)32 core的壓測(cè)服務(wù)器，通過mpstat可以監(jiān)控每一個(gè)虛擬處理器的負(fù)載情況。也可以查看總的處理器負(fù)載情況。

mpstat 1

可以看到%idle處于閑置狀態(tài)的cpu百分比，%user用戶態(tài)任務(wù)占用的cpu百分比，%sys系統(tǒng)態(tài)內(nèi)核占用cpu百分比，%soft軟中斷占用cpu百分比，%nice調(diào)整任務(wù)優(yōu)先級(jí)占用的cpu百分比等等。

iostat

主要用于監(jiān)控io統(tǒng)計(jì)信息

iostat 1

如果我們有大量的io操作的話通過iostat監(jiān)控io的寫入和讀取的數(shù)據(jù)量，同時(shí)也能看到在io負(fù)載特別大的情況下cpu的平均負(fù)載情況。

top

監(jiān)控整個(gè)系統(tǒng)的整體性能情況
top命令是我們?cè)谌粘Ｇ闆r下使用頻率最高的，可以對(duì)當(dāng)前系統(tǒng)環(huán)境了如指掌。處理器load率情況，memory消耗情況，哪個(gè)task消耗cpu、memory最高。

top

top命令功能非常豐富，可以分別根據(jù)%MEM、%CPU排序。

load average域表示cpu load率情況，后面三段分別表示最近1分鐘、5分鐘、15分鐘的平均load率。這個(gè)值不能大于當(dāng)前cpu core數(shù)，如果大于說明cpu load已經(jīng)嚴(yán)重過高。就要去查看是不是線程數(shù)設(shè)置的過高，還要考慮這些任務(wù)是不是處理時(shí)間太長(zhǎng)。設(shè)置的線程數(shù)與任務(wù)所處理的時(shí)長(zhǎng)有直接關(guān)系。

Tasks域表示任務(wù)數(shù)情況，total總的任務(wù)數(shù)，running運(yùn)行中的任務(wù)數(shù)，sleeping休眠中的任務(wù)數(shù)，stopped暫停中的任務(wù)數(shù)，zombie僵尸狀態(tài)任務(wù)數(shù)。

Swap域表示系統(tǒng)的交換區(qū)，壓測(cè)的時(shí)候關(guān)注used是否會(huì)持續(xù)升高，如果持續(xù)升高說明物理內(nèi)存已經(jīng)用完開始進(jìn)行內(nèi)存頁(yè)的交換。

free

查看當(dāng)前系統(tǒng)的內(nèi)存使用情況

free -m

total總內(nèi)存大小，used已經(jīng)分配的內(nèi)存大小，free當(dāng)前可用的內(nèi)存大小，shared任務(wù)之間的共享內(nèi)存大小，buffers系統(tǒng)已經(jīng)分配但是還未使用的，用來存放文件matedata元數(shù)據(jù)內(nèi)存大小，cached系統(tǒng)已經(jīng)分配但是還未使用的，用來存放文件的內(nèi)容數(shù)據(jù)的內(nèi)存大小。

-/+buffer/cache

used要減去buffers/cached，也就是說并沒有用掉這么多內(nèi)存，而是有一部分內(nèi)存用在了buffers/cached里。

free要加上buffers/cached，也就是說還有buffers/cached空余內(nèi)存需要加上。

Swap交換區(qū)統(tǒng)計(jì)，total交換區(qū)總大小，used已經(jīng)使用的交換區(qū)大小，free交換區(qū)可用大小。只需要關(guān)注used已經(jīng)使用的交換區(qū)大小，如果這里有占用說明內(nèi)存已經(jīng)到瓶頸。

《深入理解LINUX內(nèi)核》、《LINUX內(nèi)核設(shè)計(jì)與實(shí)現(xiàn)》可以放在手邊作為參考手冊(cè)遇到問題翻翻。

性能排查兩種方式（從上往下、從下往上）

當(dāng)系統(tǒng)出現(xiàn)性能問題的時(shí)候可以從兩個(gè)層面來排查問題，從上往下、從下網(wǎng)上，也可以綜合運(yùn)用這兩種方法，壓測(cè)的時(shí)候可以同時(shí)查看這兩個(gè)緯度的信息。

一邊打開top、free觀察cpu、memory的系統(tǒng)級(jí)別的消耗情況，同時(shí)一邊在通過jstack、jstat之類的工具查看應(yīng)用程序運(yùn)行時(shí)的內(nèi)部狀態(tài)來綜合定位。

總結(jié)

本篇文章主要還是從拋磚引玉的角度出發(fā)，整理下我們?cè)谧鲆话阈阅軌簻y(cè)的時(shí)候出現(xiàn)的常規(guī)問題及排查方法和處理流程，并沒有多么高深的技術(shù)點(diǎn)。

性能問題一旦出現(xiàn)也不會(huì)是個(gè)簡(jiǎn)單的問題，都需要花費(fèi)很多精力來排查問題，運(yùn)用各種工具、命令來逐步排查，而這些工具和命令所輸出的信息都是系統(tǒng)底層原理，需要逐一去理解和實(shí)驗(yàn)的，并沒有一個(gè)銀彈能解決所有問題。

名稱欄目：后端服務(wù)性能壓測(cè)實(shí)踐-創(chuàng)新互聯(lián)
文章分享：http://bm7419.com/article22/hedjc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站維護(hù)、網(wǎng)站導(dǎo)航、網(wǎng)站策劃、網(wǎng)站內(nèi)鏈、微信公眾號(hào)、用戶體驗(yàn)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)