HBase源分析.docVIP

hbase性能测试小结 测试环境： 机器：1 client 5 regin server 1 master 3 zookeeper 配置：8 core超到16 /24G内存，region server分配了4G heap /单seta磁盘,raid10后500GB 系统：Red Hat Enterprise Linux Server release 5.4 版本：hadoop-0.20.2+737 / hbase-0.90.1 / Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode) htable假设：row key = 200 Byte；row value=1k Byte；1 family 1 column 前期主要测试了读写性能，非常满意。可以跑满网卡。 接下来进行了一些持续压力测试，下面是测试的一些结论 1 master启动时会读取和恢复所有hlog，这一步的工作是读取所有hlog放在内存中。在集群比较大写入比较频繁时需要配置较大内存 2 dns配置必须保证一致，在启动时dns解析不一致，运行不会报错，但是balance和recovery时会产生很大的问题，因为master无法准确地判断region server的状态。这个问题非常严重 3 LRU引起的性能消耗非常大，因为一旦内存不能命中，则需要从网络上其它主机请求数据，性能的下降是一到两个数量级。因此需要严格计算内存的使用情况，默认的计算公式是heap of regionserver * 0.2 * 0.85，其中0.2那个因子是可以配置的，建议配置到0.4-0.5 4 update时会引起读写锁互斥，目前测试可以得到互斥会引起读的性能下降一倍。当然对写是无影响的。insert也不会有影响 5 balancer将定期检查，默认是5分钟。balance主要将平衡各台机器的总region数量，有三种平衡算法，效果都差不多，由于balance时会改变region对应的server的信息，因此会有短暂的服务不可用时间，抛出NotServingRegion异常。该异常在客户端进行处理，目前默认的处理办法是阻塞。经压力测试得到balance时的region不可用时间为20ms以内，6小时内balance次数约12次 6 balancer不会以table为粒度进行工作。这会导致如果一张表的row key长期没有发生变化，则数据有可能倾斜在某个region server上 7 compact时虽然复杂，但几乎不会阻塞读写，因为region的状态并没有改变，而只是生成了一个新的store file再做一次rename操作，只在rename时会加一个写锁，但是很快解锁。在平均3500qps写入的压力测试中统计了3个小时内某个region server中的compact次数为195次，其中40次1s，110次1-2s，32次2-3s，10次3-4s，1次4s，1次7s 8 split耗时在10ms级别，对访问正在split的region的请求抛出NotServingRegion异常 hbase 源码解析之master篇1 master启动过程： ? --首先初始化HMaster --创建一个rpcServer，其中并启动 --启动一个Listener线程，功能是监听client的请求，将请求放入nio请求队列，逻辑如下： --创建n个selector，和一个n个线程的readpool，n由ipc.server.read.threadpool.size决定，默认为10 --读取每个请求的头和内容，将内容放入priorityQueue中 --启动一个Responder线程，功能是将响应队列里的数据写给各个client的connection通道，逻辑如下： --创建nio selector --默认超时时间为15 mins --依次将responseQueue中的内容写回各通道，并关闭连接 --buffer=8k(代码写死) --如果该请求的返回没有写完，则放回队列头，推迟再发送 --对于超时未完成的响应，丢弃并关闭相应连接 --启动N(n默认为10)个Handler线程,功能是处理请求队列，并将结果写到响应队列 --读取priorityQueue中的call，调用对应的call方法获得value，写回out并调用doRespond方法，处理该请求，并唤醒writable　selector --启动M(m默认为0)个Handler线程以处理priority --注册zookeeper watcher ? --bloc