共计 3396 个字符，预计需要花费 9 分钟才能阅读完成。
01
终于等来了估算，这就把服务迁徙到最新的 CPU 平台下来，这样前端的共事立马就能感触咱们带来的速度晋升了。可是…… 这些性能指标怎么回事？不仅没有全面晋升，有些反而降落了。不应该这样啊，这可怎么办？
破费了几个月工夫终于搞定了业务模块的重构，立即部署降级让业务面目一新。可是……长尾提早竟然还减少了一倍，说好的业务成果晋升呢，到底是哪里出了问题？
下面的这些问题，对于开发运维工程师来说肯定不生疏，常常被这类出其不意的情况打个措手不及。然而，性能优化是一项高技术门槛的工作，这通常须要运维人员有丰盛的零碎常识和教训，对业务重复进行剖析、定位、测试、验证。遇到麻烦的 case，有时候可能须要破费数周工夫。如果团队中不足这类运维人员，那就只能盯着性能指标降落却没有无效的办法，最初影响了业务上线成果。
在将业务迁徙至不同计算平台，或者进行新业务上线的过程中，为了可能齐全施展计算平台的能力，及时找出性能瓶颈，对系统进行全面优化，百度智能云推出了「应用程序性能诊断工具 Btune」。
就像电脑管家能够疾速对 PC 进行性能优化，Btune 可能对云上业务进行一键性能调优，短时间内实现性能瓶颈的定位并提供优化倡议，使得高级运维人员能够胜任高技术门槛的性能调优工作。
源自百度智能云多年在各种服务器 CPU（Intel、AMD、ARM）和多类业务（举荐、搜寻、广告、大数据、数据库、视频编解码等）上的性能调优教训，Btune 反对多维度利用性能剖析，能够主动生成优化倡议进步利用性能，并提供可视化剖析数据展现。
02
Btune 内置了百度自研的瓶颈分析树模块，通过自顶向下的形式，从 CPU、内存、磁盘、网络、并发等 5 个维度对业务利用进行性能分析和瓶颈定位，并从利用、runtime、零碎、硬件等多个档次对每个瓶颈给出可操作的优化倡议。
借助 Btune 的业余能力，用户不仅能晓得性能问题的根因，还能取得问题优化的办法。只需在 Btune 的前端界面进行一键操作，几分钟后就能够失去一份残缺的性能瓶颈和优化倡议报告。
在 Btune 提供的性能瓶颈和优化倡议报告中蕴含两局部：剖析摘要和剖析详情。其中，「剖析摘要」清晰地展现了业务性能瓶颈点和相应的优化倡议，能够满足绝大部分的场景的需要。「剖析详情」提供了更具体的性能剖析数据，从系统配置、零碎性能、过程线程模型、函数指令热点等多个维度出现负载的资源散布、耗时散布、线程关系等运行个性，满足用户更细粒度性能优化。
03
接下来，咱们通过一个测试用例介绍如何应用「应用程序性能诊断工具 Btune」。（此测试用例仅用于展现 Btune 基本功能和应用办法，理论生产环境业务负载比较复杂，但 Btune 应用办法和剖析原理雷同。）
在这个例子中，首先咱们编写一个测试程序作为剖析对象。在这个程序中次要是调用 glibc 库的 memset 和 memcpy 函数对内存进行操作。而后通过 numactl 命令模拟程序跨 NUMA 拜访内存的状况。咱们通过 Btune 对这个程序进行剖析给出性能瓶颈和优化倡议。在 Btune 输入的报告中，给出了两类倡议：
- 在计算方面，给出了内存操作热点函数和对应的热点库降级倡议。
- 在内存方面，给出了跨 NUMA 访存优化倡议。
最初咱们依据 Btune 给出的倡议对程序进行优化，能够看到优化后程序性能进步了 36.8%，优化效果显著。
测试程序代码如下，程序会有限循环执行简略的内存拷贝操作，可通过编译命令：gcc -o test test.c 和启动命令：nohup numactl -N 0 -m 1 ./test & 来运行此程序。
#include "stdio.h"
#include "stdlib.h"
#include "string.h"
#define ARRAY_SIZE 1000000000
void main()
{
int i=0;
int *a = malloc(sizeof(int)*ARRAY_SIZE);
int *b = malloc(sizeof(int)*ARRAY_SIZE);
while(1)
{memset(a, 0, sizeof(int)*ARRAY_SIZE);
memset(b, 0, sizeof(int)*ARRAY_SIZE);
memcpy(b, a, sizeof(int)*ARRAY_SIZE);
};
}具体操作步骤如下：
1. 登录云服务器控制台
创立一个云服务器实例，登陆实例并拷贝、启动测试程序 test。而后在百度智能云控制台侧边栏抉择云服务器并抉择「运维与监控」上面的「自助诊断工具」进入性能剖析界面。
2. 启动性能检测
在自助诊断工具页面抉择「性能检测」选项，而后抉择方才创立的云服务器实例作为诊断实例，以及抉择 test 过程作为诊断过程，Btune 须要肯定周期的采集工夫剖析该停顿。参数配置完可开始检测。
3. 查看剖析摘要报告
几分钟后，诊断结束。Btune 输入剖析摘要报告：
（1）待优化项
列出了程序的几个瓶颈点，并给出了优化倡议。在此例中，有 3 条优化倡议：前 2 条给出了热点函数 memset 和 memcpy 的热点占比，并举荐降级 glibc2.33 进行优化（以后 CentOS 7.9 默认 glibc 是 2.17，版本较低，性能差）。第 3 条给出了以后程序跨 NUMA 内存使用率是 100%，倡议缩小跨 NUMA 拜访。
（2）诊断详情
诊断详情可查看 CPU、内存、网络、磁盘、并发等 5 个维度的监控数据。咱们以 CPU、内存和并发 3 个诊断项阐明如下：
- CPU 诊断项：内核的网络、存储和调度失常，次要危险是 glibc 热点函数和库版本。
- 内存诊断项：无内存透露，采纳匿名大页，整机内存使用量较少，次要危险是跨 NUMA 应用内存。
- 并发诊断项（mpi）：线程数是 1，因为内存默认对齐所以没有呈现 split lock 状况，线程上下文切换和线程等待时间均失常，无风险。
4. 查看剖析详情报告
点击检测报告右下角的「查看具体报告」，能够查看具体的性能性能剖析数据。
具体报告界面分为三局部：概要、过程和零碎。「概要」从程序运行工夫维度给出了初步剖析；「过程」给出了过程粒度的剖析数据（CPU、内存、磁盘、网络、热点、多线程并发）；「零碎」给出了整机粒度的剖析数据（CPU、内存、磁盘、网络）。
此案例中，通过过程「热点」能够查看热点函数 list，跨路的热点函数 list，火焰图，跨路火焰图等，具体如下：
- 热点函数：此例中次要热点是内存操作函数__memset_sse2 和__memcpy_sse3_back，别离占比 63.09% 和 36.91%。
- 跨 NUMA 热点函数：此例中次要跨路热点函数是__memcpy_sse3_back，占比 100%。
- 火焰图：此例中，glibc 中的__memset_sse2 和__memcpy_sse3_back 占比最大。
- 跨 NUMA 火焰图：此例中，glibc 中的__memcpy_sse3_back 占比最大。
5. 程序优化成果
依据 Btune 给出的优化倡议，咱们须要做两项优化措施：一个是降级 glibc 到 2.33，一个是缩小跨 NUMA 访存。
为了不便比照优化前后性能差别，咱们统计外围代码段的耗时，批改程序如下：
clock_gettime(CLOCK_REALTIME, &start);
memset(a, 0, sizeof(int)*ARRAY_SIZE);
memset(b, 0, sizeof(int)*ARRAY_SIZE);
memcpy(b, a, sizeof(int)*ARRAY_SIZE);
clock_gettime(CLOCK_REALTIME, &end);
elapsed = (end.tv_sec - start.tv_sec) + (end.tv_nsec - start.tv_nsec) / 1e9;
printf("Elapsed time: %f seconds\n", elapsed);首先，优化前的默认程序执行单次耗时 2.576349 秒。
而后，执行 Btune 的倡议优化项其一，敞开跨 NUMA 启动并放弃 2.17 版本 glibc，此时程序耗时 1.821380 秒，优化 29.3%。
最初，执行 Btune 的全副优化倡议，降级到 2.33 版本 glibc，并敞开跨 NUMA 启动，耗时 1.625940 秒，共优化 36.8%。
————END——————
举荐浏览
一文详解动态图和动态图中的主动求导机制
千万级高性能长连贯 Go 服务架构实际
百度搜寻 Push 个性化：新的冲破
数据交付改革：研发到产运自助化的转型之路