Embed Size (px)
Citation preview
Hbase 运维碎碎念
1. 这是一个读书笔记，可能有大量的理解错误2. 最后的参考文档比这个 ppt 更有价值3. 后续对 Hbase 有更多的理解，随时会更新 ppt4. 你需要有基本的 java 概念和基本的 Hbase 概念
Hbase 运维碎碎念Agenda
1. JAVA2. HDFS3. HBase
Hbase 运维碎碎念tmpwatch
运行一段时间后，发现 jps 无法列举 java 进程了，崩溃。。。
Why ？
Java 需要将 pid 信息写入到 /tmp/hsperfdata_username
tmpwatch 定期清理 /tmp
修改 sudo vi /tmp/cron.daily/tmpwatch/usr/sbin/tmpwatch “$flags” -x /tmp/hsperfdata_* …
Hbase 运维碎碎念JVM Heap
图片出处：http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
Hbase 运维碎碎念JVM Heap
简单来说， Heap 分为年轻代 (Young)/ 年老代 (Old/ Tenured)/ 持久代 (Perm)
-Xms: Heap 初始尺寸-Xmx: Heap 最大尺寸-Xmn: 年轻代尺寸-XX:NewRatio: 设置 Young 与 Old 的大小比例， -server 时默认为 1:2-XX:SurvivorRatio: 设置 Eden 与 Survivor 的比例，默认为 32 。-XX:MaxPermSize ： 持久代大小，默认 64M 。-XX:NewSize ： 年轻代大小-XX:MaxNewSize: 年轻代最大尺寸-Xss: 每个线程的 stack 尺寸
-XX:MinHeapFreeRatio ：空余堆内存小于 40% 时， JVM 就会增大堆。 -XX:MaxHeapFreeRatio ：空余堆内存大于 70% 时， JVM 会减少堆。
Hbase 运维碎碎念JVM Heap
年轻代分为 Eden ， Survior 1 ， Survior2
新对象在 Eden 区分配内存。
GC 时，将 Eden 和有对象的 Survior 区 (From Space) 的所有对象复制到另外一个 Survior(To Space) ，然后清空 Eden 和原 Sruvior 。
当一个对象在 from 和 to 之间复制的次数超过一定阀值 (-XX:MaxTenuringThreshold) 后，进入到年老代。如果是 CMS GC ，这个阀值默认为 0 ，也就是经过一次 copy 后就进入年老代。 -XX:+PrintTenuringDistribution 可以查看详细统计信息。
持久代不 GC ，除非 CMS GC 且显式设置 XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled
Hbase 运维碎碎念JVM GC
GC 分为对 Young 的 GC （ minor ）和同时对 Young 和 Old 的 GC（ Major ）
1. Serial GC ，单线程 GC ，适合小 Heap 单 CPU 。 -XX:+UseSerialGC
2. Parallel GC ，也称 Throughput GC 。与第一种 GC 不同在于Young 区是多线程的，但 Old 区仍然单线程。 -XX:+UseParallelGC 。 Java 6.0 已经支持 Old 区并行 GC ： -XX:+UseParallelOldGC 。 GC 的线程数可以通过 -XX:ParallelGCThreads=<N> 调整。通过 -XX:MaxGCPauseMillis=<N> 可以提示最大 GC 暂停时间，设置此参数会导致 JVM 自动调整 Heap 大小和一些 JVM 相关参数，慎用。
3. Concurrent GC ，也称 CMS GC ，可以在 Old 区的回收同时，运行应用程序。 -XX:+UseConcMarkSweepGC 参数启动该 GC 。该GC 还可以开启增量模式 -XX:+CMSIncrementalMode
Hbase 运维碎碎念JVM GC
Concurrent GC
1. 暂停所有线程，标记活跃对象的 root ，然后恢复线程访问2. 使用一个或者多个 CPU 标记所有活跃对象，应用线程访问不受
影响。3. 使用一个 CPU 标记第 2 步过程中有修改的对象。4. 暂停所有线程，标记前面 2 ， 3 步过程中有修改的对象，然后
恢复线程访问。5. 使用一个 CPU ，并发的将非活跃对象清除，内存释放给 free
list 。6. 使用一个 CPU ，并发的重整 heap 大小，并准备下一轮 GC 需
要的数据结构。
Hbase 运维碎碎念JVM GC
Concurrent GC
并发 GC 更消耗 CPU ，假如有 N 个 CPU ， GC 可使用 1 <= K <= ceil(N/4) 。
并发 GC 可能造成 Heap 碎片， Cloudera 推出了 MemStore-Local Allocation Buffers 特性来改善碎片问题。
如果并发 GC 进行中，有新对象要进入年老代会导致 Concurrent Mode Failure ，此时只能 stop the world ，改用串行 Full GC 。
如果新的对象要进入年老代，但年老代没有足够大小的连续空间，会导致Promotion Failuer ，此时只能 stop the world ，进行 Full GC
-XX:CMSInitiatingOccupancyFraction=<N> 可以控制启动 CMC GC 的阀值，N 表示年老代的大小百分比。如果 Concurrent Mode Failure 频繁出现，可以考虑降低其值。
Hbase 运维碎碎念JVM GC
不管哪种 GC，年轻代的 GC都会阻塞线程。推荐年轻代使用Parallel New GC，年老代使用 CMS GC-XX:+UseParNewGC –XX:+UseConcMarkSweepGC
禁止程序显式 GC-XX:+DisableExplicitGC
打印 GC Log-verbose:gc -Xloggc:filename -XX:+PrintGCDetails -XX:
+PrintGCTimeStamps打印年老代 FreeListSpace 的状态 -XX:PrintFLSStatistics=1打印 CMS 的信息-XX:PrintCMSStatistics=1
Hbase 运维碎碎念NUMA
从 JDK6u2 开始，增加了 -XX:+UseNUMA ，在 UseParallelGC时， JVM 会将年轻代根据节点数切分为不同的 pool 。
cat /sys/devices/system/node/node0/meminfoNode 0 MemTotal: 12382196 kBNode 0 MemFree: 9739412 kBNode 0 MemUsed: 2642784 kBNode 0 Active: 1805868 kBNode 0 Inactive: 548076 kBNode 0 HighTotal: 0 kBNode 0 HighFree: 0 kBNode 0 LowTotal: 12382196 kBNode 0 LowFree: 9739412 kBNode 0 Dirty: 396 kBNode 0 Writeback: 0 kBNode 0 FilePages: 1765192 kBNode 0 Mapped: 23236 kBNode 0 AnonPages: 589204 kBNode 0 PageTables: 3672 kBNode 0 NFS_Unstable: 0 kBNode 0 Bounce: 0 kBNode 0 Slab: 141612 kBNode 0 HugePages_Total: 0Node 0 HugePages_Free: 0
Hbase 运维碎碎念NUMA
$ numastat node0 node1numa_hit 1675519925 1659271911numa_miss 0 0numa_foreign 0 0interleave_hit 110847 112840local_node 1675317828 1658259635other_node 202097 1012276
Hbase 运维碎碎念NUMA
图片出处： http://blogs.oracle.com/jonthecollector/entry/help_for_the_numa_weary
Hbase 运维碎碎念NUMA
关闭 NUMA ？
vi /etc/grub.conf…Title Red Hat Enterprise Linux Server (2.6.18-164.el5)
root (hd0,0)kernel /vmlinuz-2.6.18-164.el5 ro root=LABEL=/
numa=off console=tty0 console=ttyS1,115200 initrd /initrd-2.6.18-164.el5.img
Hbase 运维碎碎念Large Page
OS 设置假设使用 2G 的大页面内存（ 2M页面）echo 1000 > /proc/sys/vm/nr_hugepagesecho 2147483647 > /proc/sys/kernel/shmmax
JVM 设置-XX:+UseLargePages
-Xmx 整个 JVM Heap必须全部使用大页内存，或者全部不用。
Hbase 运维碎碎念Agenda
1. JAVA2. HDFS3. HBase
Hbase 运维碎碎念ulimit
sudo vi /etc/security/limits.conf* soft nproc 65536* hard nproc 65536* soft nofile 65536* hard nofile 65536
Swap
echo 0 > /proc/sys/vm/swappiness
Hbase 运维碎碎念Sync
Apache官方版本的 0.20.x 不支持 sync （ hflush ），有较大存在数据丢失的可能性。
如果作为 Hbase 的存储，需要使用 CDH3版本或者自行编译Hadoop branch-0.20-append分支。
官方版本的 HDFS 只有在文件关闭后才能确保数据不丢失，如采用官方，可考虑加快 Hlog 的切换（ hbase.regionserver.logroll.period ），以尽量减少 WAL日志的丢失，但会影响性能：1. 产生更多的小文件，影响 NameNode 的管理效率2. 更频繁的 flush ， Hlog 超过一定数量（默认 32 ）后会触发所有
memstore 的 flush ，影响 regionserver 的效率
Hbase 运维碎碎念NameNode
NameNode目前的版本是单点，主要保存两类数据：
1. Namespace通过 Fsimage 和 Editlog 持久化到硬盘
2. BlocksMap纯内存三元组结构，重启后需要 datanode做 blockreport 重构
NameNode容灾需要确保 Fsimage 和 Editlog 写两份（通过 NFS ）
NameNode 重启的时间取决于 Editlog 的 Apply 时间和 BlockReport 的时间。
Hbase 运维碎碎念Safemode
dfs.safemode.threshold.pct默认 0.999 ，也就是 blockreport阶段 NN 需要收到 99.9% 的 block的 report 信息才能退出安全模式
dfs.safemode.min.datanodes退出 safemode 前存活的最小 DN 数，默认 0 ，不限制
dfs.safemode.extension 达到阀值以后等待默认 30000毫秒后才正式退出安全模式
手工进入 safemode$hadoop dfsadmin -safemode enter
手工退出 safemode hadoop dfsadmin -safemode leave
Hbase 运维碎碎念DataNode
dfs.datanode.max.xcievers默认 256 ，建议至少 4096+ ，太小可能导致频繁报错： hdfs.DFSClient: Could not obtain block blk_XXXXXXXXXXXXXXXXXXXXXX_YYYYYYYY from any node: java.io.IOException: No live nodes contain current block.
Hbase 运维碎碎念监控 Metrics
Metrics 可以写到 Ganglia ，或者本地文件vi hadoop-metrics.properties#dfs.class=org.apache.hadoop.metrics.file.FileContextdfs.class=org.apache.hadoop.hbase.metrics.file.TimeStampingFileContextdfs.period=10dfs.fileName=/tmp/dfsmetrics.logdfs.class=org.apache.hadoop.metrics.ganglia.GangliaContext31dfs.period=10dfs.servers=localhost:8649
注： Hadoop 的 FileContext 没有记录 timestamp ，建议使用 Hbase 的TimeStampingFileContext
Hbase 运维碎碎念监控 Metrics
Metrics 也可以同时写到 Ganglia 和本地文件
dfs.class=org.apache.hadoop.metrics.spi.CompositeContextdfs.arity=2dfs.period=10dfs.sub1.class=org.apache.hadoop.hbase.metrics.file.TimeStampingFileContextdfs.fileName=/tmp/metrics_hbase.logdfs.sub2.class=org.apache.hadoop.metrics.ganglia.GangliaContext31dfs.servers=localhost:8649
Hbase 运维碎碎念Agenda
1. JAVA2. HDFS3. HBase
Hbase 运维碎碎念Flush/Compaction/Split
CompactSplitThread.javalock.lock();try { if(!this.server.isStopped()) { // Don't interrupt us while we are working byte [] midKey = r.compactStores(); if (r.getLastCompactInfo() != null) { // compaction aborted? this.server.getMetrics().addCompaction(r.getLastCompactInfo()); } if (shouldSplitRegion() && midKey != null && !this.server.isStopped()) { split(r, midKey); } } } finally { lock.unlock();}
Hbase 运维碎碎念Flush/Compaction/Split
hbase.hregion.memstore.flush.size默认 64M ，当一个 region 中所有 MemStore总大小超过 64M 时，开始 Flush 。
hbase.hregion.max.filesize默认 256M ，当一个 StoreFile 超过 256M 时，会启动 split 分裂为两个 daughter region ，分裂只是创建两个 reference ，不复制数据。
hbase.hregion.memstore.block.multiplier默认 2 ，当一个 region 所有 memstore 之和超过hbase.hregion.memstore.flush.size （默认 64M ）大小的 2倍时，会强制阻塞写刷到磁盘。
Hbase 运维碎碎念Flush/Compaction/Split
hbase.regionserver.regionSplitLimit如果在线的 region 超过此数目，则不再 split ，默认int.MAX_VALUE(2147483647) ，设为 1即可关闭自动 split 。
hbase.hstore.compactionThreshold默认 3 ，当一个 store 中的 storefile 超时 3 个时，触发 compact 。所以，将此值设置为 int.MAX_VALUE 可关闭自动 compact 。
hbase.hstore.blockingStoreFiles默认 7 ，当 region 中任一个 store 中的 storefile 超过 7 个时，会触发的compact ，在 compact完成之前， flush 会延迟执行。如果此时更新较多，导致该region 的 memstore 之和超过 hbase.hregion.memstore.flush.size*hbase.hregion.memstore.block.multiplier ，则会阻塞更新，直到 Flush完成，或者 hbase.hstore.blockingWaitTime （默认 90s ）超时，建议加大该值。
Hbase 运维碎碎念Flush/Compaction/Split
hbase.regionserver.maxlogs默认 32 ，当 Hlog 的数量超过 32 个时会造成 flush 所有的 region ，不管它的memstore 是否满。
hbase.regionserver.global.memstore.upperLimit默认 0.4 ，表示 region server上所有的 memstore占用的内存总和最多为MaxHeap 的 40% ，超过则会加锁刷磁盘，一直要等到某个 memstore刷到磁盘，且 memstore总和下去了，才会继续， Flush 是串行操作，所以对 memstore 多或写非常频繁的场景要特别注意。
hbase.regionserver.global.memstore.lowerLimit默认 0.35 ，当所有 MemStore 的大小超过 MaxHeap 的 35% 时，开始持续Flush ，以尽量避免到 upperLimit 导致锁。
Hbase 运维碎碎念Minor Compaction
Minor Compaction 只合并 StoreFile ，不清理历史版本和删除记录
hbase.hstore.compaction.max默认 10 ，一次 minor compaction 最多只处理 10 个 StoreFile
Hbase 运维碎碎念Major Compaction
Major Compaction 合并所有 StoreFile ，清理历史版本和删除记录
hbase.hregion.majorcompaction默认 86400000 毫秒 =1天，同一个 region两次 major compaction操作的时间间隔。
如果一次 minor compaction选中的 StoreFile 是这个 region 的所有StoreFile ， minor compaction 会自动升级为 major compaction
手工触发：$hbase shellhbase(main):015:0> compact 'test'0 row(s) in 0.2220 secondshbase(main):016:0> major_compact 'test'0 row(s) in 0.3240 seconds
So ，如果没有 delete ， major compaction 可以不用太频繁的执行。
Hbase 运维碎碎念Column Family
每个 CF都有一套MemStore+StoreFiless
但是同一个 table 的所有 CF 的 MemStore都会在同一时间 Flush （未来或许会改善），会在同一时间 split ，
从写的角度看，一个 table 最好不要设计太多的 CF ，各个 CF 之间的数据长度和更新频率尽量保持平衡，他们之间有太多的紧耦合。
从读的角度看，读取频繁的列放到一个较小的 CF较有利。
CF 的设计需要均衡考虑业务的读写模式。
Hbase 运维碎碎念MSLAB
MemStore-Local Allocation Buffer
每个 MemStore都有一个 MemStoreLAB实例 MemStoreLAB 有一个 2MB 的 curChunk ，其 nextFreeOffset 为 0 每次 insert 一个 KV 时，数据（ byte[] 数组）复制到
curChunk ， nextFreeOffset 随之增长 curChunk满了以后，重新分配一个 2MB 的 Chunk 上述操作采用 compare-and-swap ，因此无需加锁
优点： 原始插入的数据生命周期变短，就不用进入年老代 可能进入年老代的 Chunk 是固定以 2MB 为大小，消除碎片的烦恼 每个 Chunk 只可能属于一个 MemStore 当 MemStore刷到磁盘， Heap 释放的内存也是以 2MB 为单位。
Hbase 运维碎碎念MSLAB
hbase.hregion.memstore.mslab.enabled是否启用 MSLAB ，默认 true
hbase.hregion.memstore.mslab.chunksizeChunk 的尺寸，默认 2MB
hbase.hregion.memstore.mslab.max.allocationMSLAB 中单次分配内存的最大尺寸，默认 256K ，超过该尺寸的内存直接在Heap上分配。
Hbase 运维碎碎念Regionserver
zookeeper.session.timeout默认 3 分钟，也就是 rs 超过 3 分钟没有给 zk 消息， Master 就认为 rs挂了。如果 gc 的过程中阻塞时间超过了 3 分钟，那就杯具了， so 。。。
hfile.block.cache.size默认 0.2 ，全局公用的 hfile 的 cache ，最多占用 MaxHeap 的 20% 。当数据在memstore 中读取不到时，就会从这个 cache里获取，当从此 cache 中获取不到时，就需要读取文件。当 cache 的 block达到了这个值的 85% 时，即会启动evict （日志中会出现“ Block cache LRU eviction” ），将 cache 清除到 75%大小，可通过日志中的“ LRU Stats: ” 来观察 cache 的命中率
Hbase 运维碎碎念Client
hbase.client.pause默认 1000ms ，客户端被阻塞或者失败后重试间隔，间隔为指数避让，即1,1,1,2,2,4,4,8,16,32 ，建议改下这个值，同时加大重试次数，避免 split 造成客户端响应时间过长以及失败率增加。
hbase.client.retries.number默认为 10 次，决定了客户端的重试次数
hbase.ipc.client.tcpnodelay默认 tcp 的 no delay 是 false ，建议修改为 true
ipc.ping.intervalRPC等待服务端响应的超时时间，默认为 1 分钟，有点太长了，建议改成 3秒（ 3000 ）
Hbase 运维碎碎念Compress
LZO 比默认的 Gzip 性能更好，但 Gzip压缩比更高
安装 lzo-2.00 以上版本：http://www.oberhumer.com/opensource/lzo/download/到 http://code.google.com/p/hadoop-gpl-compression/ 下载 lzo 相关的 native库
io.compression.codecscom.hadoop.compression.lzo.LzoCodec,com.hadoop.compression.lzo.LzopCodec
io.compression.codec.lzo.classcom.hadoop.compression.lzo.LzoCodec
参考： http://wiki.apache.org/hadoop/UsingLzoCompression
Hbase 运维碎碎念Replication
是的， Hbase 0.90.0 也开始支持 replication 了，不过目前版本 bug较多。参考： http://koven2049.iteye.com/blog/983633
图片出处： http://hbase.apache.org/docs/r0.89.20100726/replication.html
Hbase 运维碎碎念监控 Metrics
hbase.class=org.apache.hadoop.metrics.spi.CompositeContexthbase.arity=2hbase.period=10hbase.sub1.class=org.apache.hadoop.hbase.metrics.file.TimeStampingFileContexthbase.fileName=/tmp/metrics_hbase.loghbase.sub2.class=org.apache.hadoop.metrics.ganglia.GangliaContext31hbase.servers=localhost:8649
Hbase 运维碎碎念备份恢复
导出到本地或者 HDFShbase org.apache.hadoop.hbase.mapreduce.Driver export \Tablename /desctination
导入回 Hbasehbase org.apache.hadoop.hbase.mapreduce.Driver import \Tablename /source
导入 TSV 文件（以 Tab 分割的文本文件）hbase org.apache.hadoop.hbase.mapreduce.Driver importtsv \ -Dimporttsv.columns=a,b,c Tablename /source如果是 csv 文件，只需要加参数 -Dimporttsv.separator=,即可
Hbase 运维碎碎念备份恢复Hbase集群间 CopyTablehbase org.apache.hadoop.hbase.mapreduce.CopyTable …或者hbase org.apache.hadoop.hbase.mapreduce.Driver copytable …
Hadoop集群间 Copy 文件hadoop distcp -p -update "hdfs://A:8020/user/foo/bar" "hdfs://B:8020/user/foo/baz“
Mozilla 开发的 Backup工具对运行的 Hbase 进行做 distcp 会导致不一致， Mozilla 为此开发了一个Backup工具http://blog.mozilla.com/data/2011/02/04/migrating-hbase-in-the-trenches/
Hbase 运维碎碎念压力测试
$ ./hbase org.apache.hadoop.hbase.PerformanceEvaluationUsage: java org.apache.hadoop.hbase.PerformanceEvaluation \ [--miniCluster] [--nomapred] [--rows=ROWS] <command> <nclients>
Options: miniCluster Run the test on an HBaseMiniCluster nomapred Run multiple clients using threads (rather than use mapreduce) rows Rows each client runs. Default: One million flushCommits Used to determine if the test should flush the table. Default: false writeToWAL Set writeToWAL on puts. Default: True
Command: filterScan Run scan test using a filter to find a specific row based on it's value (make sure to use --rows=20) randomRead Run random read test randomSeekScan Run random seek and scan 100 test randomWrite Run random write test scan Run scan test (read every row) scanRange10 Run random seek scan with both start and stop row (max 10 rows) scanRange100 Run random seek scan with both start and stop row (max 100 rows) scanRange1000 Run random seek scan with both start and stop row (max 1000 rows) scanRange10000 Run random seek scan with both start and stop row (max 10000 rows) sequentialRead Run sequential read test sequentialWrite Run sequential write test
Args: nclients Integer. Required. Total number of clients (and HRegionServers) running: 1 <= value <= 500Examples: To run a single evaluation client: $ bin/hbase org.apache.hadoop.hbase.PerformanceEvaluation sequentialWrite 1
Hbase 运维碎碎念压力测试 Grinder ： http://grinder.sourceforge.net/ YCSB ： http://wiki.github.com/brianfrankcooper/YCSB/ GridMix ：
http://hadoop.apache.org/mapreduce/docs/current/gridmix.html
Hbase 运维碎碎念参考文档
《 Hadoop:The Definitive Guide》 the Apache Hbase Book hbase-hug-presentation http://www.spnguru.com/ Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning Avoiding Full GCs in HBase with MemStore
-Local Allocation Buffers: Part 1 Avoiding Full GCs in HBase with MemStore
-Local Allocation Buffers: Part 2 Avoiding Full GCs in HBase with MemStore
-Local Allocation Buffers: Part 3 Help for the NUMA weary
Hbase 运维碎碎念参考文档
NUMA与英特尔下一代Xeon处理器学习心得 http://blog.bluedavy.com/?p=236 http://koven2049.iteye.com/blog/983502 VISUALIZING HBASE FLUSHES AND COMPACTION namenode 内部关键数据结构简介 http://HBase.info
The End
Thanks~~
