November 24, 2016 / Kyle Sun / 0 Comments
昨天听podcast听到的，觉得还蛮好玩，分享一下：
1. Email发不超过500英里的故事
如果你是公司的 IT，有人告诉你公司的 email 只能发送到500英里以内的人，你会是什么反应？你一定觉得这是个大玩笑吧。事实上，故事的主人公也是这么想的，觉得那帮人有毛病。然后他随手一试，从北卡到亚特兰大，没问题。到华盛顿，没问题。到纽约，420英里，没问题。到孟菲斯，600英里，擦，不行了！
最后发现是因为 mail server 在 upgrade 的过程中降级了软件，从而导致软件的配置有稍许不同 — timeout 变成了 0，意味着 3ms timeout，刚好是 500 英里左右的距离！
2. 游戏无法存档的故事
这是一个游戏开发者的苦逼故事。他负责一个存档读档的部分，然后发现有一定的概率在写的时候会出错。读档存档非常重要，于是他调试了好几个月，把 code 剥离到最最基本，却发现还是会出错。后来他突然发现在游戏初始化的时候会设置一个较高的刷新频率，如果他在写档的时候重置一下这个频率就不会出错。他百思不得其解，为什么一个较高的频率会导致出错。直到有一天有个 PM 在看他调试的时候玩了一会儿遥控器，这个时候写档就失败了。他一把把遥控器抢了过来，再次调出程序，写档，玩遥控器，失败，100% 重现。
最后他把这个结果发给了游戏机厂商，还在日本。那边一开始也不信，直到看到了重现的文档，发现是控制元件之间的互相影响。
3. 系统夜间错乱的故事
一个苏联的工程发现他的系统经常挂，白天运行的好好的，晚上就会挂。排查的时候发现每晚都在某一个固定的时刻出问题，而这个时间总是有一趟火车经过。这趟火车不是普通的列车，而是从切尔诺贝利核泄漏站出发的火车，核辐射会对磁盘和内存造成影响以至于每晚准时宕机。而后工程师发现这些火车是运肉的，然后他就立刻离开苏联了。
这让我想到另外一个故事，也是每晚准时宕机的故事。而且当工程师去现场排查的时候，晚上就不宕机了。工程师以为是不是有老鼠，装了一个摄像头，结果发现的真相是搞清洁的阿姨每天晚上会拔掉风扇电源打扫什么的，一段时间之后机箱会过热然后故障。而当有人排查的时候，阿姨就不会拔掉电源了。
July 13, 2015 / Kyle Sun / 0 Comments
其实每个 open source 的玩意儿都会有这个那个的 bug 的，但是这次白白花了一天半的时间，正经活没干，实在是很想吐一个槽。
我们有一个hadoop的机群，最开始是一堆配置低的 pizzabox，每台box有俩 disk，后来加了一些高配置的 beefbox，自从那个之后我们的 cluster 就没有平衡过，亏得于 HDFS-6621 所赐，Balancer 就是一龟速。这也就算了，反正我们也不着急，让他慢慢平衡呗～
然后周四早上，有些 pizzabox 的 disk 就满了，但 cluster 的 utilization 只有不到 50%。我们就怀疑各种 config 问题，比如是不是 dfs.datanode.fsdataset.volume.choosing.policy 设成 Round Robin 啦（之前被咬过），dfs.datanode.available-space-volume-choosing-policy.balanced-space-preference-fraction 是不是没设对，或者 dfs.datanode.du.reserved 是不是设太小了。总之排查了一番没有找出什么问题，就先看看 hdfs 能不能自己把几个 volume 之间 balance 一下，就翻到了这个 HDFS-1312 已经开了5年的 task 到现在还是悬而未决。
好吧，那我们就手动搞一下，参照 Hadoop 的 FAQ，貌似也不复杂，只要把 datanode 关掉，挪一下 subdir 到另一个磁盘同样的文件目录下就好了。我们也就这么做了，datanode 上线之后倒是 ok 了，磁盘多了点空余空间，我们很高兴，于是把其他的有问题的 box 都这么搞了。结果过了不久，我们就注意到磁盘又开始满了，我们心中就一股 WTF…
然后我们又开始一顿排查，又是看源码又是 debug 的，觉得 datanode 没有问题，新 block 也是写到另一个磁盘的。折腾了很久，然后我去比对了一下文件，发现了 dncp_block_verification.log.curr 居然有 1 TB !
所以我们是撞到了这个 HDFS-6114，我们挪了多少 block，丫又会写一堆 scan log 让我们一阵白挪….. 心里真的是万马奔腾…..
想想 Hadoop 也是有 10 年历史了，怎么还能这么不靠谱……..