V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Stendan
V2EX  ›  哔哩哔哩

如何看待 2021.07.13 B 站崩溃事件

  •  1
     
  •   Stendan · 2022-07-15 08:39:10 +08:00 · 14661 次点击
    这是一个创建于 640 天前的主题,其中的信息可能已经有所发展或是发生改变。
    第 1 条附言  ·  2022-07-15 13:41:44 +08:00
    2022.07.16 14:00-17:00 直播预告

    B 站“713 事故”后的多活容灾建设优化
    分享嘉宾曾深度参与 713 故障处理,本次分享将对 713 部分问题做答疑解惑,同时还会分享 B 站常见的高可用方案和故障后的多活容灾建设优化。

    https://www.bilibili.com/read/cv17581401
    103 条回复    2022-07-16 10:48:31 +08:00
    1  2  
    chendy
        1
    chendy  
       2022-07-15 08:43:10 +08:00   ❤️ 16
    出门左转知乎
    elfive
        2
    elfive  
       2022-07-15 08:46:22 +08:00 via iPhone   ❤️ 11
    有什么好看的?
    站在程序员的角度,没人能写出 100%不出问题的代码,都是一种概率妥协而已。
    storyxc
        3
    storyxc  
       2022-07-15 08:46:42 +08:00
    昨天用手机看的。
    Xhack
        4
    Xhack  
       2022-07-15 08:47:50 +08:00
    楼主 感觉像是键盘侠之类的,我坐着 拿手机看的 然后呢?
    teenight
        5
    teenight  
       2022-07-15 08:49:11 +08:00 via Android
    以平常心看待
    imdong
        6
    imdong  
       2022-07-15 08:52:04 +08:00 via iPhone
    怎么看?直播围观咯。

    https://files.catbox.moe/gky3wt.jpeg
    manshisan
        7
    manshisan  
       2022-07-15 08:57:07 +08:00 via iPhone
    @imdong 关注了
    jinliming2
        8
    jinliming2  
       2022-07-15 08:59:58 +08:00 via iPhone
    事故发生一周年,B 站出了事故分析报告……
    重启没用,回滚没用,最终还是重装解决 99 % 的问题……
    Stendan
        9
    Stendan  
    OP
       2022-07-15 09:06:43 +08:00   ❤️ 8
    @Xhack 生活如意,没空对线
    R18
        10
    R18  
       2022-07-15 09:07:06 +08:00
    希望大公司多出这种文章内容
    krly0912
        11
    krly0912  
       2022-07-15 09:07:24 +08:00
    @jinliming2 看了事故分析报告解析,是 7 层 slb 的负载均衡更新了功能,一行 lua 代码因为类型转换原因导致无限递归造成的。cpu 直接打到 100%。重启后诱发因子消失了,所以正常了
    lixiaobai913
        12
    lixiaobai913  
       2022-07-15 09:07:27 +08:00
    2022.07.14 的 QQ 上午发送不了离线文件怎么看待?
    EastLord
        13
    EastLord  
       2022-07-15 09:09:18 +08:00   ❤️ 1
    我还以为是 2022 年
    equationl
        14
    equationl  
       2022-07-15 09:11:36 +08:00
    @jinliming2 要是重装也没用是不是该到重买了(
    leido
        15
    leido  
       2022-07-15 09:11:41 +08:00   ❤️ 5
    重点是, 去年的事怎么今年才出报告...
    isno
        16
    isno  
       2022-07-15 09:13:36 +08:00
    @leido 大公司信息公开都是要审核 走流程的

    而且 B 站又没有义务一定要对外出这个故障报告
    MEIerer
        17
    MEIerer  
       2022-07-15 09:15:40 +08:00
    我觉得很正常,代码不能顾及全部,没影响用户数据就行。还有你这贴在知乎有人发过了,不会是来骗铜币的吧
    qping
        18
    qping  
       2022-07-15 09:21:41 +08:00
    @krly0912 #11 这有点厉害,怎么能定位到这个 lua 代码的
    technet
        19
    technet  
       2022-07-15 09:21:52 +08:00
    @elfive 微信似乎比 Facebook cloudflare 谷歌推特等网站还要稳定,几乎很少出现宕机
    ChicC
        20
    ChicC  
       2022-07-15 09:25:11 +08:00
    递归
    ccagml
        21
    ccagml  
       2022-07-15 09:29:43 +08:00 via Android   ❤️ 1
    原来大家都是,重启->回滚代码->重装
    QuinceyWu
        22
    QuinceyWu  
       2022-07-15 09:31:51 +08:00   ❤️ 3
    Block List + 1
    xingyuc
        23
    xingyuc  
       2022-07-15 09:33:05 +08:00
    如何看待 QQ 大规模盗号
    shyrock
        24
    shyrock  
       2022-07-15 09:33:26 +08:00
    挺佩服的,大厂有资源和决心花这么长时间做根因分析。

    换成我,感觉挖不到这么深的原因。只能作为悬案归档。
    zhoudaiyu
        25
    zhoudaiyu  
       2022-07-15 09:34:17 +08:00
    原来 SLB 也可以写扩展逻辑
    Leviathann
        26
    Leviathann  
       2022-07-15 09:36:41 +08:00
    我的评价是:动态弱类型语言就是个 jb
    kkocdko
        27
    kkocdko  
       2022-07-15 09:46:07 +08:00
    有很多人给出了各种答案,比如类型检查,写测试等等。

    但我想说的是,一切缓解和检查措施总有失效的时候。我更看重备份与回滚,以及快速的介入,保证事故发生时的控制权。
    liuliangyz
        28
    liuliangyz  
       2022-07-15 09:47:20 +08:00
    @leido 人家没有衣服公开报告,而且这么大的事,牵扯多少部门,多少同学。最终报告要层层递交。
    didilili
        29
    didilili  
       2022-07-15 09:52:06 +08:00
    写的如此详细,着实是受教了~
    ElliotQi
        30
    ElliotQi  
       2022-07-15 09:52:48 +08:00
    @qping Flame Graph 看出来的?
    bxb100
        31
    bxb100  
       2022-07-15 09:54:09 +08:00 via Android
    B 站解决问题的方案:猜,线下重试,现场火焰图
    DingJZ
        32
    DingJZ  
       2022-07-15 09:56:17 +08:00
    01:50 此时在线业务基本全部恢复。

    当晚已定位到诱因是某个容器 IP 的 weight="0"。此应用在 1:45 时发布完成,weight="0"的诱因已消除。所以后续关闭 jit 虽然无效,但因为诱因消失,所以重启 SLB 后恢复正常。

    一顿操作之后,还是外部变化消失+重启恢复的,中间重建之类的操作其实都没用

    面对故障,一找出变化,二回滚。
    newmlp
        33
    newmlp  
       2022-07-15 10:09:09 +08:00
    关键服务还搞 lua 脚本这种花里胡哨的东西,该
    zapper
        34
    zapper  
       2022-07-15 10:10:13 +08:00   ❤️ 10
    v2 知乎化
    知乎贴吧化
    贴吧粪坑化
    nomagick
        35
    nomagick  
       2022-07-15 10:11:24 +08:00   ❤️ 5
    根本原因还没意识到呢

    硬件防火墙一般都有一个非常方便切换的旁路模式,可以迅速消除防火墙对网络的影响。

    像 WAF 这种东西充满不确定性,其行为飘忽不定,代码质量堪忧,流量处理能力和流量内容相关,更有复杂的过滤逻辑,搞不好啥时候就出问题。

    在自己流量路径上串行设置 WAF 类似物而没有旁路机制,这才是症结。

    我看这报告问题还是归咎在开发上,开发是有问题,但不至于影响全业务,真正的问题在架构上,首席架构师引咎吧
    yujinchn
        36
    yujinchn  
       2022-07-15 10:21:06 +08:00
    @shyrock 原因没找到,这次可以了不代表下次就不会又出现,找到原因直接解决更好
    shyrock
        37
    shyrock  
       2022-07-15 10:41:00 +08:00
    @yujinchn 我看原文不是定位到了具体的 lua 代码了?怎么你说没找到
    joyyu
        38
    joyyu  
       2022-07-15 10:55:18 +08:00
    "0" != 0
    Mac
        39
    Mac  
       2022-07-15 10:58:09 +08:00 via Android
    昨天我家洗衣机崩了,不脱水,原因就是一个字,便宜。
    EminemW
        40
    EminemW  
       2022-07-15 11:06:21 +08:00 via iPhone
    所以算是自测的时候没考虑到边界条件?”0” != 0
    Zerek
        41
    Zerek  
       2022-07-15 11:25:00 +08:00
    7 月 13 ?定眼一看哦。。。2021
    wanacry
        42
    wanacry  
       2022-07-15 11:29:25 +08:00 via iPhone
    昨天我家里的洗衣机修好了
    wangyzj
        43
    wangyzj  
       2022-07-15 11:41:05 +08:00   ❤️ 3
    这个文章就说明 B 站最基本的运维流程都没有,还是几个关键人物在支持,核心组件没有冗余,问题还很多

    但归根结底,搞运维嘛
    没事的时候你是成本
    有事的时候是你的责任
    给运维花钱总觉得亏得慌
    又让马儿跑,又不给吃草
    做得好是让自己失业,做的不好就得背锅一样失业

    总之,运维,都这个 B 样
    abuabu
        44
    abuabu  
       2022-07-15 11:41:15 +08:00   ❤️ 30
    为什么一个很好能够讨论技术的帖子会被冷嘲热讽?
    lookStupiToForce
        45
    lookStupiToForce  
       2022-07-15 11:43:26 +08:00
    v2 上还有玩鄙视链的
    真是有人的地方就有恶臭的圈子习气
    nyakoy
        46
    nyakoy  
       2022-07-15 11:48:29 +08:00
    堪称精彩,但是代码得防御边界做的如此弱确实没想到
    Baloneo
        47
    Baloneo  
       2022-07-15 11:56:36 +08:00
    要么用电脑看 要么手机看
    crazytudou
        48
    crazytudou  
       2022-07-15 11:57:26 +08:00
    逼乎:你怎么看?
    mmnnyycc
        49
    mmnnyycc  
       2022-07-15 12:03:01 +08:00
    @qping #18 openresty 商业公司,春哥说的 100%无侵入式的
    mmnnyycc
        50
    mmnnyycc  
       2022-07-15 12:04:48 +08:00   ❤️ 4
    几分钟前章亦春说的原话:
    B 站这两天发表了一篇总结去年那场大事故的文章: https://mp.weixin.qq.com/s/nGtC5lBX_Iaj57HIdXq3Qg 当时我们 OpenResty Inc 公司团队帮助 B 站在线上快速定位了导致 CPU 100% 的 Lua 代码路径。B 站是我们的 OpenResty XRay 产品的商业客户。

    文中提到的 Lua 火焰图就是 OpenResty XRay 在 B 站生产服务器上采样有问题的 OpenResty 服务进程得到的。生成火焰图也就花了几分钟的时间,因为使用 100% 非侵入的动态追踪技术,并不需要对 B 站的进程进行任何修改。根据 Lua 火焰图最终确认根源问题是 B 站的业务往 Redis 服务器里写入了个字符串类型的权重 0 值的坏数据(即 “0”),而 Lua 代码期望的是数值类型的权重值,从而导致了无限递归和无限循环。文中提到的 LuaJIT 的 JIT 编译器的问题其实并不存在; JIT 编译器在这里并没有 bug 。

    感谢 Bilibili 对我们公司产品和技术的信任和支持!当然,B 站线上系统使用的也是我们的开源 OpenResty 软件。OpenResty XRay 产品主页: https://openresty.com.cn/cn/xray/
    Morii
        51
    Morii  
       2022-07-15 12:20:09 +08:00
    @shyrock #24

    要分锅的,开复盘大会。
    dxppp
        52
    dxppp  
       2022-07-15 13:13:47 +08:00 via Android
    官方微信公众号也发了相同的文章
    https://mp.weixin.qq.com/s/nGtC5lBX_Iaj57HIdXq3Qg
    VZXXBACQ
        53
    VZXXBACQ  
       2022-07-15 13:33:22 +08:00
    技术讨论文章为什么会有这么多莫名奇妙的回复?怎么看待不是很正常吗?

    弱类型真不行。
    Huelse
        54
    Huelse  
       2022-07-15 13:38:41 +08:00
    LUA 这种弱类型语言在这种地方真的要命
    siweipancc
        55
    siweipancc  
       2022-07-15 13:47:30 +08:00 via iPhone
    草,又是弱类型
    edward1987
        56
    edward1987  
       2022-07-15 14:19:55 +08:00
    主题值得讨论,但是能别用逼乎标题吗。。。不喜欢
    edward1987
        57
    edward1987  
       2022-07-15 14:21:11 +08:00
    只要有无限递归的可能,我觉得最好都打个日志,配个上限。。。曾经也遇到过😂
    zapper
        58
    zapper  
       2022-07-15 14:33:01 +08:00
    @VZXXBACQ #52 没看出来哪里讨论技术,lz 甚至没有自己的观点。
    maguowei
        59
    maguowei  
       2022-07-15 14:39:08 +08:00
    @mmnnyycc 这个有原文出处么?还是来自非公开的信息源?
    VZXXBACQ
        60
    VZXXBACQ  
       2022-07-15 14:40:21 +08:00
    @zapper LZ 附上的文章是很不错的一线技术讨论,分享出来问大家如何看待有什么问题吗😂
    dorothyREN
        61
    dorothyREN  
       2022-07-15 14:43:19 +08:00
    @wangyzj #43 我现在都后悔入了运维的坑
    exploreexe
        62
    exploreexe  
       2022-07-15 14:43:31 +08:00
    你去知乎发帖子啊,还怎么看。。。
    GeorgeGalway
        63
    GeorgeGalway  
       2022-07-15 14:48:33 +08:00
    @VZXXBACQ 我感觉也是,前几楼的冷嘲热讽让我怀疑楼主发了个钓鱼文章
    blless
        64
    blless  
       2022-07-15 14:53:27 +08:00   ❤️ 12
    本老运维出来说一点点。
    核心就是 B 站对运维投入应该不够重视。几个关键字,2021 年,自建机房,OpenResty+注册中心 ,线上网络和办公网络互通,关键业务 SLB 居然还要临时新建,业务回滚极不完善。

    不过也是事后 BB 罢了,线上原因多种多样。运维做多了,个人觉得核心在于不是排查出问题或者解决问题,而是快速恢复,降低影响。所以一个老运维需要很清楚知道,一些改动可能影响的范围。

    这里事故的关键点其实在于,利用 OpenResty 的灵活性,接入了一个可以动态获取网关配置的注册中心。也就是说 LB 的配置变更的核心在于注册中心配置下发的配置。(我以前公司任何可能改动到网关的配置审核都是三层审核)。这里我猜很有可能 B 站注册中心下发配置权限在另一个部门,而且可能绕开了线上运维人员的审核。然后整个事故报告里面没有提到一句下发错误配置的部门,整个事故报告围绕自身问题...似乎看到了一个已经被强势业务部门 PUA 成性的背锅老运维了。所以如何把关键变更权掌控在运维手上,或者至少有效通知到运维人员,才是运维的关键。但是这一点往往因为业务线太长,需要公司更高层级的支持,所以往往一个公司的运维好坏是跟公司整体相关的。强势业务部门就会以各种理由抵制这些手段,老板也会站在业务部门角度。没有任何办法,只能等血淋淋的线上事故发生之后,趁机搞一点运维建设。

    另外好多人一说事故就提高可用,问题是高可用上限是没有边界的。公司不注重运维体系建设,盲目砸钱搞高可用,本来人就不多,还要加工作量,我只能说下次事故说不定指日可待
    hsiaochi
        65
    hsiaochi  
       2022-07-15 14:55:44 +08:00
    用手机看,用电脑看,用平板看。。。
    pastor
        66
    pastor  
       2022-07-15 14:57:02 +08:00
    @blless 感觉应该多加一些配置中心分组,不同节点连到不同的配置中心,升级的时候也可以分批次更新配置,按分组从小到大、先更新小分组,跑一阵正常了之后再更新下一批,避免一跪全跪
    zapper
        67
    zapper  
       2022-07-15 15:04:43 +08:00   ❤️ 1
    @VZXXBACQ #59
    @GeorgeGalway #62
    我觉得其实这个帖子大可不必使用这个标题,甚至有点文不对题。因为内容主题是这次事件的解决报告,而这次事件本身早就已经过去一年了。
    而我所说的“v2 知乎化”,包括但不限于此类大量以前泛滥于知乎的主题:“如何看待 x“、”x 是什么体验”;
    而“知乎贴吧化”,意为知乎现在泛滥着贴吧以前出现的各种求助类问题例如“windows 未能启动 按 F8 没用怎么办?”。
    而大部分贴吧早就已经断气了
    当然我没有权利去管别人发什么,只是单纯表达对现在帖子标题的一种无奈
    blless
        68
    blless  
       2022-07-15 15:16:01 +08:00 via Android
    @pastor #66 能做的话都不是事,但是这种一般工作量太大了。涉及人和部门非常多,协作起来真的要命。除非整个 Ops 平台化建设都很完备才有可能这么搞
    maguowei
        69
    maguowei  
       2022-07-15 15:21:27 +08:00
    @mmnnyycc 看到了,在微博上
    HFX3389
        70
    HFX3389  
       2022-07-15 15:36:05 +08:00
    @dorothyREN #61 但我学前端的是被 recoil 搞的人都蒙了,最后发现好像我不适合造东西,适合用东西...
    realrojeralone
        71
    realrojeralone  
       2022-07-15 15:47:08 +08:00   ❤️ 1
    a90120411
        72
    a90120411  
       2022-07-15 16:18:39 +08:00
    我只知道 B 站在每个视频连接后面动态加了 vd_source 参数很恶心。
    wangyzj
        73
    wangyzj  
       2022-07-15 16:25:29 +08:00
    @blless #64 万事不决先重启
    重启不行就多重启几遍
    yujinchn
        74
    yujinchn  
       2022-07-15 16:31:17 +08:00
    @shyrock 你看我回复的谁,没说找不到啊,我意思就是说这种最好能找出详细原因,不然指不定下次又出现
    flyqie
        75
    flyqie  
       2022-07-15 16:36:20 +08:00 via Android
    看完了,着实没想到当时的事故居然由于这种低级错误。

    通过一个缺失的 if type(b) == "number",暴露出来了这么多问题。。
    yujinchn
        76
    yujinchn  
       2022-07-15 16:37:20 +08:00
    @shyrock 就你回复的啊,我的问题,说的有歧义,没说 b 站没找到,是说要是原因没找到的话
    A555
        77
    A555  
       2022-07-15 17:16:03 +08:00
    去年的事,今年发事故报告
    salmon5
        78
    salmon5  
       2022-07-15 17:32:46 +08:00
    我只关心内部管理和绩效上怎么处理的,其他都是渣渣
    pastor
        79
    pastor  
       2022-07-15 17:36:13 +08:00
    会不会 2022.07.16 14:00-17:00 直播时又发生宕机,如果赶巧,就更社死了...
    Cbdy
        80
    Cbdy  
       2022-07-15 17:38:34 +08:00 via Android
    B 站的网站做的是真烂,令人作呕
    Sixyuan
        81
    Sixyuan  
       2022-07-15 17:51:03 +08:00
    重点是,op 为什么不发表自己的看法?我认为这是交流的前提。
    vision4fun
        82
    vision4fun  
       2022-07-15 17:54:58 +08:00
    领导,人不够,加点人吧!
    LeegoYih
        83
    LeegoYih  
       2022-07-15 17:56:03 +08:00
    草台
    Tussik
        84
    Tussik  
       2022-07-15 17:56:09 +08:00
    我昨天在哔哩哔哩节点下也发了相关帖子,楼里关于测试的部分讨论我觉得还挺有意思的,大家有兴趣可以看看
    https://v2ex.com/t/866226
    NiZerin
        85
    NiZerin  
       2022-07-15 17:59:00 +08:00
    简单的说就是:弱类型的锅
    frostnotfall
        86
    frostnotfall  
       2022-07-15 18:01:39 +08:00   ❤️ 1
    根本原因是 lua 传参时传 0 导致异常。

    “_gcd 函数对入参没有做类型校验,允许参数 b 传入:"0"。同时因为"0" != 0 ,所以此函数第一次执行后返回是 _gcd("0",nan)。如果传入的是 int 0 ,则会触发[ if b == 0 ]分支逻辑判断,不会死循环。”

    说实话,lua 语言欠缺的恰恰就是种种类似这样的小细节,也是服务端没有大规模用起来的原因。比如用默认的排序、遍历这些,都需要额外的逻辑来处理,所用不所见,所见不所得。

    openresty 将 lua 集成进 Nginx 无疑是非常方便的,开发速度嘎嘎高。曾经需要在 L7 层做加解密逻辑,一天半的时间,从了解 Lua 到代码完成并测试。速度是真的快。

    但是 lua 毕竟是缝合进 Nginx 的,天生就不会 100%完全匹配,再加上 lua 的种种小问题,总有种那着精致的小手枪上战场的赶脚。
    salmon5
        87
    salmon5  
       2022-07-15 18:04:18 +08:00
    b 站和美团、58 技术就查很远,渣渣
    flyqie
        88
    flyqie  
       2022-07-15 18:34:35 +08:00 via Android
    @frostnotfall

    B 站的事跟 lua 没太大关系吧。

    这个应该属于弱语言通病,真打算扯到 lua 的话。。难道说应该直接报错而不是返回 nan ?
    flyqie
        89
    flyqie  
       2022-07-15 18:38:45 +08:00 via Android
    @flyqie

    弱语言 -> 弱类型语言
    frostnotfall
        90
    frostnotfall  
       2022-07-15 19:04:17 +08:00
    @flyqie #88 不好意思,的确看错了,这里是 lua-resty-balancer 的代码不是 lua 的代码,看的时候跑偏了因为前面说是 jit bug 。
    xiangyuecn
        91
    xiangyuecn  
       2022-07-15 19:05:44 +08:00
    跟 弱类型语言 不弱类型语言 的 没有任何关系。该死循环的时候,换什么语言 谁都跑不掉🐶🐶
    Pythoner666666
        92
    Pythoner666666  
       2022-07-15 19:19:17 +08:00
    @mmnnyycc “根源问题是 B 站的业务往 Redis 服务器里写入了个字符串类型的权重 0 值的坏数据(即 “0”)” 这个如果是真的那么说明 写这段代码的人使用 redis 的经验欠缺,因为从 redis 取值 无论是什么数据类型,取出来的值都是 string 。反之这句话就是假的
    evilStart
        93
    evilStart  
       2022-07-15 19:26:27 +08:00 via Android
    @shyrock 啊这,b 站也算大厂啊
    frostnotfall
        94
    frostnotfall  
       2022-07-15 19:30:20 +08:00
    @flyqie #90 但紧接而来的问题就是,lua 函数的实现,没有指定传入参数的类型?
    Ansen
        95
    Ansen  
       2022-07-15 20:09:16 +08:00
    不看 B 站
    jqsl2012
        96
    jqsl2012  
       2022-07-15 20:14:09 +08:00 via Android
    B 站是什么
    HankLu
        97
    HankLu  
       2022-07-15 20:15:12 +08:00
    不要递归不要递归不要递归
    omnip
        98
    omnip  
       2022-07-15 20:55:02 +08:00
    没人注意到最后一句话么:多活的高可用容灾架构确实生效了。 [doge]
    flyqie
        99
    flyqie  
       2022-07-15 21:03:42 +08:00 via Android
    @frostnotfall

    没记错的话,貌似是这样的。

    好像没办法指定类型。
    liuxu
        100
    liuxu  
       2022-07-15 22:00:17 +08:00   ❤️ 2
    代码出的 bug ,老运维来了也没用,哪怕运维能审核代码,lua 这个 nan 的坑该出问题还是的出

    注册中心、自建机房、嫌架构原始的、人员投入不够什么的,这些都是虚的,像 google 、cloudflare 这种不一样该崩还是崩,还有说弱类型语言不行,那强类型语言写的东西不也是 bug 一堆

    这个事故只有一个问题,就是拿到 prof 跑的火焰图却不知道怎么分析导致的后面扯的一堆,递归错误从火焰图来看一定是不断重复调用一个方法,哪怕动态解释型语言也会重复一部分代码,对着反推就行了

    这个事故出了第一件事应该 top 看哪个进程出了问题,第二件事就是 strace 到进程看看输出,卡到哪里了,然后才会 prof 输出和火焰图,最后再不济 gdb 上去分析,也别说什么生产上 gdb 不合规,生产都崩成这样了,任何能有效恢复服务的分析方式都是正确的方式

    看看这报告也说“我们的事件分析平台目前只提供了面向应用的事件查询能力,缺少面向用户、面向平台、面向组件的事件分析能力”,说白了这个事情就是组件底层代码分析能力不够


    这也说明了生产环境添加编译调试信息的重要性,像《高性能 mysql 》里面讲的,给生产环境 mysql 添加调试信息,哪怕增加 20%的 cpu 损耗,但是到了出问题分析的时候,绝对会觉得这 20%花的值
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   985 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 19:58 · PVG 03:58 · LAX 12:58 · JFK 15:58
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.