治白癜风好的医院 http://m.39.net/pf/bdfyy/
净是拿比自己弱的人当对手，不可能有意思。没有人能一看到谜题就瞬间解出答案。读到一半就知道犯人的推理小说真是无聊透顶。将自身能力发挥至极限去解开问题，这时才能把知识变成自己的东西。　　　　　　　　—青木峰郎《Ruby源代码完全解读》　　　　　　　　　　　　　　　　

当我们对Go程序进行性能分析时，一般想到的方式是Pprof提供的一系列工具分析CPU火焰图、内存占用。

诚然，通过分析cpu耗时最多的流程，并设法对cpu耗时最多的函数进行优化，毫无疑问能够改善程序整体的状况。然而，优化了这些步骤就一定能够大幅度降低容器配置和机器数量吗，一定能够大幅度提高性能吗？答案是不确定的。一个函数在pprof中耗时多可能是因为他本身耗时就多，他是现象却不一定是问题。同时，在高负载情况下可能会导致某一些请求，某一些函数耗时突然升高。但是这种升高不一定能够体现在pprof上。因为pprof能看到整体的耗时情况，却无法分析个例。因此我们需要跳出pprofcpuprofiling，仔细审视程序遇到的最严重的性能瓶颈。

在本文中，将回顾笔者对于线上Goweb程序面临的性能瓶颈进行分析的过程，这一瓶颈分析的结果最终将导致线上节约上千台容器。本文中使用的工具和方法可以对排查其他瓶颈问题起到启发的作用。

愿望

程序的核心目标是能够在更短的时间并行处理更多的请求，需要保证正常情况下在ms以下的耗时保证

压测手段

调整机器权重，对于单台容器进行压测

现状？

通过压测分析，得到的现状是：

正常情况下服务~3qps。压测时候（通过调整权重）到达~16qps以上时，可见耗时p99（百分之1的请求高于该阈值）抖动，而p95保持稳定。正常pms+，压测时部分容器p99可见ms+

cpuidle80%以上

内存容量充足。

相同的请求再次调用时，走相同的代码路径，但是耗时能够恢复正常。这种耗时差距可达ms以上。

下游调用的耗时p99可见保持稳定，可以一定程度排除是网络耗时导致的

当容器飘逸到性能更强的宿主机之后，耗时能够得到显著缓解

因此我们主要面对的问题是耗时p99抖动的问题。接下来笔者从多个成面对此问题进行了分析。

请求

耗时上涨可能是因为

转载请注明:http://www.aideyishus.com/lkgx/310.html