需求

延长 MongoDB 某集合里的“过期时间”字段。

风险分析

update 一下是很简单，主要怕在 Shell 下操作可能改变数字类型。
先做了实验，发现 3.2 的版本下，并没有这个问题，之前看书，说数字可能被改为双精度，看来是旧版本的不足。

1
2
3
4

db.UMU.find().forEach(function (doc) {
    doc.expireDate = NumberLong(doc.updateTime + 180*24*60*60*1000);
    db.UMU.save(doc);
})

其中 NumberLong 是必要的，不然更新后，expireDate 的类型并不是和 updateTime 一样的 NumberLong。

问题

Ceph 运维发现一个 osd 慢了。

分析

1. 硬件配置对比

找了一台参照机器，上面也一样跑了 15 个 osd，发现 CPU、内存、主板、内存、硬盘的型号都一样，参数也没看出明显差别。但磁盘有点毛病，用 smartctl 看不出通电时长，所以也没有法断定不是磁盘之间的差异。

ProLiant DL380e Gen8

Intel® Xeon® CPU E5-2470 0 @ 2.30GHz

16G DDR3 1333 MHz * 10

2. 排除配置差异

确实找出一个差异来，这个慢的 osd 的磁盘分区和别的 osd 不一样，前面 14 个 osd 的 journal 分区占整个硬盘的比例是 20%，这个慢的 osd 则是 10%。

但后来发现，其它 14 个是普通的 osd，慢的那个是 bucket index osd，所以是故意那样分区的。

3. 发现 mcelog 大了很多

慢盘的 mcelog 比参照机器上的大了 20G，后来确认是很早以前有内存错误打的，不是最近发生。

4. 怀疑内存还是有毛病，毕竟曾经有过毛病

测试逐字节内存填写，结果发现慢盘机器总是比参照机器慢一些，而且浮动比较大，所以怀疑是整机性能不行，并非就那个 bucket index osd 慢，只是 bucket index osd 慢得比较明显。后来，另一名同事确认了这点，15 个 osd 都比参照机器上的 15 个 osd 慢。

5. 在另一名同事的协助下，发现 CPU 降频了……

用 cpufreq-info 查看，发现这个问题机器的 CPU 是 ondemand 模式，降频后，没有及时恢复！后来改为性能模式，问题解决。至于为什么 CPU 不能恢复高频模式，有点怀疑是 pcc-cpufreq.ko 这个 cpufreq_driver 的 bug，但没仔细研究了，直接听取前辈的经验：使用 ondemand 模式，可能导致莫名其妙的问题，而且并不能省多少电，意义不大。

单说 CPU，省电的关键应该是把工作电压降低了，功率下降肯定能省电；只把频率降低（能提高电阻？），效果目测是不会很明显。这个研究不深，欢迎指教。

6. 为什么参照机器没有问题？

两个可能性：

（1）BIOS ROM 版本不一样，参照机器更高：P73 08/20/2012，问题机器：P73 06/01/2012。

（2）BIOS 参数可能也不一样。（服务器不能 IPMI，无法查看……）

《#诗盗#·圣诞绿帽》：冬城懒觉睡眠好，狗皮皱纹迎风悼。绿帽难戴晓寒惊，红耳猪头切克闹。浮生长恨热量少，肯爱千薪轻一笑。为君打开小太阳，或向火边留晚照。

注解

昨晚开电暖器睡眯眯，今早起来还很冷，想着要骑车上班会被冷风吹成狗，心里是拒绝的……
突然看到墙上有一顶帽子，是前几年圣诞节公司发的，可惜是绿色的……算了，还是不要戴，肉体御寒。

《#诗盗#·狗冻》：拖鞋套袜来暴走，风吹手抖冻成狗。穷狗出门包个球，富狗车里挤乳沟。
《#诗盗#·鸡冻》：今晚降温没冷死，明早吓醒有饭吃。夜长有尽梦无穷，日短无妨日一日。

注解

穷人出门就是把自己包成一个球，富人不用靠自身御寒，所以一年四季都可以穿很少，秀身材是分分秒的事情。
御寒手段：吃饱、床上运动。

1. 白洁的故事

现在是 2017 年 12 月 29 日 22 点，哥在西湖边的一个咖啡厅，思考人生。

差点忘记自我介绍，哥叫白洁，呃，男，不是你们想的那个少妇……是一名爱岗敬业的专业运维，日常工作是写脚本，比如这样的：

1

rm -rf /

这样的：

1

python -c 'import os; os.system("".join([chr(ord(i)-1) for i in "sn!.sg! "]))'

还有这样的：

1

dd if=/dev/zero of=/dev/sda

好吧，你们可能看不懂，说人话，哥是一名背锅侠……黑锅可以背，但是绿帽哥是不能戴的，完全无法忍受。

