export HBASE_HEAPSIZE=16384export HBASE_OFFHEAPSIZE=25gexport HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS -Xmx16g -Xms16g -Xmn4g -Xss256k -XX:MaxPermSize=256m -XX:SurvivorRatio=2 -XX:+UseParNewGC -XX:ParallelGCThreads=12 -XX:+UseConcMarkSweepGC -XX:Paralle

本文借鉴之前HBaseConAsia2017,小米公司对hbase g1 gc的优化分享.此外还可以参考apache官方博客对于hbase g1 gc优化的一篇文章(Tuning G1GC For Your HBase Cluster) g1 gc的优化主要是对一些重要的参数进行调整,然后执行压力测试,分析G1的日志.G1日志处理可以使用HubSpot开发的一个Python工具, 叫做 gc_log_visualizer , 这个工具通过正则提取日志数据, 然后绘制成监控图, 比较方便查看G1的

export HBASE_OPTS="-XX:+UseConcMarkSweepGC" export HBASE_LOG_DIR=/app/hbase/logexport HBASE_PID_DIR=/app/hbase/tmpexport HBASE_HEAPSIZE=16384export HBASE_OFFHEAPSIZE=25g export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS -Xmx16g -Xms16g -Xmn4g -X

在上一篇博客记录了GC的算法及种类,这篇博客主要记录一下GC的参数如何调整以提高jvm的性能. 一.堆的回顾: 堆的内存空间总体分为新生代和老年代,老年代存放的老年对象,新构造的对象分配在eden区中(栈上分配及新生代内存不足的情况除外).在经过GC之后,幸存下来的对象会被分配到幸存代中,s0与s1是两块完全相同的内存区域,采用复制算法,在迭代后交换内存空间.经过若干次GC后,仍然未被回收的对象会被分配到老年代中. 二.GC参数--串行收集器(Serial) 串行收集器有以下几个特点: 1)最古

1. JVM内存管理:深入垃圾收集器与内存分配策略 http://www.iteye.com/topic/802638 Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的高墙,墙外面的人想进去,墙里面的人却想出来. 概述: 说起垃圾收集(Garbage Collection,下文简称GC),大部分人都把这项技术当做Java语言的伴生产物.事实上GC的历史远远比Java来得久远,在1960年诞生于MIT的Lisp是第一门真正使用内存动态分配和垃圾收集技术的语言.当Lisp还在胚胎时期,

转自:http://blog.csdn.net/rzhzhz/article/details/7536285 环境描述 Hadoop 0.20.203.0Hbase 0.90.3Hive 0.80.1 问题描述 前几天,在HIVE执行SQL查询的时候出现了一个很奇怪的问题:就是每个SQL(涉及到MapReduce的SQL任务)在执行到某个百分比的时候,整个JOB会出现假死的情况. 2012-04-28 18:22:33,661 Stage-1 map = 0%, reduce = 0% 2012

GC常用参数 -Xmn -Xms -Xmx -Xss 年轻代 最小堆 最大堆 栈空间, -Xms -Xmx 一般设置成一样大小, -XX:+UseTLAB 使用TLAB,默认打开 -XX:+PrintTLAB 打印TLAB的使用情况 -XX:TLABSize Thread Local Allocation Buffer 设置TLAB大小 -XX:+DisableExplictGC System.gc()不管用 ,FGC -XX:+PrintGC -XX:+PrintGCDetails -XX:+

过去的一年里,我们准备在Ali-HBase上突破这个被普遍认知的痛点,为此进行了深度分析及全面创新的工作,获得了一些比较好的效果.以蚂蚁风控场景为例,HBase的线上young GC时间从120ms减少到15ms,结合阿里巴巴JDK团队提供的利器--AliGC,进一步在实验室压测环境做到了5ms.本文主要介绍我们过去在这方面的一些工作和技术思想. 背景 JVM的GC机制对开发者屏蔽了内存管理的细节,提高了开发效率.说起GC,很多人的第一反应可能是JVM长时间停顿或者FGC导致进程卡死不可服务的情

简介: java启动参数共分为三类: 其一是标准参数(-),所有的JVM实现都必须实现这些参数的功能,而且向后兼容: 其二是非标准参数(-X),默认jvm实现这些参数的功能,但是并不保证所有jvm实现都满足,且不保证向后兼容: 其三是非Stable参数(-XX),此类参数各个jvm实现会有所不同,将来可能会随时取消,需要慎重使用: -XX:+<option> 启用option,例如:-XX:+PrintGCDetails启动打印GC信息的选项,其中+号表示true,开启的意思 -XX:-<

