日本黄色一级经典视频|伊人久久精品视频|亚洲黄色色周成人视频九九九|av免费网址黄色小短片|黄色Av无码亚洲成年人|亚洲1区2区3区无码|真人黄片免费观看|无码一级小说欧美日免费三级|日韩中文字幕91在线看|精品久久久无码中文字幕边打电话

當前位置:首頁 > > 嵌入式微處理器
[導讀]關于Linux超全整理,建議收藏!

目錄:

1、CPU

2、內存

3、磁盤IO

4、網(wǎng)絡

5、系統(tǒng)負載

6、火焰圖

7、案例分析


1、CPU

1.1 說明

針對應用程序,我們通常關注的是內核CPU調度器功能和性能。

線程的狀態(tài)分析主要是分析線程的時間用在什么地方,而線程狀態(tài)的分類一般分為:

a. on-CPU:執(zhí)行中,執(zhí)行中的時間通常又分為用戶態(tài)時間user和系統(tǒng)態(tài)時間sys。
b. off-CPU:等待下一輪上CPU,或者等待I/O、鎖、換頁等等,其狀態(tài)可以細分為可執(zhí)行、匿名換頁、睡眠、鎖、空閑等狀態(tài)。

如果大量時間花在CPU上,對CPU的剖析能夠迅速解釋原因;如果系統(tǒng)時間大量處于off-cpu狀態(tài),定位問題就會費時很多。但是仍然需要清楚一些概念:

  • 處理器

  • 硬件線程

  • CPU內存緩存

  • 時鐘頻率

  • 每指令周期數(shù)CPI和每周期指令數(shù)IPC

  • CPU指令

  • 使用率

  • 用戶時間/內核時間

  • 調度器

  • 運行隊列

  • 搶占

  • 多進程

  • 多線程

  • 字長

1.2 分析工具

說明:

  • uptime,vmstat,mpstat,top,pidstat只能查詢到cpu及負載的的使用情況。

  • perf可以跟著到進程內部具體函數(shù)耗時情況,并且可以指定內核函數(shù)進行統(tǒng)計,指哪打哪。

1.3 使用方式

//查看系統(tǒng)cpu使用情況
top

//查看所有cpu核信息
mpstat?-P?ALL?1

//查看cpu使用情況以及平均負載
vmstat?1

//進程cpu的統(tǒng)計信息
pidstat?-u?1?-p?pid

//跟蹤進程內部函數(shù)級cpu使用情況
perf?top?-p?pid?-e?cpu-clock


2、內存

2.1 說明

內存是為提高效率而生,實際分析問題的時候,內存出現(xiàn)問題可能不只是影響性能,而是影響服務或者引起其他問題。同樣對于內存有些概念需要清楚:

  • 主存

  • 虛擬內存

  • 常駐內存

  • 地址空間

  • OOM

  • 頁緩存

  • 缺頁

  • 換頁

  • 交換空間

  • 交換

  • 用戶分配器libc、glibc、libmalloc和mtmalloc

  • LINUX內核級SLUB分配器

2.2 分析工具

說明:

  • free,vmstat,top,pidstat,pmap只能統(tǒng)計內存信息以及進程的內存使用情況。

  • valgrind可以分析內存泄漏問題。

  • dtrace動態(tài)跟蹤。需要對內核函數(shù)有很深入的了解,通過D語言編寫腳本完成跟蹤。

2.3 使用方式

//查看系統(tǒng)內存使用情況
free?-m

//虛擬內存統(tǒng)計信息
vmstat?1

//查看系統(tǒng)內存情況
top

//1s采集周期,獲取內存的統(tǒng)計信息
pidstat?-p?pid?-r?1

//查看進程的內存映像信息
pmap?-d?pid

//檢測程序內存問題
valgrind?--tool=memcheck?--leak-check=full?--log-file=./log.txt??./程序名


3、磁盤IO

3.1 說明

磁盤通常是計算機最慢的子系統(tǒng),也是最容易出現(xiàn)性能瓶頸的地方,因為磁盤離 CPU 距離最遠而且 CPU 訪問磁盤要涉及到機械操作,比如轉軸、尋軌等。訪問硬盤和訪問內存之間的速度差別是以數(shù)量級來計算的,就像1天和1分鐘的差別一樣。要監(jiān)測 IO 性能,有必要了解一下基本原理和 Linux 是如何處理硬盤和內存之間的 IO 的。

在理解磁盤IO之前,同樣我們需要理解一些概念,例如:

  • 文件系統(tǒng)

  • VFS

  • 文件系統(tǒng)緩存

  • 頁緩存page cache

  • 緩沖區(qū)高速緩存buffer cache

  • 目錄緩存

  • inode

  • inode緩存

  • noop調用策略

