Linux性能优化实战学习笔记：第五十八讲

1、上节回顾

专栏更新至今，我们专栏最后一部分——综合案例模块也要告一段落了。很高兴看到你没有掉队，仍然在积极学习思考、实践操做，并热情地分享你在实际环境中，遇到过的各类性能问题的
分析思路以及优化方法。

今天是性能优化答疑的第六期。照例，我从综合案例模块的留言中，摘出了一些典型问题，做为今天的答疑内容，集中回复。为了便于你学习理解，它们并非严格按照文章顺序排列的。每一个
问题，我都附上了留言区提问的截屏。若是你须要回顾内容原文，能够扫描每一个问题右下方的二维码查看。

2、问题 1：容器冷启动性能分析

一、问题

二、解答：

在为何应用容器化后，启动慢了不少中，咱们一块儿分析了容器化所致使的应用程序启动缓慢的问题。简单回顾一下当时的案例，Docker 经过 Cgroups 给容器设置了内存限制，可是容器并未
意识到 ，因此仍是分配了过多内存，致使被系统 OOM 杀死。

这个案例的根源实际上比较简单，Tony 同窗就此提了一个更深刻的问题。

咱们知道，容器为应用程序的管理带来了巨大的便捷，诸如 Serverless（只关注应用的运行，而无需关注服务器）、FaaS（Function as a Service）等新型的软件架构，也都基于容器技术来构
建。不过，虽然容器启动已经很快了，但在启动新容器，也就是冷启动的时候，启动时间相对于应用程序的性能要求来讲，仍是过长了。

那么，应该怎么来分析和优化冷启动的性能呢？

这个问题最核心的一点，其实就是要弄清楚，启动时间到底都花在哪儿了。通常来讲，一个Serverless 服务的启动，包括：

• 事件触发（好比收到新的 HTTP 调用请求）；
• 资源调度；
• 镜像拉取；
• 网络配置
• 启动应用等几个过程。

这几个过程所消耗的时间，均可以经过链路跟踪的方式来监控，进而就能够定位出耗时最多的一个或者多个流程。

紧接着，针对耗时最多的流程，咱们能够经过应用程序监控或者动态追踪的方法，定位出耗时最多的字模块，这样也就找出了要优化的瓶颈点。

好比，镜像拉取流程，能够经过缓存热点镜像来减小镜像拉取时间；网络配置流程，能够经过网络资源预分配进行加速；而资源调度和容器启动，也能够经过复用预先建立好的容器来进行优化。

3、perf probe 失败怎么办？

一、问题

二、解答：

在内核线程 CPU 利用率太高的案例中，咱们一块儿经过 perf 和火焰图工具，生成了内核热点函数调用栈的动态矢量图，并定位出性能问题发生时，执行最为频繁的内核函数。

因为案例分析中，咱们主要关注的是 CPU 的繁忙状况，因此这时候生成的火焰图，被称为 on-CPU 火焰图。事实上，除此以外，还有 off-CPU、内存等不一样的火焰图，分别表示 CPU 的阻塞和
内存的分配释放状况。

因此，李逍遥同窗提了出一个很好的问题：一样都是火焰图，CPU 火焰图和内存火焰图，在生成数据时到底有什么不一样？

这个问题，刚好问到了最核心的点上。CPU 火焰图和内存火焰图，最大的差异其实就是数据来源的不一样，也就是函数堆栈不一样，而火焰图的格式仍是彻底同样的。

• 对 CPU 火焰图来讲，采集的数据主要是消耗 CPU 的函数；
• 而对内存火焰图来讲，采集的数据主要是内存分配、释放、换页等内存管理函数。

举个例子，咱们在使用 perf record 时，默认的采集事件 cpu-cycles ，就是采集 on-CPU 数据，而生成的火焰图就是 CPU 火焰图。经过 perf record -e page-fault 将采集事件换成 page-fault
后，就能够采集内存缺页的数据，生成的火焰图天然就成了内存火焰图。

4、perf probe 失败怎么办？

一、问题

二、解答：

在动态追踪怎么用中，咱们一块儿经过几个案例，学习了 perf、bcc 等动态追踪工具的使用方法。

这些动态追踪方法，能够在不修改代码、不重启服务的状况下，让你动态了解应用程序或内核的执行过程。这对于排查状况复杂、难复现的问题尤为有效。

在使用动态追踪工具时，因为十六进制格式的函数地址并不容易理解，就须要咱们借助调试信息，将它们转换为更直观的函数名。对于内核来讲，我已经屡次提到过，须要安装 debuginfo。
不过，针对应用程序又该怎么办呢？

这里其实有两种方法。

第一种方法，假如应用程序提供了调试信息软件包，那你就能够直接安装来使用。好比，对于咱们案例中的 bash 来讲，就能够经过下面的命令，来安装它的调试信息：

# Ubuntu
apt-get install -y bash-dbgsym

# Centos
debuginfo-install bash

第二种方法，使用源码从新编译应用程序，并开启编译器的调试信息开关，好比能够为 gcc 增长-g 选项。

5、问题 4：RED 法监控微服务应用

一、问题

二、解答：

在系统监控的综合思路中，我为你介绍了监控系统资源性能时经常使用的 USE 法。USE 法把系统资源的性能指标，简化成了三类：使用率、饱和度以及错误数。三者之中任一类别的指标太高时，都
表明相应的系统资源可能有性能瓶颈。

不过，对应用程序的监控来讲，这些指标显然就不合适了。由于应用程序的核心指标，是请求数、错误数和响应时间。那该怎么办呢？这其实，正是 Adam 同窗在留言中提到的 RED 方法。

RED 方法，是 Weave Cloud 在监控微服务性能时，结合 Prometheus 监控，所提出的一种监控思路——即对微服务来讲，监控它们的请求数（Rate）、错误数（Errors）以及响应时间

（Duration）。因此，RED 方法适用于微服务应用的监控，而 USE 方法适用于系统资源的监控。

6、问题 5：深刻内核的方法

一、问题

 

 

二、解答：

在定位性能问题时，咱们经过 perf、ebpf、systemtap 等各类方法排查时，极可能会发现，问题的热点在内核中的某个函数中。而青石和 xfan 的问题，就是如何去了解、深刻 Linux 内核的原
理，特别是想弄清楚，性能工具展现的内核函数究竟是什么含义。

其实，要了解内核函数的含义，最好的方法，就是去查询所用内核版本的源代码。这里，我推荐https://elixir.bootlin.com 这个网站。使用方法也很简单，从左边选择内核版本，再经过内核函数
名称去搜索就能够了。

之因此推荐这个网站，是由于它不只可让你快速搜索函数定位，还为全部的函数、变量、宏定义等，都提供了快速跳转的功能。这样，当你看到不明白的函数或变量时，点击就能够跳转到相
应的定义处。

此外，对于 eBPF 来讲，除了能够经过内核源码来了解，我更推荐你从 BPF Compiler Collection(BCC) 这个项目开始。BCC 提供了不少短小的示例，能够帮你快速了解 eBPF 的工做原理，并熟
悉 eBPF 程序的开发思路。了解这些基本的用法后，再去深刻 eBPF 的内部，就会轻松不少。

今天我主要回答这些问题，同时也欢迎你继续在留言区写下疑问和感想，我会持续不断地在留言区跟你交流。但愿借助每一次的答疑和交流，能够和你一块儿，

把专栏中的各类知识转化为你的能力。