JVM配置参数分为三类参数:跟踪参数.堆分配参数.栈分配参数 这三类参数分别用于跟踪监控JVM状态,分配堆内存以及分配栈内存. 跟踪参数 跟踪参数用户跟踪监控JVM,往往被开发人员用于JVM调优以及故障排查. 1.当发生GC时,打印GC简要信息   使用-XX:+PrintGC或-verbose:gc参数      这两个配置参数效果是一样的,都是在发生GC时打印出简要的信息,例如: public static void main(String[] args) { byte[] bytes =n

Scan是操作Hbase中非常常用的一个操作,虽然前面的Hbase API操作简单的介绍了Scan的操作,但不够详细,由于Scan非常常用,关于其详细的整理也是很有必要的. Scan HBase中的数据表通过划分成一个个的Region来实现数据的分片,每一个Region关联一个RowKey的范围区间,而每一个Region中的数据,按RowKey的字典顺序进行组织. 正是基于这种设计,使得HBase能够轻松应对这类查询:“指定一个RowKey的范围区间,获取该区间的所有记录”, 这类查询在HBas

在用PySpark操作HBase时默认是scan操作,通常情况下我们希望加上rowkey指定范围,即只获取一部分数据参加运算.翻遍了spark的python相关文档,搜遍了google和stackoverflow也没有具体的解决方案.既然java和scala都支持,python肯定也支持的. 翻了一下hbase源码 org.apache.hadoop.hbase.mapreduce.TableInputFormat setConf方法里原来是根据特定的字符串对scan进行配置,那么在Python

https://blog.csdn.net/qq_21383435/article/details/80702205

@ 目录 HBase参数调优 hbase.regionserver.handler.count hbase.hregion.max.filesize hbase.hregion.majorcompaction hbase.hstore.compaction.min hbase.hstore.compaction.max hbase.hstore.blockingStoreFiles hbase.regionserver.global.memstore.size(重) hbase.regionse

本系列的最后一部分是有关垃圾收集(GC)日志的JVM参数.GC日志是一个很重要的工具,它准确记录了每一次的GC的执行时间和执行结果,通过分析GC日志可以优化堆设置和GC设置,或者改进应用程序的对象分配模式. -XX:+PrintGC 参数-XX:+PrintGC(或者-verbose:gc)开启了简单GC日志模式,为每一次新生代(young generation)的GC和每一次的Full GC打印一行信息.下面举例说明: 1 [GC 246656K->243120K(376320K), 0.09

hbase读数据用scan,读数据加速的配置参数为: Scan scan = new Scan(); scan.setCaching(500); // 1 is the default in Scan, which will be bad for MapReduce jobs scan.setCacheBlocks(false); // don't set to true for MR jobs 其中, public Scan setCacheBlocks(boolean cacheBlocks

说到 Java 虚拟机,不得不提的就是 Java 虚拟机的 GC(Garbage Collection)日志.而对于 GC 日志,我们不仅要学会看懂,而且要学会如何设置对应的 GC 日志参数.今天就让我们来学习一下 Java 虚拟机中所有与 GC 日志有关的参数.相信掌握了这些参数之后,对于大家线上打印 GC 日志是有不少帮助的. 为了能够更直观地显示出每个参数的作用,我们将以下面的 Demo 为例子去设置 GC 日志参数. /** * @author 陈树义 * @date 2018.09.2

本文介绍了一次生产环境的JVM GC相关参数的调优过程,通过参数的调整避免了GC卡顿对JAVA服务成功率的影响. 这段时间在整理jvm系列的文章,无意中发现本文,作者思路清晰通过步步分析最终解决问题.我个人特别喜欢这种实战类的内容,经原作者的授权同意,将文章分享于此.原文链接:Java服务GC参数调优案例,下面为转载此文的内容,备注部分为本人添加,主要起到说明的作用. 背景以及遇到的问题 我们的Java HTTP服务属于OLTP类型,对成功率和响应时间的要求比较高,在生产环境中出现偶现的成功率突

link:http://www.51testing.com/?uid-445759-action-viewspace-itemid-812467 并行运行hbase删表,建表操作,多个表多个region,导致hbase挂掉. 查看日志: 从日志中可以看出GC时间过长导致zookeeper连接超时,master退出.(是master退出而不是regionserver退出是因为进行的操作是建表,删表,是由master来进行操作的). 原因: hbase中和GC相关的参数: 修改前(默认): expo

版本:HBase-0.98.6-cdh5.3.6 HBase参数调优 1. zookeeper.session.timeout: 默认90000(毫秒), 控制连接zk的timeout时间.由于hbase的集群是由zk管理的,所以当一个regionserver挂掉的时候,master是从zk集群上得到的,如果该值比较大,那么可能就会有比较高的延时:如果该值比较小,那么当有一个较长时间的gc发生的时候,可能会出现假宕机. 2. dfs.datanode.failed.volumes.tolerat