- cache halaman buffer cache buffer cache
6.3 使用方式
//查看系统io信息iotop//统计io详细信息iostat -d -x -k 1 10//查看进程级io的信息pidstat -d 1 -p pid//查看系统IO的请求，比如可以在发现系统IO异常时，可以使用该命令进行调查，就能指定到底是什么原因导致的IO异常perf record -e block:block_rq_issue -ag^Cperf report
Salin selepas log masuk
7. 网络
7.1 说明
网络的监测是所有 Linux 子系统里面最复杂的，有太多的因素在里面，比如：延迟、阻塞、冲突、丢包等，更糟的是与 Linux 主机相连的路由器、交换机、无线信号都会影响到整体网络并且很难判断是因为 Linux 网络子系统的问题还是别的设备的问题，增加了监测和判断的复杂度。现在我们使用的所有网卡都称为自适应网卡，意思是说能根据网络上的不同网络设备导致的不同网络速度和工作模式进行自动调整。7.2 分析工具
7.3 使用方式
//显示网络统计信息netstat -s//显示当前UDP连接状况netstat -nu//显示UDP端口号的使用情况netstat -apu//统计机器中网络连接各个状态个数netstat -a | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'//显示TCP连接ss -t -a//显示sockets摘要信息ss -s//显示所有udp socketsss -u -a//tcp,etcp状态sar -n TCP,ETCP 1//查看网络IOsar -n DEV 1//抓包以包为单位进行输出tcpdump -i eth1 host 192.168.1.1 and port 80 //抓包以流为单位显示数据内容tcpflow -cp host 192.168.1.1Salin selepas log masuk
8. 系统负载
8.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。8.2 分析工具
8.3 使用方式
//查看负载情况uptimetopvmstat//统计系统调用耗时情况strace -c -p pid//跟踪指定的系统操作例如epoll_waitstrace -T -e epoll_wait -p pid//查看内核日志信息dmesg
Salin selepas log masuk
9. 火焰图
9.1 说明
火焰图（Flame Graph是 Bredan Gregg 创建的一种性能分析图表，因为它的样子近似 ?而得名。y 轴表示调用栈，每一层都是一个函数。调用栈越深，火焰就越高，顶部就是正在执行的函数，下方都是它的父函数。x 轴表示抽样数，如果一个函数在 x 轴占据的宽度越宽，就表示它被抽到的次数多，即执行的时间长。注意，x 轴不代表时间，而是所有的调用栈合并后，按字母顺序排列的。火焰图就是看顶层的哪个函数占据的宽度最大。只要有”平顶”（plateaus），就表示该函数可能存在性能问题。颜色没有特殊含义，因为火焰图表示的是 CPU 的繁忙程度，所以一般选择暖色调。常见的火焰图类型有 On-CPU、Off-CPU、Memory、Hot/Cold、Differential等等。
9.2 安装依赖库
//安装systemtap，默认系统已安装yum install systemtap systemtap-runtime//内核调试库必须跟内核版本对应，例如：uname -r 2.6.18-308.el5kernel-debuginfo-2.6.18-308.el5.x86_64.rpmkernel-devel-2.6.18-308.el5.x86_64.rpmkernel-debuginfo-common-2.6.18-308.el5.x86_64.rpm//安装内核调试库debuginfo-install --enablerepo=debuginfo search kerneldebuginfo-install --enablerepo=debuginfo search glibc
Salin selepas log masuk
9.3 安装
git clone https://github.com/lidaohang/quick_location.gitcd quick_location
Salin selepas log masuk
9.4 CPU级别火焰图
cpu占用过高，或者使用率提不上来，你能快速定位到代码的哪块有问题吗？
一般的做法可能就是通过日志等方式去确定问题。现在我们有了火焰图，能够非常清晰的发现哪个函数占用cpu过高，或者过低导致的问题。另外，搜索公众号Linux就该这样学后台回复“猴子”，获取一份惊喜礼包。
9.4.1 on-CPU
cpu占用过高，执行中的时间通常又分为用户态时间user和系统态时间sys。//on-CPU usersh ngx_on_cpu_u.sh pid//进入结果目录 cd ngx_on_cpu_u//on-CPU kernelsh ngx_on_cpu_k.sh pid//进入结果目录 cd ngx_on_cpu_k//开一个临时端口 8088 python -m SimpleHTTPServer 8088//打开浏览器输入地址127.0.0.1:8088/pid.svg
Salin selepas log masuk
DEMO：
Salin selepas log masuk
#include <stdio.h>#include <stdlib.h>
void foo3(){ }
void foo2(){ int i; for(i=0 ; i < 10; i++) foo3();}
void foo1(){ int i; for(i = 0; i< 1000; i++) foo3();}
int main(void){ int i; for( i =0; i< 1000000000; i++) { foo1(); foo2(); }}Salin selepas log masuk
DEMO火焰图：
9.4.2 off-CPU
cpu过低，利用率不高。等待下一轮CPU，或者等待I/O、锁、换页等等，其状态可以细分为可执行、匿名换页、睡眠、锁、空闲等状态。
使用方式：
// off-CPU usersh ngx_off_cpu_u.sh pid//进入结果目录cd ngx_off_cpu_u//off-CPU kernelsh ngx_off_cpu_k.sh pid//进入结果目录cd ngx_off_cpu_k//开一个临时端口8088python -m SimpleHTTPServer 8088//打开浏览器输入地址127.0.0.1:8088/pid.svg
Salin selepas log masuk
官网DEMO：
9.5 内存级别火焰图
如果线上程序出现了内存泄漏，并且只在特定的场景才会出现。这个时候我们怎么办呢？有什么好的方式和工具能快速的发现代码的问题呢？同样内存级别火焰图帮你快速分析问题的根源。
使用方式：
sh ngx_on_memory.sh pid//进入结果目录cd ngx_on_memory//开一个临时端口8088python -m SimpleHTTPServer 8088//打开浏览器输入地址127.0.0.1:8088/pid.svg
Salin selepas log masuk
官网DEMO：
9.6 性能回退-红蓝差分火焰图
你能快速定位CPU性能回退的问题么？如果你的工作环境非常复杂且变化快速，那么使用现有的工具是来定位这类问题是很具有挑战性的。当你花掉数周时间把根因找到时，代码已经又变更了好几轮，新的性能问题又冒了出来。主要可以用到每次构建中，每次上线做对比看，如果损失严重可以立马解决修复。
通过抓取了两张普通的火焰图，然后进行对比，并对差异部分进行标色：红色表示上升，蓝色表示下降。差分火焰图是以当前（“修改后”）的profile文件作为基准，形状和大小都保持不变。因此你通过色彩的差异就能够很直观的找到差异部分，且可以看出为什么会有这样的差异。
使用方式：
cd quick_location//抓取代码修改前的profile 1文件perf record -F 99 -p pid -g -- sleep 30perf script > out.stacks1//抓取代码修改后的profile 2文件perf record -F 99 -p pid -g -- sleep 30perf 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
Salin selepas log masuk
DEMO：
//test.c#include <stdio.h>#include <stdlib.h>
void foo3(){ }
void foo2(){ int i; for(i=0 ; i < 10; i++) foo3();}
void foo1(){ int i; for(i = 0; i< 1000; i++) foo3();}
int main(void){ int i; for( i =0; i< 1000000000; i++) { foo1(); foo2(); }}
//test1.c#include <stdio.h>#include <stdlib.h>
void foo3(){
}
void foo2(){ int i; for(i=0 ; i < 10; i++) foo3();}
void foo1(){ int i; for(i = 0; i< 1000; i++) foo3();}
void add(){ int i; for(i = 0; i< 10000; i++) foo3();}
int main(void){ int i; for( i =0; i< 1000000000; i++) { foo1(); foo2(); add(); }}Salin selepas log masuk
DEMO红蓝差分火焰图：
10. Analisis Kes
10.1 Anomali dalam kelompok nginx pada lapisan akses
Ia ditemui melalui pemalam pemantauan bahawa pada pukul 19 pada 25 September 2017, sejumlah besar kod status 499 dan 5xx muncul dalam trafik permintaan kluster nginx. Dan didapati bahawa penggunaan CPU mesin telah meningkat, dan ia berterusan. Di samping itu, cari latar belakang algoritma teratas akaun rasmi dan balas "algoritma" untuk mendapatkan pakej hadiah kejutan. 10.2 Menganalisis petunjuk berkaitan nginx
a) **Analisis trafik permintaan nginx:
Kesimpulan: tidak didapati melalui angka tersebut meningkat secara mendadak , tetapi digugurkan, ikuti Tidak mengapa jika terdapat peningkatan mendadak dalam trafik permintaan.
b) **Analisis masa tindak balas nginx
Kesimpulan:
Ia boleh didapati dari rajah di atas bahawa peningkatan masa tindak balas nginx itu sendiri atau berkaitan dengan backend nginx masa tindak balas huluan.
c) ** Analysis of Nginx Hulu Time
conclusion:
it ditemui dari angka di atas bahawa masa tindak balas hulu nginx telah meningkat. masa tindak balas huluan belakang mungkin menahan nginx, menyebabkan nginx mengalami trafik permintaan yang tidak normal.
10.3 Menganalisis situasi CPU sistem
a) **Perhatikan penunjuk sistem melalui atas
atastop
结论：
发现nginx worker cpu比较高
b) **分析nginx进程内部cpu情况
perf top -p pid
🎜🎜🎜Kesimpulan:🎜🎜🎜🎜 kerja yang agak tinggi🎜🎜🎜 mendapati bahawa cpu lebih tinggi b) 🎜**🎜Analisis situasi CPU dalaman proses nginx🎜🎜🎜perf top -p pid🎜结论：
发现主要开销在free,malloc,json解析上面
10.4 火焰图分析cpu
a) **生成用户态cpu火焰图
//on-CPU usersh ngx_on_cpu_u.sh pid//进入结果目录cd ngx_on_cpu_u//开一个临时端口8088python -m SimpleHTTPServer 8088//打开浏览器输入地址127.0.0.1:8088/pid.svg
Salin selepas log masuk
结论：
发现代码里面有频繁的解析json操作，并且发现这个json库性能不高，占用cpu挺高。
10.5 案例总结
a) 分析请求流量异常，得出nginx upstream后端机器响应时间拉长
b) Menganalisis cpu tinggi proses nginx, disimpulkan bahawa kod modul dalaman nginx mempunyai penghuraian json yang memakan masa dan operasi peruntukan memori dan kitar semula
10.5.1 Analisis mendalam
Kesimpulan berdasarkan analisis dua perkara di atas, kami menganalisis lebih lanjut.
Tindak balas hulu bahagian belakang diregangkan, yang mungkin menjejaskan keupayaan pemprosesan nginx paling banyak. Tetapi ia tidak mungkin menjejaskan modul dalaman nginx yang menggunakan terlalu banyak operasi CPU. Dan modul yang menduduki banyak CPU pada masa itu mempunyai logik yang hanya akan dilaksanakan apabila diminta. Tidak mungkin bahagian belakang upstram menahan nginx, dengan itu mencetuskan operasi CPU yang memakan masa ini.
10.5.2 Penyelesaian
Apabila menghadapi masalah seperti ini, kami akan memberi keutamaan kepada menyelesaikan masalah yang diketahui dan sangat jelas. Itulah masalah CPU tinggi. Penyelesaiannya adalah untuk menurunkan dan menutup modul yang menggunakan terlalu banyak CPU, dan kemudian perhatikan. Selepas menurunkan dan menutup modul, CPU jatuh, dan trafik permintaan nginx menjadi normal. Sebab mengapa masa hulu dipanjangkan adalah kerana antara muka yang dipanggil oleh perkhidmatan hujung belakang hulu mungkin gelung dan kembali ke nginx semula.
11.参考资料
http://www.brendangregg.com/index.html
http://www.brendangregg.com/FlameGraphs
http://www.brendangregg.com/FlameGraphs/memoryflamegraphs.html
http://www.brendangregg.com/FlameGraphs/offcpuflamegraphs.html
com/blog/2014-11-09/differential-flame-graphs.html
https://github.com/openresty/openresty-systemtap-toolkit
com/brendangregg/FlameGraph
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
