Fire_Balrog
- 浏览: 19567 次
- 性别:
- 来自: 广州
-
最新评论
文章列表
今天看了UNIX编程艺术的第12章——优化。
其中讲到吞吐量和延迟的问题，深有体会。
之前曾经做过相关的优化，结果过于看重吞吐量的上升而忽略了延迟，
最后也引起了很多问题。
摘抄如下：
"过早优化乃万恶之源。"
“有三种常规的策略来减少时延，(a)对可以共享启动开销的事务进行批处理，(b)允许事务重复，和(c)缓存。”
好久没更新了，随便写写。
最近在搞一个调度器的扩展功能，用了类似插件的方法实现。
好处就是不需要重启应用就可以将功能应用起来，并且可以通过配置数据文件的方式来改变实际操作流程。
按照UNIX编程艺术中讲的，就是数据驱动的一种实现方式；
数据不仅仅是某个对象的状态，实际上还定义了程序的控制流。
详细的有空以后在补充。
之前看了一篇描述神奇sqrt函数的文章，因此很好奇java是怎么实现sqrt的。
然后闲的无聊跟踪了一下Math.sqrt的调用，发现
public static double sqrt(double a) {
return StrictMath.sqrt(a);
}
然后：
在StrictMath里
public static native double sqrt(double a);
说明sqrt是一个native的实现。
从StrictMath的类说明中可以得知，这是调用了一个
Freely Distri ...
来源于源码阅读笔记。
前提：
• 机器故障是常态
• 文件不能丢失
• 需要对文件进行冗余的拷贝备份
思路：
• 不足拷贝数的：及时复制
• 超过拷贝数的：删除多余的
使用svn时，有时候需要对文件执行chmod +x操作
但是实际上，chmod后再check in无法改变文件属性
查看svn的手册得知svn还有propset的操作
因此操作chmod的方法变为：
svn propset svn:executable ON [filename]
之后再执行svn ci即可
相关的可操作的属性还有以下几种
svn:ignore
svn:keywords
svn:executable
svn:eol-style
svn:mime-type
svn:externals
svn:needs-lock
在linux下经常需要一些自动化执行的脚本，
有可能需要用到某些要求人工输入确认的地方
（如rm之类的操作）
expect是较为方便的一个工具
但是若过度使用expect，有可能对某些并不需要输入确认的操作也进行expect，
从而导致相应的输出被expect吞没
因此需要对expect的操作进行具体的判断
并且设置合适的超时时间
一旦expect结束，马上interact将控制权交回
set timeout 100
eval spawn $input $argv
if {$argc >= 2} {
set cmd [lindex $argv 1]
if {$c ...
最近在对HDFS对DistribuitedFileSystem进行改造，目标是实现一个自己定制的DFS。
显而易见，大概会有以下几种构思：
一是完全实现一个新的DFS，显然难度也太大，也等于是自己在重造车轮，显然不靠谱；
二是修改现有的DFS，在其 ...
同样，本文也仅仅是个人笔记
前段时间在做与Hive相关的工作，于是简单整理一下Hive交互的过程吧。
一、解析部分
1.系统建立jvm，利用反射机制运行Hive
2.CliDriver.main 解析cmdline的主程序，将有‘;'的输入分割组合成一句完整的sql
3.CliDriver.processLine 分析运行一句sql
4.CliDriver.processCmd
5.compile 判断合法性，并且生成一个ASTNode对象以及一个QueryPlan对象
6.利用SematicAnalyzer，从plan对象中获取语法分析结果，并且将其一个一个put入run ...
本文仅仅是个人读书笔记，不一定具参考价值
对于高可用性的Hadoop集群而言，应该尽量提高集群的可服务时间。
但是由于某些不可避免的原因，集群有时候需要进行重启，因此重启的时间成为关键问题。
而其中namenode的重启则是最为耗时的一个环节，namenode需要处理所有datanode的block report，
一旦节点数目变多，这个处理的过程会变得很慢。所以可以在这个部分加以改进。
近日在jira上看到一个issue
https://issues.apache.org/jira/browse/HDFS-1295
这个issue正是用于提高namenode的重启速度 ...
这周发现sort的一个问题，直接使用的时候居然不按ASCII排序。。。
查了一下，需要这样设置
export LC_CTYPE=en_US.ascii
实际上
LC_CTYPE determines the locale for interpretation of sequences of bytes of text data as characters
今天在遇到个问题，如何在callee中获取caller的信息？
搜索了一下，java提供一种如下的方法：
StackTraceElement stack[] = (new Throwable()).getStackTrace();
即可获得相应的调用栈中的信息。
方法其实类似new 一个Exception ，然后printStackTrace.......
但是有大牛说这是一个不精确的方法，java并未保证可以获取caller信息的完整；
查阅了Java文档说明：
getStackTrace
public StackTraceElement[ ...
借着开会的机会，去北京出差玩了两天，见到了若干大佬，真实令人感慨。
国内做hadoop的公司还是很多的，大家的问题和解决方法也殊途同归。
印象比较深刻的就是fb公司，无论是raid压缩，scheduler的改进，namenode的热备，都是目前工作中切切实实遇到都问题，具有重大的参考价值。
至于具体的细节，以后慢慢研究再记下吧。