Uber 最近发了一篇文章,主要讲的是在核心服务上动态调整 GOGC 来降低 GC 的 mark 阶段 CPU
占用。基本可以做到有效果,低风险,可扩展,半自动化。
Uber 当前的服务规模大概是几千微服务,基于云上的调度基础设施来进行部署。大部分服务是 GO 写的,这篇文章的作者是做 Maps Production
Engineering,这个组之前帮一些 Java 系统调整过 GC 参数(这应该就是他们帮 Go 做优化想的也是怎么调整参数的出发点吧)
在任何语言的并发编程场景中,都有 race 问题,现代语言为了解决 race 问题有两种思路,一种是像 rust 那样的通过所有权+Sync/Send
限制用户尽量无法写出带 race 的代码;一种是像 Go 这样,通过 race detector 在测试期间检查数据竞争问题。
Go 的 race detector 设计决定了其无法在线上环境开启,而很多公司的项目上线前其实是没有 race test 的环节的,这就导致了一些
Gopher
之前在做性能优化分享的时候,经常会说接口延迟大幅上升时,应该先去看看 pprof 里的 goroutine 页面,看看 goroutine
是不是阻塞在什么地方了(比如锁),如果确实是这样,那就去解决这个阻塞问题,可以大幅度优化接口的延迟。
如果我们只是做工程,知道上面这个简单的结论就可以了,最近在一个中年人技术群里,一位前同事问了这么个问题,《Systems Performance》这本书里有一个
USE 方法论,其中提到了一个 Saturation (饱和度)的概念,这个和 Utilization 有啥区别?实际工作中有把 Saturation
监控起来的么?
几个月前听过一个老同事说早期 lyft 来国内交流的时候,展示过他们强大的线下开发环境,所有的前后端服务都可以在同一台电脑上启动,颇为羡慕,正好最近陶师傅分享了
lyft 的线下环境方案
[https://eng.lyft.com/scaling-productivity-on-microservices-at-lyft-part-2-optimizing-for-fast-local-development-9f27a98b47ee]
,感觉参考价值挺大的。
先来定义一下问题:现在微服务架构在国内互联网公司已经普及了,互联网公司的主流程服务比较复杂,尽管已经尽最大努力进行解耦,改造过后还是会依赖几十至上百的外部服务
。这样导致的最大的问题是,业务研发在线下测试主流程服务极其困难。
如果你恰好在这样的环境工作,想一想,你在修改了主流程的代码之后,是不是没有办法在本地完成测试?是不是必须得把你的开发分支部署到远端的某个环境去?或者是不是必须部署到有
QA 维护的 Staging 环境才能开发 debug?
最近有意无意地看到三个分享,正好都是和优化相关的,看看不同领域对性能的不同关注点还是挺有意思的。
databend 的性能优化
[https://github.com/datafuselabs/datafuse-presentations/blob/master/meetup-20211203-performance-tuning-in-databend/performance-tuning-in-databend.pdf]
databend 是一个对标 clickhouse 的数据库,他们的性能目标是要比 ck 快,会追求一些比较细节的代码优化。
gvisor 在蚂蚁的优化
[https://gvisor.dev/blog/2021/12/02/running-gvisor-in-production-at-scale-in-ant/