3.2 分析工具

3.3 使用方式

//查看系統(tǒng)io信息
iotop

//統(tǒng)計io詳細信息
iostat?-d?-x?-k?1?10

//查看進程級io的信息
pidstat?-d?1?-p??pid

//查看系統(tǒng)IO的請求,比如可以在發(fā)現(xiàn)系統(tǒng)IO異常時,可以使用該命令進行調查,就能指定到底是什么原因導致的IO異常
perf?record?-e?block:block_rq_issue?-ag
^C
perf?report


4、網(wǎng)絡

4.1 說明

網(wǎng)絡的監(jiān)測是所有 Linux 子系統(tǒng)里面最復雜的,有太多的因素在里面,比如:延遲、阻塞、沖突、丟包等,更糟的是與 Linux 主機相連的路由器、交換機、無線信號都會影響到整體網(wǎng)絡并且很難判斷是因為 Linux 網(wǎng)絡子系統(tǒng)的問題還是別的設備的問題,增加了監(jiān)測和判斷的復雜度。現(xiàn)在我們使用的所有網(wǎng)卡都稱為自適應網(wǎng)卡,意思是說能根據(jù)網(wǎng)絡上的不同網(wǎng)絡設備導致的不同網(wǎng)絡速度和工作模式進行自動調整。

4.2 分析工具

4.3 使用方式

//顯示網(wǎng)絡統(tǒng)計信息
netstat?-s

//顯示當前UDP連接狀況
netstat?-nu

//顯示UDP端口號的使用情況
netstat?-apu

//統(tǒng)計機器中網(wǎng)絡連接各個狀態(tài)個數(shù)
netstat?-a?|?awk?\\'/^tcp/?{++S[$NF]}?END?{for(a?in?S)?print?a,?S[a]}\\'

//顯示TCP連接
ss?-t?-a

//顯示sockets摘要信息
ss?-s

//顯示所有udp?sockets
ss?-u?-a

//tcp,etcp狀態(tài)
sar?-n?TCP,ETCP?1

//查看網(wǎng)絡IO
sar?-n?DEV?1

//抓包以包為單位進行輸出
tcpdump?-i?eth1?host?192.168.1.1?and?port?80?

//抓包以流為單位顯示數(shù)據(jù)內容
tcpflow?-cp?host?192.168.1.1


5、系統(tǒng)負載

5.1 說明

Load 就是對計算機干活多少的度量(WikiPedia:the system Load is a measure of the amount of work that a compute system is doing)簡單的說是進程隊列的長度。Load Average 就是一段時間(1分鐘、5分鐘、15分鐘)內平均Load。

5.2 分析工具

5.3 使用方式

//查看負載情況
uptime

top

vmstat

//統(tǒng)計系統(tǒng)調用耗時情況
strace?-c?-p?pid

//跟蹤指定的系統(tǒng)操作例如epoll_wait
strace?-T?-e?epoll_wait?-p?pid

//查看內核日志信息
dmesg


6、火焰圖

6.1 說明

