网站系统建设开票要开什么,网站后台实际访问地址与注册的域名地址不同,自己做网站广告,公司名字大全20000个免费FlameScope是一个新的开源性能可视化工具#xff0c;它使用次秒级偏移热图和火焰图来分析周期活动、方差、扰动。我们在Netflix TechBlog上面#xff0c;发表了技术文章Netflix FlameScope#xff0c;以及工具的源代码。火焰图很好理解#xff0c;次秒级偏移热图理解起来要…FlameScope是一个新的开源性能可视化工具它使用次秒级偏移热图和火焰图来分析周期活动、方差、扰动。我们在Netflix TechBlog上面发表了技术文章Netflix FlameScope以及工具的源代码。火焰图很好理解次秒级偏移热图理解起来要困难些我最近发明的它。FlameScope可以该帮助你理解后者。
总而言之次秒级偏移热图是这样的x轴是一整秒y轴是这一秒里的几分之一秒。这每个几分之一秒都被称作一个桶或者说盒表示这几分之一秒里事件数量的聚合。盒子颜色深度表示发生的次数颜色越深表示次数越多。
下图一个真实的CPU上的次秒级偏移热图样本: 这张图中能分析出什么信息来呢为了能把各种不同模式区分开来展示我在这篇文章里先画了一些人工合成的样本。实际使用FlameScope工具时可以选择你的各个模式还能生成火焰图显示对应的代码路径这里我不展示火焰图。
周期活动
1 . 一个线程每秒一次 线程在每秒钟内的同样的偏移里醒来做几毫秒的工作然后回到睡眠。
2 . 一个线程两次每秒 每500ms唤醒一次。既可能是两个线程也可能是一个线程500ms 唤醒一次。
3 . 两个线程 看起来像两个线程均1s唤醒一次
4 . 一个忙等待线程每秒一次 这个线程做约20ms的工作然后睡1s。这是一个常见的模式导致每秒钟唤醒抵消匍匐前进。
5 . 一个忙等待线程,两次每秒 每500ms唤醒一次。有可能是单线程程序每秒唤醒两次。
6 . 一个计算较密集的忙等线程 斜率高每秒做更多的工作大约是80毫秒。
7 . 一个计算较不密集的忙等线程 斜率低每秒做的工作较少可能只有几毫秒。
8 . 一个忙等待线程每5秒钟唤醒一次 现在5秒唤醒一次。
我们可以根据夹角和唤醒的时间间隔计算每个唤醒的CPU繁忙时间: busy_time (1000 ms / (热图行数 时间长度) tan(夹角) 例如45°夹角的线 busy_time (1000 ms / (501)) tan(45) 20ms
方差
9 . cpu利用率100% 这是CPU完全被用满的样子
10 . cpu利用率50% 真实的工作负载更像是这样是由短请求、随机到达组成的。
11 . cpu利用率25% 相同的工作负载类型大小在25%。
12 . cpu利用率5% 相同的工作负载类型大小在5%。
13 . 负载增加 在2分钟的尺度上负载在变重。
14 . 变化的负荷 每30秒就有5秒的工作负载较重。
扰动
15 . CPU扰动 时不时地所有CPU都满载个100ms。比如垃圾回收
16 . CPU阻塞 时不时地所有CPU都空载个100ms。比如等I/O
17 . 单线程阻塞 时不时地只有一个CPU没有idle表现为粉红色长条而不是白色长条。比如全局锁
最后这个模式很有趣它发生在一个当前运行的线程持有一把锁而其它所有线程都阻塞在这把锁上。 那么该线程在做什么呢点击FlameScope的粉色线就能看到此时的火焰图。复杂的性能问题立刻变简单。
总结
你能从这张图中分析出什么结论
实际使用FlameScope工具时可以选择你的各个模式还能生成火焰图显示对应的代码路径。
我和同事Martin Spier也是该工具的主开发人员11月8日在LinkedIn性能meetup上发表演讲。
祝你使用FlameScope愉快欢迎截图分享你遇到有趣的模式!
Brendan
实践
需要补充的是作者最新的工作将强大的Differential Flame Graph也集成到FlameScope中了现在交互式地在FlameScope上选择两个测试集以及对应的时间段对比两个测试组的事件采样。
我在使用FlameScope时发现并fix了FlameScope的若干bug。也包括Differential Flame Graph跑不起来的一些bug。之后我便用它来进行了一些性能问题的复现。还发现其中一些有趣的模式。
首先我想分析两个测试组的调度特征。我对他们分别进行了perf sched record采样并使用FlameScope进行了数据可视化。
性能好的分组 客户端 服务端性能差的分组 客户端 服务端
我们发现性能差的分组有大量的调度事件而且发生地非常均匀。性能好的分组则是周期性地繁忙工作若干毫秒深红色长条我们还能发现背景里有周期性的轻松任务浅红色长条
这个对比给了我们这两个测试集的调度特征一个直观的感受。但看来分析问题需要借助更多的信息。
于是我使用了Differential Flame Graph分析两个测试集的完整调用栈上的采样。 该图便给出一个重要线索两个测试集最重大的区别在vfs_write-do_sync_write-sock_aio_write-inet_sendmsg-copy_user_enhanced_fast_string这条路径上。注意由于内核编译优化等原因调用路径略有不准确
性能好的测试组多调用了很多次copy_user_enhanced_fast_string性能差测试组的则很少。
之后的工作便于FlameScope关系不大了。这便是我使用FlameScope工具进行测试和性能调优的一个实践。Bredan Gregg大神主导的这个软件对性能数据阐释的直观性真的太强了~
原文链接 本文为云栖社区原创内容未经允许不得转载。
