容器化 RDS:借助火焰图定位Kubernetes性能问题
容器化RDS系列文章:
容器化RDS:计算存储分离架构下的“Split-Brain”
容器化RDS:计算存储分离还是本地存储?
容器化RDS:你需要了解数据是如何被写"坏"的
容器化RDS:PersistentLocalVolumes和VolumeScheduling
容器化RDS:借助 CSI 扩展 Kubernetes 存储能力
借助 CSI(Container Storage Interface),加上对 Kubenetes 核心代码的少量修改,可以 out-tree 的方式高效且低耦合的方式扩展 Kubenetes 存储管理子模块。如《容器化 RDS:借助 CSI 扩展 Kubernetes 存储能力》介绍,以 out-tree 方式添加 PVC 扩容(Resize)特性。从可执行程序到可用编程产品,还需要设计结合业务需求的性能基准测试,并对发现的性能瓶颈进行优化。经验数据表明,相同功能的编程产品的成本,至少是已经过测试的程序的三倍。——人月神话本文将分享性能基准测试的优化案例:
发现性能瓶颈
确定问题组件
借助 CPU Profile 和 Flame Graph,快速缩小范围,定位到问题 code-path
有针对的优化
发现性能瓶颈
测试用例:
批量创建100个读写模式为RWO,容量为1GiB 的 PVC
期望测试结果:
180秒内全部创建成功并无报错
所有的编程人员都是乐观主义者,毕竟在可能出现问题的地方,一定都会遇到问题,在耗时 3600 秒后,95% 的 PVC 处于 Pending 状态,严格的说,在批量创建的场景,该功能不可用。
大量 PVC 处于 Pending 状态
定位问题组件
由于涉及组件众多:
kube-apiserver
kube-controller-manager
kubelet
external-provisioner
external-attacher
csi-driver
qcfs-csi-plugin
组件之间调用复杂,再加上无处不在的协程(goroutine),如果直接查看日志或是 debug code 定位问题,犹如大海捞针,更不要说定位性能瓶颈。所以,首要工作是先定位到问题组件。
在测试过程中,我们记录了所有组件和系统的资源使用情况,运气不佳,从 CPU 使用情况,内存使用情况,网络 I/O 和磁盘 I/O 来看都没有异常数据。
通过梳理存储管理相关组件的架构图:
架构图
以及业务流程的梳理,kube-controller-manager、external-provisioner 和 csi-driver 嫌疑较大。
通过 kubelet logs 查看日志,可以在 external-provisioner 中发现可疑日志:
I0728 19:19:50.504069 1 request.go:480] Throttling request took 192.714335ms, request: POST:https://10.96.0.1:443/api/v1/namespaces/default/eventsI0728 19:19:50.704033 1 request.go:480] Throttling request took 190.667675ms, request: POST:https://10.96.0.1:443/api/v1/namespaces/default/events
external-provisioner 访问 kube-apiserver 触发限流
external-provisioner 有重大嫌疑。
定位问题 code-path
我们可以立马进入调试环节:
阅读 external-provisioner 代码,加入调试日志,理解逻辑
不断缩小 code-path
步骤 1、2持续迭代,直到最终定位到问题函数,这是非常有效的办法。
或者采用 CPU profile:
采集堆栈样本
找到在采样手气内消耗 CPU 时间比率最高的函数,把该函数作为调试的起点
相比上一种,更高效的缩小问题的范围,节省更多的时间。
借助模块“net/http/pprof”,对 external-provisioner 进行 60 秒的 CPU 采样,可以获得如下信息:
生成堆栈使用百分比排序:
函数的调用关系以及采样周期内 CPU 耗时百分比:
针对“net/http/pprof”稍微啰嗦几句:
提供 CPU profile 和 Heap profile;
在采样时获得堆栈(几乎所有)信息, 以此为依据估算整个采样周期内堆栈的CPU占用百分比, 并不是 100% 准确;
采样成本并不低,100赫兹既可以采样够用的堆栈信息,又不会给应用程序带来过大开销;
CPU 采样频率默认为 100 赫兹,并硬编码到模块中, 不建议调到 500 赫兹以上。
网上已经有大量的相关文章,这里不赘述。
配合获取的 CPU profile 信息生成火焰图(Flame Graph):
这里针对火焰图再啰嗦下:
借助第三方工具 go-torch 绘制
每个矩形代表一个堆栈,采样时间内,CPU 占用百分比越高 Y 轴越长,X 轴表明了堆栈之间的调用关系
从左到右按照字母表排序
颜色随机选择,无具体含义
网上已经有大量的相关文章,这里不赘述。
可以发现函数 addClaim 和 lockProvisionClaimOperation 的 CPU 占用比率达到 36.23%。
来自于 external-provisioner 调用的第三方模块 kubenetes-incubator/external-storage
所以,只要引用例如了模块 Kubenetes-incubator/external-storage 实现卷创建功能,都可以复现 api throttling。
再针对性的加入调试日志到 code-path 中,理解逻辑,很快可以确定问题:
在创建卷时,external-storage 需要访问 API 资源(譬如 configmap、pvc、pv、event、secrets、storageclass 等),为减少 kube-apiserver 工作负荷,不建议直接访问 kube-apiserver,而应该利用本地缓存(由 informer cache 构建)。但 external-storage 恰好直接访问 kube-apiserver。通过下图可以看到,有18.84%的采样时间在 list event,这是导致 api throttling 的原因。
进一步分析,之所以有大量的 list event 是因为 Leader Election 的 Lock 实现粒度太细导致锁抢占严重。生产环境中,一个组件会启动多个实例,抢占到 Leader Lock 的实例即为 Leader 并对外提供服务,其他实例以 Slave 模式运行,一旦 Leader 出现问题,Slave 发现 Leader Lock 在租期内没有更新即可发起抢占成为新的 Leader 并接管服务。这样不仅提升了组件的可用性也避免了可能带来的 data race 问题。所以可以理解成是一个组件实例一把锁,并且只在 Leader 和 Slave 角色切换时才会重新选主,但 external-storage 原意为了提升并发度,运行多个实例同时为 Leader 提供服务,可以简单理解成一个 PVC 一把锁,100 PVC 就意味着多个实例要最少发生100次的 Lock 抢占。
最终定位到问题原因:
Lock 的抢占导致 api throttling,引发 Lock 抢占 timeout,timeout 后抢占重试,进一步恶化 api throttling。
从下图可以进一步得到验证,有 8.7% 的采样时间在进行 Leader Election。
解决问题
一旦发现问题的根源,解决它反而是件不难的事情。后面针对该问题做了修复:
采用 sharedinformer cache
修改 Leader Lock 粒度
再次生成运行,可以发现函数 addClaim 和 lockProvisionClaimOperation 的 CPU 占用百分比下降到 13.95%。
external-provisioner 日志中的 throttling 关键字消失
100 PVC 的时间缩短到60秒以内全部创建成功,无任何报错。
结语
对于终端用户而言,交互的界面越来越简单,但对于开发者而言,组件越来越多,编译一次的时间越来越久,加上无处不在的并发,导致定位问题的难度越来越大,尤其是性能问题。所以,对体系架构的理解能帮我们快速锁定问题组件,配合 Profile 工具和 Flame Graph 快速定位 code-path,再加上对业务逻辑的理解找到解决方案。所有的编程人员都是乐观主义者,无论是什么样的程序,结果是勿庸置疑的:"这次它肯定会运行。" 或者 "我刚刚找出了最后一个问题。" ——人月神话
Kubernetes实战培训
Kubernetes应用实战培训将于2018年10月12日在深圳开课,3天时间带你系统学习Kubernetes。本次培训包括:容器基础、Docker基础、Docker进阶、Kubernetes架构及部署、Kubernetes常用对象、Kubernetes网络、存储、服务发现、Kubernetes的调度和服务质量保证、监控和日志、Helm、项目实践等,点击下方图片查看详情。
容器化 RDS:借助火焰图定位Kubernetes性能问题相关推荐
- mysql docker还是rds_容器化RDS:计算存储分离还是本地存储?
随着交流机会的增多(集中在金融行业,规模都在各自领域数一数二),发现大家对 Docker + Kubernetes 的接受程度超乎想象, 并极有兴趣将这套架构应用到 RDS 领域.数据库服务的需求可以 ...
- mysql火焰图_【性能】如何使用perf和火焰图分析系统性能?
一.实验环境 二.实验案例分析 安装完成后,我们先在第一个终端,执行下面的命令运行案例,也就是一个最基本的 Nginx 应用: 运行 Nginx 服务并对外开放 80 端口 # docker run ...
- 记一次Arthas火焰图(Flame Graph)性能分析实战
前言 最近负责的一个核心服务,TP999总是被上游吐槽,失败率也比较高.TP999达到了200ms+,最终通过arhas的火焰图,直接定位到了耗时的原因,是由于对象多余的序列化和反序列化导致的,去掉后 ...
- perf + 火焰图分析程序性能
From: https://www.cnblogs.com/happyliu/p/6142929.html 1.perf命令简要介绍 性能调优时,我们通常需要分析查找到程序百分比高的热点代码片段,这便 ...
- 超好用的自带火焰图的 Java 性能分析工具 Async-profiler 了解一下
如果你经常遇到 Java 线上性能问题束手无策,看着线上服务 CPU 飙升一筹莫展,发现内存不断泄露满脸茫然.别慌,这里有一款低开销.自带火焰图.让你大呼好用的 Java 性能分析工具 - async ...
- mysql火焰图_perf + 火焰图分析程序性能 - 刘志鹏的Blog - 博客园
1.perf命令简要介绍 性能调优时,我们通常需要分析查找到程序百分比高的热点代码片段,这便需要使用 perf record 记录单个函数级别的统计信息,并使用 perf report 来显示统计结果 ...
- 宋宝华: 用off-cpu火焰图进行Linux性能分析
在<宋宝华:火焰图:全局视野的Linux性能剖析>一文中,我们主要看了on-cpu火焰图,理解了系统的CPU的走向的分析.但是,很多时候,单纯地看on-cpu的情况(什么代码在耗费CPU) ...
- 巧用“火焰图”快速分析链路性能
火焰图(Flame Graph)是由 Linux 性能优化大师 Brendan Gregg 发明的用于分析性能瓶颈的可视化图表,它以一个全局的视野来看待时间分布,从顶部往底部列出所有可能导致性能瓶颈 ...
- mysql火焰图_perf + 火焰图分析程序性能
1.perf命令简要介绍 性能调优时,我们通常需要分析查找到程序百分比高的热点代码片段,这便需要使用 perf record 记录单个函数级别的统计信息,并使用 perf report 来显示统计结果 ...
- 阿里云容器化GPU共享服务已开放!性能无损失,对你的环境无侵入,真正实现AI降本增效...
杨净 发自 凹非寺 量子位 报道 | 公众号 QbitAI 随着GPU算力越来越强,其成本也越来越高昂. 但有时,执行一个深度学习任务,并不需要占用一整张GPU. 就相当于,你不仅多花了钱,还浪费了 ...
最新文章
- db 文件 加密_有人说Kettle 数据库JNDI方式数据库密码不能加密,搞他!
- c语言模板程序,模板模式 (C语言实现)
- mysql 防注入 php_PHP+mysql防止SQL注入的方法小结
- ASP.NET MVC从数据库读取、存入图片
- 公众号网页能调用银联支付么_支付宝新一代刷脸支付硬件发布,自带“轮子”,三天就能开发小程序...
- 2021考研——复习规划(数学篇)
- Easy RM to MP3 Converter漏洞分析报告
- 模拟将本地文件上传至外服务器
- 对于Android11无法访问Android/data的解决方案 还在为你的大姐姐找不到而担心吗?还在为你的学习资料找不到而发愁吗?2021-03-11
- 三个等于符号 和两个等于符号的区别
- 如何在 Excel 表格中查找数据
- 【深度学习】Numpy实现简单神经网络
- 目标检测——day66 Scaled-YOLOv4: Scaling Cross Stage Partial Network
- 2022年食盐市场现状
- C语言:浙大版《C语言程序设计(第3版)》题目集 习题5-5 使用函数统计指定数字的个数 (15 分)
- ANSI colored Python logging — Gist
- 如何安全使用公共Wifi,防止信息泄露?
- torch.max()、expand()、expand_as()使用讲解
- Mac 系统option键的妙用
- IntelliJ IDEA 15款 神级超级牛逼插件推荐(自用,真的超级牛逼)