41|线上综合案例:节约线上千台容器的性能分析实战
郑建勋
你好,我是郑建勋。
当我们对 Go 程序进行性能分析时,一般想到的方式是使用 pprof 提供的一系列工具分析 CPU 火焰图、内存占用情况等。
诚然,通过分析 CPU 耗时最多的流程,设法对 CPU 耗时最多的函数进行优化,毫无疑问能够改善程序整体的状况。然而,优化了这些步骤就一定能够大幅度提高容器的 QPS,降低机器数量,一定能够大幅度提高性能吗?
不一定。因为一个函数在 pprof 中耗时多,可能是因为它本身耗时就多,它是现象却不一定是问题。同时,在高负载情况下,可能会导致某一些请求、函数的耗时突然升高,而这些异常却又不一定能够体现在 pprof 上。因为 pprof 能看到整体的耗时情况,却难以分析个例。因此,有时候我们需要跳出 pprof cpu profiling,仔细审视程序遇到的最严重的性能瓶颈。
这节课,我们一起来回顾分析线上的 Go Web 程序的性能瓶颈的整个过程,看看最终如何节约上千台容器。这节课用到的工具和方法也可以给我们排查其他瓶颈问题一些启发。
程序问题描述与排查过程
我们团队维护的一个核心程序为 Go Web 服务,当前程序能够承载的 QPS 非常低。当 QPS 上涨到一个阈值时,就会出现 p99 抖动,导致接口耗时超过了上游给定的超时时间。在过去,解决这类问题的方法就是加容器来分摊请求量,随着业务发展,时间久了,这个核心服务线上就有了几千台容器。最近几年,很多开发者都尝试分析这个问题的原因,但都无功而返,现在由于有了降本的需求,需要再次直视这个问题。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文深入介绍了Go Web程序性能分析及解决实战经验,分享了解决上千台容器性能瓶颈的过程。首先描述了程序性能问题,包括QPS上涨导致的p99抖动、CPU空闲率高、内存利用率正常等现象。通过排查请求排队、程序状态恶化、网络请求处理、磁盘IO、系统调用、调度器延迟、CPU消耗、并发锁、日志写入、垃圾回收等可能的问题,逐一排除了各种假设。最终,通过分析调度器细节和使用trace工具,发现程序存在极大的QPS提升空间,且没有明显的瓶颈问题。进一步分析发现,GC阶段下大量的内存分配导致了大量的辅助标记,加上专有GC处理占用了2个线程,导致程序运行状态迅速恶化。作者提出了减少内存分配和构建内存池来复用内存的解决思路,并分享了sync.Pool的最佳实践。总之,本文通过深入分析和解决实际性能问题,为读者提供了宝贵的技术经验和解决思路。文章强调了合适的时间使用合适的工具,将起到事半功倍的效果,以及trace工具在分析程序整体运行状态和P99瓶颈问题时的强大作用。文章还指出在容器化趋势下,排查复杂问题变得更加困难,需要有体系化的思考和强大的学习能力。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Go 进阶 · 分布式爬虫实战》,新⼈⾸单¥68
《Go 进阶 · 分布式爬虫实战》,新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(3)
- 最新
- 精选
- Realm1.CPU - top - vmstat - mpstat - pidstat - /proc/softirqs - /proc/interrupts, - sar - strace - perf 2.内存: - free - top - vmstat -pidstat -sar2023-01-12归属地:浙江3
- 牙小木一种是减少(此处为“合理“比较合适)内存的分配,比如代码层面的优化 另一种思路是构建内存池来复用内存, 最后一个暴力的思路是加大gc执行的阈值,2023-08-19归属地:北京
- 牙小木这篇不错,团队的力量2023-08-19归属地:北京
收起评论