交流会小结

上周五去北航参加了一个文件系统和存储的交流会,是华为牵头办的,小会议,参会不到30个人。本人水平有限,只能挑一些听懂的留个笔记。


陆游游/

首先是清华大学的陆游游同学讲一个全新设计的基于FLASH存储的文件系统。大概思路是将存储管理和SSD上的FTL合并在一起做成一层,还利用NAND片上每个PAGE的额外存储空间存放一些元数据以在机器断电重启后重新沿链接找回数据(这样就可以不用journal了,似乎也可以认为是把journal放在了PAGE的额外存储空间里),然后在上面架一个新的简化的文件系统做基本的namespace管理。这个思路跟DFS有点像,不过DFS只是上面那一层薄薄的namespace管理,下面就交给Fusionio的firmware了。

华为的谢美伦介绍了手机终端上几种常用文件系统的评测。Android上当然首推ext4,但是后起之秀f2fs更简单且随机写性能不输ext4(这点大家有争论,有人认为这个评测应该写满存储卡再全删掉,再重新测试,也就是要把FTL打乱了再测,会更公正),不过来自阿里云的刘铮表示:google倾向于在服务器和手机上使用统一的文件系统即ext4以方便维护。看来f2fs虽然更贴合NAND,但是大厂支持上还不够丰富。

来自百度的杨勇强介绍了百度的分布式存储和文件系统。这个,互联网的玩法太相似了,主从结构,erasure code,就不累述了。讲到中途的时候,来自华为存储部门的几个工程师问了很多分布式环境下锁的问题,发现互联网由于应用和底层都是自己写,所以可以玩很多花招,比如一个文件只允许一个写进程操作等等,而且,互联网公司不怕内核panic,反正是负载均衡,宕机一台重启就可以了,所以对底层软件的稳定性也没有太多要求。他们深感做企业存储不得不高效的实现整个POSIX,比互联网的分布式存储难做多了。也有工程师向百度提问为什么用ARM服务器?真的那么需要省电吗?百度的谢广军回答说省电是必要的,一台两路服务器光xeon CPU耗电就到了85瓦,换成ARM变成几瓦,还是挺明显的。

最后由来自华为的程菊生博士介绍已经广泛宣传的OceanStore 9000,最大40PB的存储集群。我们几个人马上提问:用的是以太网还是Infiniband?答曰Infiniband,大家相视而笑,这年头,高端一点的企业存储不用Infiniband根本不行,延时降不下来啊。OceanStore 9000里既有硬盘也有SSD,SSD用来做自动分层的缓存层(这大概是为了成本),其中硬盘用RAID 2.0的方式组织,以加快坏盘后的数据恢复速度。


交流会/

纯个人感受,做存储(泛泛而谈,不专指企业存储),底层和架构就是那些,Infiniband啊,主从结构啊,RAID啊,双控啊,各家的都差不太多。就看怎么拼在一起,怎么处理一系列细节问题了,换句话说,看的是各家的节操 :)

自修DELL笔记本

家里有个DELL e6400的笔记本,最近用起来感觉越来越发烫,而且长时间浏览网页或干活儿后,就频频死机。一开始以为是今年夏天温度太高,于是把塑料瓶装上自来水冻成冰块,放到笔记本的背后降温。


dell笔记本

后来在 @唐僧_huangliang 的提醒下,仔细听了听散热口,确实一点风扇的声音都听不到。于是打开笔记本,才发现虽然里面的配件还很新,但是散热口的内侧已经堆积了厚厚的一层油灰,于是赶紧清除之。装好后重新开机,还是听不到风扇声,于是到DELL官网上下了个BIOS的更新程序,安装后提示要重启,重启后终于听到了轻微的风扇声。这次笔记本的后背不烫了,看来把热量从里往外吹是比较高效的,这么点风声就可以保持本子不升温了,都不用敷冰块了。

去哪儿

部门这几天在投票选六月份outing的地点,很多同事选了“泰国清迈”。

coly:咋那么多人选泰国啊!最近泰国这么乱,我又这把年纪了,万一穿着黄衬衫到泰国,被红衫军以为是黄衫军,痛打一顿,一身的血,结果又被黄衫军以为是红衫军,又被痛打....

我回到家,把消息告诉了家人,家里人也觉得泰国最近不太平。吃饭,看电视,正好新闻里演泰国的局势,里面大大的标题“泰国,去向何方?”

妈:你看,泰国自己都不知道该去哪儿,你们还去那儿干嘛?

追踪CPU跑满

最近测试一个应用遇到问题:一旦压力略涨,应用的CPU就顶满。由于是多线程应用,直接就把系统的CPU耗完了。
本来想用gdb來调试的,结果gdb不给力,就在attach那里卡死,半天不动。后来想到了用perf来调试,果然找到了一处性能热点。修复热点以后,CPU顶满的问题缓解了一些,不太容易出现了,但是,多跑一会儿,还是会有。而且现在出现CPU顶满时,不仅gdb不返回,连perf record -a -g都无法用Ctrl+c来停止了,仔细top命令看了一下,原来系统的sys是100%,usr几乎为0%,也就是说,是卡在内核里了,难怪perf不好使。
perf这样的神器都用不了了,还能怎么办?最后@coly提醒我:用 echo t > /proc/sysrq-trigger 把内核栈整个打出来。好办法,我试了一下,dmesg里一堆信息:

Apr 25 22:37:57 v3 kernel: sheep         R  running task        0 19157      1 0x10000080
Apr 25 22:37:57 v3 kernel: ffff8802b41c5418 0000000000000086 ffff88028761ecc0 ffffea0008b0f478
Apr 25 22:37:57 v3 kernel: ffffffff814ef33e ffff88046ff9b588 ffffea0008b0f478 ffffea0008b0f478
Apr 25 22:37:57 v3 kernel: ffff8803ec6ab0f8 ffff8802b41c5fd8 000000000000f4e8 ffff8803ec6ab100
Apr 25 22:37:57 v3 kernel: Call Trace:
Apr 25 22:37:57 v3 kernel: [] ? _spin_lock+0x1e/0x30
Apr 25 22:37:57 v3 kernel: [] ? __lru_cache_add+0x40/0x90
Apr 25 22:37:57 v3 kernel: [] __cond_resched+0x2a/0x40
Apr 25 22:37:57 v3 kernel: [] _cond_resched+0x30/0x40
Apr 25 22:37:57 v3 kernel: [] migrate_pages+0x9d/0x4b0
Apr 25 22:37:57 v3 kernel: [] ? compaction_alloc+0x0/0x3e0
Apr 25 22:37:57 v3 kernel: [] compact_zone+0x4f4/0x770
Apr 25 22:37:57 v3 kernel: [] compact_zone_order+0xa1/0xe0
Apr 25 22:37:57 v3 kernel: [] try_to_compact_pages+0x11c/0x190
Apr 25 22:37:57 v3 kernel: [] ? native_sched_clock+0x13/0x60
Apr 25 22:37:57 v3 kernel: [] __alloc_pages_nodemask+0x5f5/0x940
Apr 25 22:37:57 v3 kernel: [] alloc_pages_vma+0x9a/0x150
Apr 25 22:37:57 v3 kernel: [] do_huge_pmd_anonymous_page+0x145/0x370
Apr 25 22:37:57 v3 kernel: [] handle_mm_fault+0x25a/0x2b0
Apr 25 22:37:57 v3 kernel: [] ? mempool_alloc+0x63/0x140
Apr 25 22:37:57 v3 kernel: [] __get_user_pages+0x12a/0x430
Apr 25 22:37:57 v3 kernel: [] ? rwsem_down_read_failed+0x26/0x30
Apr 25 22:37:57 v3 kernel: [] get_user_pages+0x49/0x50
Apr 25 22:37:57 v3 kernel: [] get_user_pages_fast+0x157/0x1c0
......
Apr 25 22:37:57 v3 kernel: sheep         D ffff88047fc24900     0 19158      1 0x10000080
Apr 25 22:37:57 v3 kernel: ffff880357da9890 0000000000000086 0000000000000000 0000000000000003
Apr 25 22:37:57 v3 kernel: ffff8804700e6ea0 ffff880357da9878 ffffffff812518e2 ffff880357da0000
Apr 25 22:37:57 v3 kernel: ffff8803ec6aa6b8 ffff880357da9fd8 000000000000f4e8 ffff8803ec6aa6b8
Apr 25 22:37:57 v3 kernel: Call Trace:
Apr 25 22:37:57 v3 kernel: [] ? __make_request+0x122/0x5a0
Apr 25 22:37:57 v3 kernel: [] rwsem_down_failed_common+0x95/0x1d0
Apr 25 22:37:57 v3 kernel: [] ? mempool_alloc_slab+0x15/0x20
Apr 25 22:37:57 v3 kernel: [] ? mempool_alloc+0x63/0x140
Apr 25 22:37:57 v3 kernel: [] rwsem_down_read_failed+0x26/0x30
Apr 25 22:37:57 v3 kernel: [] call_rwsem_down_read_failed+0x14/0x30
Apr 25 22:37:57 v3 kernel: [] ? down_read+0x24/0x30
Apr 25 22:37:57 v3 kernel: [] get_user_pages_fast+0x124/0x1c0
......

看到了"lock"、“mutex”这些字眼,果然是内核里面卡住了,@coly一看到compact_zone()就明确告诉我,是hugepages的问题,把它关掉试试。用

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
echo no > /sys/kernel/mm/redhat_transparent_hugepage/khugepaged/defrag

关掉,应用果然一切正常了。原来以前在hadoop集群上也遇到过类似的问题(所以现在alikernel是默认关掉transparent hugepaes的),不过当时只是CPU略涨,不像现在这个,干脆锁死了。
原来除了gdb,valgrind,perf,还有“echo t > /proc/sysrq-trigger"这样更犀利的办法,@coly告诉我,还有更犀利的,就是连sysrq-trigger都不好使了,可以看
/proc/{pid}/wchan,里面是该进程阻塞位置的内核函数名,在所有办法都没戏的时候可以看它。
学习了。

小记备份遭遇

今天备份机器上的一个目录,用“du -sh .”看这个目录只占用了1.5G空间。但是,我一用tar打包,就半天停不下来,tar包都涨到十几G了还没有打包完。奇怪,哪多出来这么多东西。
查了半天,后来发现目录里有个101G的大文件,而du -sh 对这个大文件的返回结果却是”1.1M“,喔,原来这是个空洞文件,tar却只能老老实实的读数据,所以出来的tar包巨大无比。看来,备份目录前光"du -sh .“是不够的,至少还得类似"find . -size +100M"全部检查一遍大小才行。

1 2 3 13