幽绿的灯光映射在田牌笔记本 Logo 上，哥若有所思，咖啡厅的 BGM 很应景地放着：“爱是一道光，如此美妙”，纳尼，还朗朗上口，居然不由自主跟着哼起来！！

但是哥很快陷入深思，快 4 个月前，哥从币特宝公司离职，理由是老板给哥发了一顶绿帽。

这个公司原来是一个游戏公司，2014 年时，游戏业务有很稳定的收入，老板发大财，团队也有些人员空闲出来，于是老板想扩展新业务，选择了当时很火的皮土坯理财，所以后来公司就有两大业务，都很赚钱。

老板也是个蛮年轻的人，脑子转得快，钱也赚得快，但有个毛病——喜欢 PBC……长话短说，哥追了 8 个月的女神，彼此已经默认，周边人也都认同了，快送入洞房时，迅速失败，原因居然是女神被老板砸钱收走了！

哥离职前就暗自发誓要报仇！在新公司上三个月班，业余时都在学习社工和黑客技术，准备选择目前比较敏感和脆弱的皮土坯业务下手，下一个重重的黑手。

打开田牌笔记本，架起美国云主机加蓝灯，用脚本把以前记录的服务器试探了一遍，通过端口开启情况判断，服务器和上面跑的应用都变化不大，但哥早已没有权限登录，实在懊恼！

尝试了几个系统漏洞，都不成功，难道技术还不够硬？一个小时过去了，有点心灰意冷……果然时间就是金钱，想那时，哥拥有所有服务器的最高管理权限，但基于职业道德，并没有故意留下什么后门。苦恼啊！

等等！时间就是金钱！对了，早期哥部署服务器时，曾经架设过一个 NTP 服务器，币特宝公司的所有服务器都会向一系列的 NTP 服务器同步时间，其中就包含了哥架设的那个 gsntp.cc，当时技术总监有亲自审核过同步脚本，大家还开玩笑地说，那个是“高速 NTP”的意思。事实上，大家并没有重视这个事情，gsntp.cc 是哥个人的域名，是在上上家公司就存在的，大约 2010 年到币特宝时，直接给用上了，直到扩展皮土坯业务时，才有人问过，但由于存在历史悠久，没人去怀疑什么。

后来哥的个人云主机到期，没有续费，NTP 服务也失效了，但由于 NTP 服务器列表有好几个，所以第一个失效也没人发现异常。更加天助我也的是，技术总监是个比较抠的人，币特宝公司内部其实也有自己的 NTP 服务器，但他怕服务器负担大，把自己的服务器放在列表的最后，美其名曰保护资源。哥哈哈一笑，用手指托了托墨镜，赫赫，哥没有近视，戴墨镜是为了在咖啡厅装逼，5.2 视力的双眼，紧盯着屏幕，一个计划展开，指令在键盘上咔咔地输入，一个小时后，这个公司将会陷入漩涡。

23:46，由于是周末，这时候有大量玩家，哥在贴吧已经看到大量玩家在骂，更厉害的是皮土坯的贴吧，很多人在怀疑老板是不是要跑路，自己的钱是不是都飞了……还有一个帖子很好玩，自称内部人士，说这公司快倒闭了，因为欠运营商巨款，服务器被强行断网。神助攻啊！以这家公司的尿性，一群人需要至少 3 小时才能处理好故障，而哥已经准备清理一切，喝完最后一滴咖啡，离开。

2. 值班运维小弟的故事

小弟是一名运维，平时的工作主要是看监控图，有这样的……这样的……还有这样的！没错，其实并没有图，都是一些曲线而已。然后简单分析告警原因，如果解决不了就叫人。

放假前夜，他们都出去 high，就小弟们俩在值班，一切风平浪静地有点困，另一个小伙伴嫌无聊，去蹲坑兼抽烟。趁他不在，顺便骂一句：香烟，真基罢臭。小弟想起，以前看某手机大厂创始人接受采访时，居然当众抽起烟来，这素质……有钱也是乐射。

心里正骂得爽时，突然就出事了，各种应用错误飙升的告警，一台台报上来，直到重要的交易服务器也告警了，小弟几乎吓尿，另一枚小伙伴估计正在吓屎……已经 23 点后，大部分人可能都比较难找，只能硬着头皮一个个电话打过去，慢慢地叫来几个人，产品经理、项目管理、开发。

人是来了，但灾难面积还是一直扩大，小弟已经双腿发软，领导也赶来群聊问话。这简直是小弟职业生涯最壮观的一次救灾时间。围观了一个小时，才有人发现时间发生了跃进，跑到 2018 年 2 月，然后再倒退回现在的正常时间。这直接导致各个分布式系统的核心组件崩溃，进而引起所有集群雪崩……