火焰圖(Flame Graph是 Bredan Gregg 創(chuàng)建的一種性能分析圖表,因為它的樣子近似 ?而得名。

火焰圖主要是用來展示 CPU的調用棧。

y 軸表示調用棧,每一層都是一個函數(shù)。調用棧越深,火焰就越高,頂部就是正在執(zhí)行的函數(shù),下方都是它的父函數(shù)。

x 軸表示抽樣數(shù),如果一個函數(shù)在 x 軸占據(jù)的寬度越寬,就表示它被抽到的次數(shù)多,即執(zhí)行的時間長。注意,x 軸不代表時間,而是所有的調用棧合并后,按字母順序排列的。

火焰圖就是看頂層的哪個函數(shù)占據(jù)的寬度最大。只要有”平頂”(plateaus),就表示該函數(shù)可能存在性能問題。顏色沒有特殊含義,因為火焰圖表示的是 CPU 的繁忙程度,所以一般選擇暖色調。

常見的火焰圖類型有On-CPU、Off-CPU、Memory、Hot/Cold、Differential等等。

6.2 安裝依賴庫

//安裝systemtap,默認系統(tǒng)已安裝
yum?install?systemtap?systemtap-runtime

//內核調試庫必須跟內核版本對應,例如:uname -r 2.6.18-308.el5
kernel-debuginfo-2.6.18-308.el5.x86_64.rpm
kernel-devel-2.6.18-308.el5.x86_64.rpm
kernel-debuginfo-common-2.6.18-308.el5.x86_64.rpm

//安裝內核調試庫
debuginfo-install?--enablerepo=debuginfo?search?kernel
debuginfo-install?--enablerepo=debuginfo??search?glibc

6.3 安裝

git?clone?https://github.com/lidaohang/quick_location.git
cd?quick_location

6.4 CPU級別火焰圖

cpu占用過高,或者使用率提不上來,你能快速定位到代碼的哪塊有問題嗎?
一般的做法可能就是通過日志等方式去確定問題?,F(xiàn)在我們有了火焰圖,能夠非常清晰的發(fā)現(xiàn)哪個函數(shù)占用cpu過高,或者過低導致的問題。

6.4.1 on-CPU


cpu占用過高,執(zhí)行中的時間通常又分為用戶態(tài)時間user和系統(tǒng)態(tài)時間sys。

使用方式:

//on-CPU?user
sh?ngx_on_cpu_u.sh?pid

//進入結果目錄
cd?ngx_on_cpu_u

//on-CPU?kernel
sh?ngx_on_cpu_k.sh?pid

//進入結果目錄
cd?ngx_on_cpu_k

//開一個臨時端口8088
python?-m?SimpleHTTPServer?8088

//打開瀏覽器輸入地址
127.0.0.1:8088/pid.svg


DEMO:


#include?
#include?

void?foo3()
{
}

void?foo2()
{
??int?i;
??for(i=0?;?i?10;?i++)
???????foo3();
}

void?foo1()
{
??int?i;
??for(i?=?0;?i1000;?i++)
?????foo3();
}

int?main(void)
{
??int?i;
??for(?i?=0;?i1000000000;?i++)?{
??????foo1();
??????foo2();
??}
}


DEMO火焰圖:


6.4.2 off-CPU

cpu過低,利用率不高。等待下一輪CPU,或者等待I/O、鎖、換頁等等,其狀態(tài)可以細分為可執(zhí)行、匿名換頁、睡眠、鎖、空閑等狀態(tài)。

使用方式:

//?off-CPU?user
sh?ngx_off_cpu_u.sh?pid

//進入結果目錄
cd?ngx_off_cpu_u

//off-CPU?kernel
sh?ngx_off_cpu_k.sh?pid

//進入結果目錄
cd?ngx_off_cpu_k

//開一個臨時端口8088
python?-m?SimpleHTTPServer?8088

//打開瀏覽器輸入地址
127.0.0.1:8088/pid.svg


官網(wǎng)DEMO:

6.5 內存級別火焰圖

如果線上程序出現(xiàn)了內存泄漏,并且只在特定的場景才會出現(xiàn)。這個時候我們怎么辦呢?有什么好的方式和工具能快速的發(fā)現(xiàn)代碼的問題呢?同樣內存級別火焰圖幫你快速分析問題的根源。

使用方式:

sh?ngx_on_memory.sh?pid

//進入結果目錄
cd?ngx_on_memory

//開一個臨時端口8088
python?-m?SimpleHTTPServer?8088

//打開瀏覽器輸入地址
127.0.0.1:8088/pid.svg


官網(wǎng)DEMO:

6.6 性能回退-紅藍差分火焰圖


你能快速定位CPU性能回退的問題么?如果你的工作環(huán)境非常復雜且變化快速,那么使用現(xiàn)有的工具是來定位這類問題是很具有挑戰(zhàn)性的。當你花掉數(shù)周時間把根因找到時,代碼已經(jīng)又變更了好幾輪,新的性能問題又冒了出來。主要可以用到每次構建中,每次上線做對比看,如果損失嚴重可以立馬解決修復。


通過抓取了兩張普通的火焰圖,然后進行對比,并對差異部分進行標色:紅色表示上升,藍色表示下降。差分火焰圖是以當前(“修改后”)的profile文件作為基準,形狀和大小都保持不變。因此你通過色彩的差異就能夠很直觀的找到差異部分,且可以看出為什么會有這樣的差異。


使用方式:


cd?quick_location

//抓取代碼修改前的profile?1文件
perf?record?-F?99?-p?pid?-g?--?sleep?30
perf?script?>?out.stacks1

//抓取代碼修改后的profile?2文件
perf?record?-F?99?-p?pid?-g?--?sleep?30
perf?script?>?out.stacks2

//生成差分火焰圖:
./FlameGraph/stackcollapse-perf.pl?../out.stacks1?>?out.folded1
./FlameGraph/stackcollapse-perf.pl?../out.stacks2?>?out.folded2
./FlameGraph/difffolded.pl?out.folded1?out.folded2?|?./FlameGraph/flamegraph.pl?>?diff2.svg


DEMO:

//test.c
#include?
#include?

void?foo3()
{
}

void?foo2()
{
??int?i;
??for(i=0?;?i?10;?i++)
???????foo3();
}

void?foo1()
{
??int?i;
??for(i?=?0;?i1000;?i++)
?????foo3();
}

int?main(void)
{
??int?i;
??for(?i?=0;?i1000000000;?i++)?{
??????foo1();
??????foo2();
??}
}

//test1.c
#include?
#include?

void?foo3()
{
}

void?foo2()
{
??int?i;
??for(i=0?;?i?10;?i++)
???????foo3();
}

void?foo1()
{
??int?i;
??for(i?=?0;?i1000;?i++)
?????foo3();
}

void?add()
{
??int?i;
??for(i?=?0;?i10000;?i++)
?????foo3();
}

int?main(void)
{
??int?i;
??for(?i?=0;?i1000000000;?i++)?{
??????foo1();
??????foo2();
??????add();
??}
}


DEMO紅藍差分火焰圖:

7、案例分析

7.1 接入層nginx集群異?,F(xiàn)象

通過監(jiān)控插件發(fā)現(xiàn)在2017.09.25 19點nginx集群請求流量出現(xiàn)大量的499,5xx狀態(tài)碼。并且發(fā)現(xiàn)機器cpu使用率升高,目前一直持續(xù)中。

7.2 分析nginx相關指標

a)?分析nginx請求流量:

