三个故事

三个故事

故事一 无招胜有招

我有一个同事前是5Q(人人网的前身) 出来的,叫Z神,负责技术(所有解决不了的问题都找他),Z神从chinaren出道,跟着王兴一块创业做 5Q,5Q在学校靠鸡腿打下大片市场,最后被陈一舟的校内收购(据说被收购后5Q的好多技术都走了,最后王兴硬是呆在校内网把合约上的所有钱都拿到了)。

Z神让我最佩服的解决问题的能力,好多问题其实他也不一定就擅长,但是他就是有本事通过Help、Google不停地验证尝试就把一个不熟悉的问题给解决了,这是我最羡慕的能力,在后面的职业生涯中一直不停地往这个方面尝试。

应用刚启动连接到数据库的时候比较慢,但又不是慢查询

  1. Z神的解决办法是通过tcpdump来分析网络包,看网络包的时间戳和网络包的内容,然后找到了具体卡在了哪里。
  2. 如果是专业的DBA可能会通过show processlist 看具体连接在做什么,比如看到这些连接状态是 authentication 状态,然后再通过Google或者对这个状态的理解知道创建连接的时候MySQL需要反查IP、域名这里比较耗时,通过配置参数 skip-name-resolve 跳过去就好了。
  3. 如果是MySQL的老司机,一上来就知道连接慢的话跟 skip-name-resolve 关系最大。

在我眼里这三种方式都解决了问题,最后一种最快但是纯靠积累和经验,换个问题也许就不灵了;第一种方式是最牛逼和通用的,只需要最少的知识就把问题解决了。

我当时跟着Z神从sudo、ls等linux命令开始学起。当然我不会轻易去打搅他问他,每次碰到问题我尽量让他在我的电脑上来操作,解决后我再自己复盘,通过history调出他的所有操作记录,看他在我的电脑上用Google搜啥了,然后一个个去学习分析他每个动作,去想他为什么搜这个关键字,复盘完还有不懂的再到他面前跟他面对面的讨论他为什么要这么做,指导他这么做的知识和逻辑又是什么。

如果你学不会无招胜有招,那么history你总能学会吧!

这是当时的Z神用我的工作台(方方正正的显示器可见年代很久远了)

img

故事二 网络专家的机会

N年前我刚加入一家公司几个月,有一个客户购买了我们的产品上线后金额对不上(1类生产事故),于是经理带着我们几个技术去现场看看是什么原因,路上经理说你们不要有什么心理压力,我不懂技术但是我过去就是替你们挨骂的,我好好跪在客户那挨骂,你们好好安心解决问题。

问题大概就是客户有一段涉及交易的代码在事务中,但是提交到后端我们的服务上后钱对不上了,客户认为我们产品事务实现有问题。

到了现场客户不让下载他们代码,只能人肉趴在他们指定的机器上用眼睛看问题在哪里,看了三天自然是没找到为啥,大家非常沮丧地回来了,然后我们的产品被下线,客户直接把数据库换成了Oracle,换完后第一天没问题,我们是越发沮丧,大家都不敢提这个事情了,但是三天后一个振奋人心的消息传过来了:金额还是对不上 …… :))))))

于是我们再度派出技术人员帮他们看为什么(这次客户配合度高了很多),最后有个同事提了一嘴要不用 tcpdump 抓个包看看,到底应用代码有没有set autocommit=0, 半个小时后传来喜讯用户代码发出的就是autocommit=1,说明用户代码的事务配置没生效。

最后查出来配置文件中有中文注释,测试环境没有问题,但是生产环境机器不支持中文出现了乱码,中文注释后的配置文件没有被解析到,导致事务没有生效!

打个岔,类似问题你也可以看看这个MySQL JDBC驱动8.0的bug导致事务没生效

事情还没完,当我听到这个结果后恨不得实际抽自己,tcpdump咱也会用,怎么当时就没想到呢!于是后来我天天看tcpdump、分析网络包,有段时间最开心的是在酒店看书了。一个月后写了几篇文章放在公司内网,再然后公司内部各个团队开始拿着各种问题找过来,我的case也越来越多。

有一次产品调用是这样的 1->2->3->4->5->6 产品5是我们的,1说性能上不去,rt 是100太大,扯了两天皮,然后说5有问题,于是我到5上抓了个包,抓完包一分析,我心里有底了,明确告诉他们5的rt才2,压力还没有到5这里来,另外按照我抓包结果的rt分析,5的能力是20万,现在还不到1万,瓶颈在1-5之间,然后我上1/2/3/4用 netstat 分别看下网络状态发现1-2之间网络到了瓶颈(2回包给1的时候大量的包no ack),不要怀疑netstat真有这么强大,只是你不会看而已。如下图 2上的9108服务端口给1发回结果的时候1那边迟迟不给ack。其实这个case用好工具只是很小的一点,关键的是我能抓包分析出rt,然后从rt推断出系统的能力(别说全链路监控之类的,有时候还得拼刺刀),进而快速定位到瓶颈

image-20220611101850071

现在我们的产品文档必备一份tcpdump、tshark(wireshark命令行版本)救急命令箱,有时候让客户复制粘贴执行后给我们某个结果,好多问题不再是问题了

这个故事的结果是我成了公司的网络“专家”

故事三 Die是什么

2021年4月的时候,我们有个项目要在不同的硬件平台验收,那天傍晚7点正要回家的我被项目经理拽到了现场

系统性能不达标,现场都不知道为啥

我到现场看了下perf

img

然后处理了下,IPC从0.08提升到了0.22(IPC代表性能,越大越好),再细调下最终能到0.27,对应的业务测试QPS也是原来的4倍。

img

到这里谈不上任何故事性,我也很好奇为什么有这么好的效果,不信可以看这篇《十年后数据库还是不敢拥抱NUMA?》。

接下来的几天那个项目经理特批我拿他们的环境随便测试,于是我停下手头的工作,花了一周在这个环境做了很多验证和学习,并请教了公司CPU方面特别厉害的大佬,如下图(2021年我的水平就是这样,和所有程序员对CPU的了解一样,只是知道主频、核数,会看top)

img

大佬跟我说:两个Die的L3不互通。我就问了一句Die是啥意思,他回答一个晶圆。其实这时我还没有听懂,但是不好意思再问了– 这感觉你们平时都有吧,就是不在一个段位,差太远了,不好意思再问,到了该自己先去弄脏双手后再请教的时候了!

于是就Google各种概念、并收集各种资料和图,最后整理了一下(所以文章的连贯性其实不好),以个人笔记的形式存档下来了。

最后把这些笔记从多核、超线程、NUMA、睿频、功耗、GPU、大小核再到分支预测、cache_line失效、加锁代价、IPC等各种指标(都有对应的代码和测试数据)总结成了一系列文章。

image-20210802161410524

这个故事你觉得我想说啥,辛苦帮我在评论里总结下

其他想说的

看完故事升华一下方法论:如何在工作中学习

如果你觉得看完对你很有帮助可以通过如下方式找到我

find me on twitter: @plantegg

知识星球:https://t.zsxq.com/0cSFEUh2J

image-20230407232314969

开了一个星球,在里面讲解一些案例、知识、学习方法,肯定没法让大家称为顶尖程序员(我自己都不是),只是希望用我的方法、知识、经验、案例作为你的垫脚石,帮助你快速、早日成为一个基本合格的程序员。

争取在星球内:

  • 养成基本动手能力
  • 拥有起码的分析推理能力–按我接触的程序员,大多都是没有逻辑的
  • 知识上教会你几个关键的知识点