然而为什么会这样呢？却是木有人搞明白。直到一个扫地僧出现，三言两语之后就发现问题根源出在 NTP 同步脚本。小弟真是佩服，佩服。

3. 扫地僧的故事

作为一名扫地僧，修身养性是基本技能，23 点就睡觉比啥修炼方法都简单实用。周末，最多也就晚个一小时。洗澡时，领导连续给贫僧打了 4 个电话，肯定没好事，最后接到的时间是 23:35，果然出大事了。

线上的问题，正常情况下贫僧是不参与的，之前也没有领导半夜打来电话问候，嗯，平时早就关机了，赫赫。总之，贫僧就安静地扫地，宁静以致远。接到电话时，也是懵逼，但领导特别关爱，明显马上开机干活，说不定还能露两手装装逼。

从工作群的聊天记录看，时间曾经发生跳进和倒退，而且是大规模，这只有 NTP 服务器出错才有可能，于是贫僧看了 NTP 同步脚本，里面有个 gsntp.cc 很可疑，好像是“搞死你逃跑，嘻嘻”的意思……What??居然还是放在同步列表的第一位！然后是 asia.pool.ntp.org，最后才是公司自己的……实在无语。另外，为了分散服务器的压力，同步脚本的计划时间还是随机产生的，每小时一次，但分钟数不一样，所以出问题的时间各自不同，但在一小时内大量出事。那为什么时间又迅速自己复原了？坑爹呢！计划任务里居然有两个时间同步！一个是指向刚刚看的脚本，另一个是直接一行命令强行同步 asia.pool.ntp.org。这一切都对上了，那么是不是这个 gsntp.cc 搞的鬼呢？敲了个命令向它查询时间差，结果这个域名指向的根本就不是 NTP 服务器，而且是加拿大的 IP。怀疑有人在这一小时内，开启了 NTP 服务，导致时间错乱后，又迅速关闭。

查一下同步脚本的 log……尼玛，这 log 里面只有一堆的“同步成功”，没有记录同步前后时间！这特么是谁写的！

蛋定，蛋定，这种事情不是第一次遇到，目前只能全线撤除这个时间同步脚本，改天让人精心改造后再上线。这故障已经找不到负责人了，也没有铁一般的证据解释根本原因，但贫僧的第六感认为这一定和三个月前的那个事件有关。于是贫僧宣告：可能是 DNS 被劫持，NTP 服务器列表中有一个被解析到某个时间错误的 NTP 服务器上了。这么离奇的巧合，你们信吗？

4. 吓醒

稣是不信……本故事纯属做梦，如有雷同，请吓醒！

《#诗盗#·悟空》：石台太湿干林涝，河上廿精耳目嘈。山中无事升猴子，羞身养性法力高。

注解

一只石猴升天的故事……
干林涝：干燥的树林水涝了。
廿精：存了二十年的经书。
山中：双关，一是字面意思，二是闽南语里的三藏。
升猴子：三藏没事的时候就喜欢把猴子当风筝升上天。

《#诗盗#·杀马特猿》：一灯大师扫乐射，八核高工保三核。今日不举要买药，明年再买打七折。

注解

杀马特：取其头发五彩缤纷的特征。双关性是开头两个字母倒过来：MS。
猿：谐音，双关性是 Y，一个颜色的英文单词也是 Y 开头。
八核高工：八级员工、核心员工、高级员工。
保三核：保山河

pthread_t 其实是一个结构体指针，里面包含了 TID 和 PID，找出它的偏移量就行。在 Ubuntu 16.04.3 x64 测试通过。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

int get_tid_from_pthread(pthread_t t)
{
	struct pthread_fake {
		void *nothing[90];
		pid_t tid;
	};

	struct pthread_fake* f = (struct pthread_fake*)t;
	return f->tid;
}

int get_pid_from_pthread(pthread_t t)
{
	struct pthread_fake {
		void *nothing[90];
		pid_t tid;
		pid_t pid;
	};

	struct pthread_fake* f = (struct pthread_fake*)t;
	return f->pid;
}

《#诗盗#·翔胺睡道》：通勤之路岛到岛，出岛一堵早造早。睡道屎油烧烧烧。入岛二堵艹艹艹。

注解

翔胺睡道：翔安隧道里面车太堵，都是毒气，闻多了会脑残，一氧化碳中毒。
早造早：早知道就再早点。
屎油：石油烧了有毒烟，臭臭的。

《#诗盗#·上班族焦虑症》：一屎分成两泡拉，一泡切成三段挤，一挤使出三分气，一气蹦出四个屁。

注解

本诗描述了上班族加班后晚起不得不节省拉屎的时间，分成两次拉的惨状，果然是好屎！