9.3 安装
9.4 CPU级别火焰图cpu占用过高，或者使用率提不上来，你能快速定位到代码的哪块有问题吗？
一般的做法可能就是通过日志等方式去确定问题。现在我们有了火焰图，能够非常清晰的发现哪个函数占用cpu过高，或者过低导致的问题。
9.4.1 on-CPU
cpu占用过高，执行中的时间通常又分为用户态时间user和系统态时间sys。
使用方式：
DEMO：
DEMO火焰图：
9.4.2 off-CPUcpu过低，利用率不高。等待下一轮CPU，或者等待I/O、锁、换页等等，其状态可以细分为可执行、匿名换页、睡眠、锁、空闲等状态。
使用方式：
官网DEMO：
9.5 内存级别火焰图如果线上程序出现了内存泄漏，并且只在特定的场景才会出现。这个时候我们怎么办呢？有什么好的方式和工具能快速的发现代码的问题呢？同样内存级别火焰图帮你快速分析问题的根源。
使用方式：
官网DEMO：
9.6 性能回退-红蓝差分火焰图
你能快速定位CPU性能回退的问题么？如果你的工作环境非常复杂且变化快速，那么使用现有的工具是来定位这类问题是很具有挑战性的。当你花掉数周时间把根因找到时，代码已经又变更了好几轮，新的性能问题又冒了出来。主要可以用到每次构建中，每次上线做对比看，如果损失严重可以立马解决修复。
通过抓取了两张普通的火焰图，然后进行对比，并对差异部分进行标色：红色表示上升，蓝色表示下降。差分火焰图是以当前（“修改后”）的profile文件作为基准，形状和大小都保持不变。因此你通过色彩的差异就能够很直观的找到差异部分，且可以看出为什么会有这样的差异。
使用方式：
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();
}
}
DEMO红蓝差分火焰图：
10、案例分析10.1 接入层nginx集群异常现象
通过监控插件发现在2017.09.25 19点nginx集群请求流量出现大量的499，5xx状态码。并且发现机器cpu使用率升高，目前一直持续中。
10.2 分析nginx相关指标a) 分析nginx请求流量：
结论：
通过上图发现流量并没有突增，反而下降了，跟请求流量突增没关系。
结论：
通过上图发现nginx的响应时间有增加可能跟nginx自身有关系或者跟后端upstream响应时间有关系。
c) 分析nginx upstream响应时间
结论：
通过上图发现nginx upstream 响应时间有增加，目前猜测可能后端upstream响应时间拖住nginx，导致nginx出现请求流量异常。
10.3 分析系统cpu情况
a) **通过top观察系统指标
top
结论：
发现nginx worker cpu比较高
b) **分析nginx进程内部cpu情况
perf top -p pid
结论：
发现主要开销在free,malloc,json解析上面
10.4 火焰图分析cpu
a) **生成用户态cpu火焰图
结论：
发现代码里面有频繁的解析json操作，并且发现这个json库性能不高，占用cpu挺高。
10.5 案例总结a) 分析请求流量异常，得出nginx upstream后端机器响应时间拉长
b) 分析nginx进程cpu高，得出nginx内部模块代码有耗时的json解析以及内存分配回收操作
10.5.1 深入分析根据以上两点问题分析的结论，我们进一步深入分析。
后端upstream响应拉长，最多可能影响nginx的处理能力。但是不可能会影响nginx内部模块占用过多的cpu操作。并且当时占用cpu高的模块，是在请求的时候才会走的逻辑。不太可能是upstram后端拖住nginx，从而触发这个cpu的耗时操作。
10.5.2 解决方式遇到这种问题，我们优先解决已知的，并且非常明确的问题。那就是cpu高的问题。解决方式先降级关闭占用cpu过高的模块，然后进行观察。经过降级关闭该模块cpu降下来了，并且nginx请求流量也正常了。之所以会影响upstream时间拉长，因为upstream后端的服务调用的接口可能是个环路再次走回到nginx。
原文：https://www.jianshu.com/p/0bbac570fa4c
文章来源于网络，版权归原作者所有，如有侵权，请联系删除。
楼主
标题置顶
标题高亮
