2012-10-24

本周最大的变化是我们team终于有了第三台服务器。我需要用它运行hadoop,虽然硬盘只有100GB,但是有总比没有好。这周的主要工作是做搜索的点击日志分析。在做这些日志分析工作之前,我一直以为统计程序的瓶颈是在IO上,所以就一门心思的学习各种列存储技术、对压缩算法做benchmark等等。但是实际运行的时候发现瓶颈总是在CPU上。对hadoop程序做profiling并非易事,所以我现在主要靠手动使用jstack做抽样,猜测哪些函数是热点。

我最近对linkedin的glu玩的越来越转了。首先是安装脚本这块儿,写多了也就熟了,所以没啥问题了。其次,glu虽然号称有监控的功能,但是实际上glu agent server只提供了一个ScheduledExecutorService罢了,其它什么都没做,全靠你去发挥。从某种角度来看,glu也可以看做是一个分布式计算框架。它的task分为两种,只执行一次的(如install),和定期执行的(ScheduledExecutorService)。那么最简单的监控功能,就是往ScheduledExecutorService扔一个task,定期检测下load、disk usage啥的。整个工作的核心是如何搜集系统信息,可惜,java在搜集操作系统信息方面的功能太弱,应用层利用jmx倒是很方便。所以就看你的监控侧重什么了。

linkedin glu里面用的groovy是1.7.x的,比较老。不仅不支持jdk 7(exception的构造函数不一样多),而且Grape也不大好使。我想用它抓mysql jdbc的jar,没成功。想手动把这个jar包加到当前这个脚本中的classpath中,也没成功。jar包放到~/.groovy/lib目录中,也没成功。最终我放弃了。改成由glu script启动一个bash脚本,这个bash脚本设置classpath并执行一个新的groovy脚本。

glu的static model文件是一个json,我现在深深的觉得在生产环境中这玩意儿绝对不该手写。因为随着机器数增多这玩意儿很快就会膨胀到数千行。所以,glu本身应该只是一个基础框架。各个企业应该写自己的脚本来生成static model文件,然后调用glu console-cli 上传、部署。glu把cli工具做那么完善就是为了便于其他人二次开发。

此博客中的热门博文

少写代码,多读别人写的代码

在windows下使用llvm+clang

tensorflow distributed runtime初窥