結論:

通過上圖發(fā)現(xiàn)流量并沒有突增,反而下降了,跟請求流量突增沒關系。

b)?分析nginx響應時間

結論:

通過上圖發(fā)現(xiàn)nginx的響應時間有增加可能跟nginx自身有關系或者跟后端upstream響應時間有關系。

c)?分析nginx upstream響應時間

結論:

通過上圖發(fā)現(xiàn)nginx upstream 響應時間有增加,目前猜測可能后端upstream響應時間拖住nginx,導致nginx出現(xiàn)請求流量異常。

7.3 分析系統(tǒng)cpu情況


a)?通過top觀察系統(tǒng)指標

top

結論:

發(fā)現(xiàn)nginx worker cpu比較高

b)?分析nginx進程內部cpu情況

perf top -p pid

結論:

發(fā)現(xiàn)主要開銷在free,malloc,json解析上面

7.4 火焰圖分析cpu

a)?生成用戶態(tài)cpu火焰圖

//test.c
#include?
#include?
//on-CPU?user
sh?ngx_on_cpu_u.sh?pid

//進入結果目錄
cd?ngx_on_cpu_u

//開一個臨時端口8088
python?-m?SimpleHTTPServer?8088

//打開瀏覽器輸入地址
127.0.0.1:8088/pid.svg


結論:


發(fā)現(xiàn)代碼里面有頻繁的解析json操作,并且發(fā)現(xiàn)這個json庫性能不高,占用cpu挺高。

7.5 案例總結

a)?分析請求流量異常,得出nginx upstream后端機器響應時間拉長

b)?分析nginx進程cpu高,得出nginx內部模塊代碼有耗時的json解析以及內存分配回收操作

7.5.1 深入分析

根據(jù)以上兩點問題分析的結論,我們進一步深入分析。

后端upstream響應拉長,最多可能影響nginx的處理能力。但是不可能會影響nginx內部模塊占用過多的cpu操作。并且當時占用cpu高的模塊,是在請求的時候才會走的邏輯。不太可能是upstram后端拖住nginx,從而觸發(fā)這個cpu的耗時操作。

7.5.2 解決方式

遇到這種問題,我們優(yōu)先解決已知的,并且非常明確的問題。那就是cpu高的問題。解決方式先降級關閉占用cpu過高的模塊,然后進行觀察。經(jīng)過降級關閉該模塊cpu降下來了,并且nginx請求流量也正常了。之所以會影響upstream時間拉長,因為upstream后端的服務調用的接口可能是個環(huán)路再次走回到nginx。
END

來源:網(wǎng)絡

版權歸原作者所有,如有侵權,請聯(lián)系刪除。

推薦閱讀

飛機上一般是什么操作系統(tǒng)?

高速CAN、容錯CAN、LIN總線有什么區(qū)別?

大佬終于把鴻蒙OS講明白了,收藏了!

免責聲明:本文內容由21ic獲得授權后發(fā)布,版權歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!

嵌入式ARM

掃描二維碼,關注更多精彩內容

本站聲明: 本文章由作者或相關機構授權發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點,本站亦不保證或承諾內容真實性等。需要轉載請聯(lián)系該專欄作者,如若文章內容侵犯您的權益,請及時聯(lián)系本站刪除( 郵箱:macysun@21ic.com )。
換一批
延伸閱讀
關閉