Golang Go语言中 一个线上的 Go 程序,是否应该长期开启 pprof
null
Golang Go语言中 一个线上的 Go 程序,是否应该长期开启 pprof
不应该,开启 pprof 会影响性能
更多关于Golang Go语言中 一个线上的 Go 程序,是否应该长期开启 pprof的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
没性能压力的,建议开着。你永远不知道线上会出什么幺蛾子。
赞同二楼说的,你永远不知道线上会出什么幺蛾子!!!
我再补充一下:
没性能压力的,建议开着。
有性能压力的,建议多开两个实例😆
运维的心声:硬件其实挺不值钱的,比起出故障的损失(经济和背锅)
那还是开着好😆,这跑的也不是太消耗性能的程序
在没有 pprof 的时候只会耗一个 http 协程的开销,只有在 pprof 的时候才会有额外的开销。
我都是注册一个 sigusr1 来开启 pprof ,默认不开,不过一直监听一个本地端口也无所谓
#3 是我最后实践的方式。
之前遇到过一个问题,grpc 服务,不定时出现 OOM ,由于配置了 docker restart always ,所以头几次 oom 并没有人发现。
快两个月以后,有客户反应,阶段性服务不可用,这个时候才回去看日志,才知道上线之处就有问题了。
之后就不管需要不需要,pprof 一律都给安排上了。实在对性能要求高的,一个开,一个不开,前面怼上 SLB
那如果是没开 pprof 的那个出现问题呢
做的动态的开关吗 好像也是个不错的操作。
net/http/pprof
会有性能损耗?
我看源码,只会在 init 函数注册几个 debug/pprof http HandleFunc 。
不都是用 http 接口么…本来 metric 也要 http 啊,有啥开销
pprof 不会消耗性能吧,我记得压测对比过 http 服务是相差无几的
在Go语言中,对于线上的Go程序,是否应该长期开启pprof
(性能分析工具),这取决于多个因素的综合考量。
首先,pprof
是一个非常强大的工具,可以帮助开发者深入了解程序的性能瓶颈、内存使用情况等。在开发阶段和性能测试阶段,开启pprof
是非常有益的。
然而,对于线上的生产环境,长期开启pprof
可能会带来一些额外的开销,包括CPU和内存资源的占用,以及可能暴露的敏感信息风险。因此,在生产环境中长期开启pprof
需要谨慎考虑。
一种常见的做法是在生产环境中根据需要临时开启pprof
,例如在遇到性能问题时。这可以通过配置管理系统或环境变量来实现,以便在需要时快速启用。
此外,还可以考虑使用采样率等参数来优化pprof
的性能影响。通过调整采样率,可以在保持性能数据准确性的同时,减少pprof
对线上程序的影响。
总之,对于线上的Go程序,是否长期开启pprof
需要根据具体情况来决定。在权衡性能开销、安全性以及性能调优需求后,做出最合适的决策。同时,建议定期评估和调整pprof
的使用策略,以适应不断变化的应用需求和性能状况。