自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(12)
  • 收藏
  • 关注

原创 看过Disruptor代码之后的一些感想

这两天感冒休息在家。到下午精神渐好,于是继续开始翻看diruptor源代码(http://lmax-exchange.github.com/disruptor/)。目前的版本号还是disruptor-3.0.0-SNAPSHOT。整个diruptor给我的感觉不太像java风格,更像C++。看起来还是挺适应的。不过真的看进去,其中关键代码十分干净,的确写的十分精巧,藏了很多技巧。有些在粗看代码时有

2012-12-13 17:32:42 9288 6

原创 debugfs和blktrace的实验

看了通过blktrace, debugfs分析磁盘IO大作,试图自己搞一把。花了1个多小时,果然能成功地定位到了正写入的文件。觉得有以下几点值得特别说一下:1、用debugfs,无论icheck或ncheck,都非常耗时,并且会产生非常高的disk read。我等了将近有10分钟rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-s

2012-11-21 12:57:15 1690

原创 mac os上配置CDH4.1.1版hbase并启用snappy

这两天乘周末时间在我的mac机器上配置了CDH4.1.1版的hadoop和hbase。hbase配置在伪分布式的hdfs上。整个配置倒也非常简单。使用CDH版hadoop和hbase比用社区版要简单太多了,需要特别配置的东西也少很多。很快我的hdfs和hbase服务都起来了。但当我要创建一个带snappy压缩的opentsdb表时,却发生了错误。regionserver的日志报告,载入native

2012-11-04 15:40:24 2467 2

原创 HDFS写的high CPU之vtune的profile分析解决

公司组里最近有位同事在实现HDFS文件写的时候,发现了high CPU,达200%+。先经jprofile初步定为问题,high CPU共有两个地方。第一个是序列化/反序列化。这个问题看下来,其实是引入了一次本可避免的序列化/反序列化。这个倒是容易解决。第二个地方比较诡异,显示是在BufferedOutputStream.write的native调用上。那位同事后又尝试使用snappy压缩。令人惊

2012-10-30 22:21:09 1965

原创 最近在公司search engine的优化

其实有很多可以写,公司在search engine上做的东西也远不止一下这些。不过下面所列各点很重要,也非常通用。更多的东西,以后再整理了。1. Search engine的优化a. 对于query latency是优化的GC策略,优化设置各代heap的尺寸b. 消除没有必要的匿名类c. 对search engine里的每个queue进行控制和监控d. 针对lucene的mar

2012-10-23 15:47:09 1201

翻译 Zookeeper之Zab协议介绍(五)

B.同因果原子广播的比较 主次序原子广播设计成保持了因果次序特性,并瘾式地在增量状态更新创建时产生。在这一章节,我们将比较因果原子广播和主次序原子广播,并将论证,这两者是无法比较的。 因果次序的定义,是基于事件的前序(precedence, or happens before)关系。对于广播协议,事件分两种,要么是广播事件,要么是采用事件。我们采用  c  ,来表示abcast()

2012-08-21 22:59:24 2963

翻译 Zookeeper之Zab协议介绍(四)

A.     核心特性ZooKeeper要求以下特性来维护所有进程的一致性:完整性:如果某进程采用了的状态变化,那么一定存在一个进程Pi∈П,Pi已经广播过了的状态变化全序性(totalorder):如果某进程在采用之前先采用了,那么任何其他进程在采用时,必须已被采用 这两个特性保证了任何事物不会被自发创建(created spontaneously)或被破坏,并且进程在处理事

2012-08-15 10:27:46 1974

翻译 Zookeeper之Zab协议介绍(三)

问题描述 ZooKeeper采用主备(primary-backup)方案来进行请求,并以主进程次序原子广播(primary order)将状态变化传播到备用进程。因此只有主进程才要广播。如果主进程崩溃,我们认为存在一个外部机制来选择新的主进程。然而,要保证任何时候只存在最多一个主进程并只允许该主进程进行广播是非常重要的。在我们的实现中,主进程选举机制同我们用以消息广播机制是紧密耦合的。假定

2012-08-12 23:03:06 2910

翻译 Zookeeper之Zab协议介绍(二)

系统模型一个Zab系统由一组进程组成II = {p1, p2, ..., pn},每个进程都配有一个稳定的存储设备。进程以一个不停的循环方式进行处理,并通过交换消息方式进行相互通信。分布式情况下,进程可能不断地崩溃,恢复。只要不崩溃,我们认为进程处于up状态,否则就处于down状态。我们假定,最终会有足够多的进程处于up状态,并持续足够长的时间。事实上,只要超过多数的进程处于up状态足够长时间

2012-08-11 08:54:12 3180

翻译 Zookeeper之Zab协议介绍(一)

1. Zab介绍ZooKeeper服务的内部通信,是基于Zab协议,即ZooKeeper Atomic Broadcast协议。原子广播(AB)是分布式计算普遍使用的原语。本质上说,ZooKeeper服务是基于复制分发的。它需要半数以上的服务器能正常工作。崩溃的服务器能恢复并且重新加入集群。ZooKeeper采用主备方式来维护被复制状态的一致性。在ZooKeeper中,leader接受

2012-08-09 23:36:58 12125

原创 ZooKeeper之.net客户端编译

最近公司开始zookeeper的进行开发和应用。由于大量应用、服务都还在使用C#,因此不得为C#用户进行服务。C#客户端编译必不可少。看了一下,C#的zookeeper客户端还是有一些,但成熟的不多。可以考虑以下两个版本:https://github.com/ewhauser/zookeeper/brancheshttps://github.com/ExactTargetDev/zooke

2012-08-09 21:04:31 5110

原创 我的Blog开张啦

Blog 第一篇 

2007-01-26 12:33:00 945

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除