Apache Phoenix(二十)因加SALT导致的HFile合并风暴
发布网友
发布时间：2023-03-06 06:29
共1个回答
热心网友
时间：2024-04-05 09:56
起因：在每张临时表上增加SALT_BUCKETS = 16，导致三个节点的hbase集群出现了3000多个region，出现的几种表象：
Zookeeper
Master
RegionServer
HLog(WAL log)
Region
Memstore 与 storefile
我们知道一个RegionServer上有n个region,每个region会根据不同的col family数拥有不同的store,每个store有一块自己的memstore内存区和多个HFile文件,所以在region很多的情况下,平均RegionServer分担的Region就会多了,那么一台RegionServer上资源是优先的,并且多个region都有自己的memstore,所以就会争抢资源,一直与memstore比较小了,所以在memstore很小的时候,就会频繁的刷HFile,那么memstore刷出来的HFile也就相应的变小了,所以为了保证HFile的数量合理,就会发生大规模的合并,那么合并就会拖慢性能,甚至导致Full GC的发生.这就会造成RegionServer与ZK可能发生失联,那么就会造成一系列的错误。
对于大量需要临时表的业务，整改成单个临时表，结合phoenix的动态列进行。以当前公司的业务为例子，一个工程包含多个运行流程，每个运行流程的算子都可能发生变化，于是乎会影响中间的建表情况，在这种情况下我们需要建的表如下：
可以看到我的表是不存在name和age的，但是我可以这样插入进去：
vm.swappiness 参数被用于定义多少积极内存页被交换到磁盘。它接收从 0 到 100 的任何值 - 一个更低的值意味着内核将更少的交换，但是一个更高的值使得内核应用更经常的交换。默认值是 60。
我们在步骤 1 中把 vm.swappiness 设置成 0，这将使得内核避免把进程尽可能的从物理内存中交换出去。这对 HBase 是非常有用的，因为 HBase 的进程消费大量的内存，一个高的 vm.swappiness 值将使得 HBase 交换很多并遭遇非常慢的垃圾回收。随着 ZooKeeper session 超时，这可能会导致 RegionServer 进程被杀死。我们建议你设置它为 0 或者任何更低的数字（比如，10）并观察 swapping 状态。
注意该值被 sysctl 命令设置仅仅会持久化直到服务器下次重启。你需要在 /etc/sysctl.conf 文件设置 vm.swappiness，以至于该设置无论服务器什么时候重启都会生效。
加大堆内存，可以加大到linux服务器内存的2/3，并且指定gc日志，方便以后调试优化。
推荐设置：0
配置major合并的间隔时间，默认为1天，可设置为0，禁止自动的major合并，可手动或者通过脚本定期进行major合并，有两种compact：minor和major，minor通常会把数个小的相邻的storeFile合并成一个大的storeFile，minor不会删除标示为删除的数据和过期的数据，major会删除需删除的数据，major合并之后，一个store只有一个storeFile文件，会对store的所有数据进行重写，有较大的性能消耗。
推荐设置：100
该设置决定了处理RPC的线程数量，默认值是10，通常可以调大，比如：150，当请求内容很大（上MB，比如大的put、使用缓存的scans）的时候，如果该值设置过大则会占用过多的内存，导致频繁的GC，或者出现OutOfMemory，因此该值不是越大越好。
推荐设置：按照数据量/1000
配置region大小，0.94.12版本默认是10G，region的大小与集群支持的总数据量有关系，如果总数据量小，则单个region太大，不利于并行的数据处理，如果集群需支持的总数据量比较大，region太小，则会导致region的个数过多，导致region的管理等成本过高，如果一个RS配置的磁盘总量为3T*12=36T数据量，数据复制3份，则一台RS服务器可以存储10T的数据，如果每个region最大为10G，则最多1000个region，如此看，94.12的这个默认配置还是比较合适的，不过如果要自己管理split，则应该调大该值，并且在建表时规划好region数量和rowkey设计，进行region预建，做到一定时间内，每个region的数据大小在一定的数据量之下，当发现有大的region，或者需要对整个表进行region扩充时再进行split操作，一般提供在线服务的hbase集群均会弃用hbase的自动split，转而自己管理split。
推荐设置：暂无
RS的block cache的内存大小*，默认值0.25，在偏向读的业务中，可以适当调大该值，具体配置时需试hbase集群服务的业务特征，结合memstore的内存占比进行综合考虑。
推荐设置：6
HStore的storeFile数量>= compactionThreshold配置的值，则可能会进行compact，默认值为3，可以调大，比如设置为6，在定期的major compact中进行剩下文件的合并。
hbase.hstore.blockingStoreFiles
HStore的storeFile的文件数大于配置值，则在flush memstore前先进行split或者compact，除非超过hbase.hstore.blockingWaitTime配置的时间，默认为7，可调大，比如：100，避免memstore不及时flush，当写入量大时，触发memstore的block，从而阻塞写操作。
推荐设置：4
默认值2，如果memstore的内存大小已经超过了hbase.hregion.memstore.flush.size的2倍，则会阻塞memstore的写操作，直到降至该值以下，为避免发生阻塞，最好调大该值，比如：4，不可太大，如果太大，则会增大导致整个RS的memstore内存超过memstore.upperLimit*的可能性，进而增大阻塞整个RS的写的几率。如果region发生了阻塞会导致大量的线程被阻塞在到该region上，从而其它region的线程数会下降，影响整体的RS服务能力
推荐设置：128M
默认值128M，单位字节，超过将被flush到hdfs，该值比较适中，一般不需要调整。
推荐设置：0.4
默认值0.4，RS所有memstore占用内存在总内存中的upper比例，当达到该值，则会从整个RS中找出最需要flush的region进行flush，直到总内存比例降至该数*以下，并且在降至*比例以下前将阻塞所有的写memstore的操作，在以写为主的集群中，可以调大该配置项，不建议太大，因为block cache和memstore cache的总大小不会超过0.8，而且不建议这两个cache的大小总和达到或者接近0.8，避免OOM，在偏向写的业务时，可配置为0.45，memstore.lowerLimit保持0.35不变，在偏向读的业务中，可调低为0.35，同时memstore.lowerLimit调低为0.3，或者再向下0.05个点，不能太低，除非只有很小的写入操作，如果是兼顾读写，则采用默认值即可。
hbase.hregion.memstore.flush.size 这个参数的作用是当单个Region内所有的memstore大小总和超过指定值时，flush该region的所有memstore。RegionServer的flush是通过将请求添加一个队列，模拟生产消费模式来异步处理的。那这里就有一个问题，当队列来不及消费，产生大量积压请求时，可能会导致内存陡增，最坏的情况是触发OOM。这个参数的作用是防止内存占用过大，当ReigonServer内所有region的memstores所占用内存总和达到heap的[40%]时，HBase会强制block所有的更新并flush这些region以释放所有memstore占用的内存
推荐设置：0.35
默认值0.35，RS的所有memstore占用内存在总内存中的lower比例，当达到该值，则会从整个RS中找出最需要flush的region进行flush，配置时需结合memstore.upperLimit和block cache的配置。同upperLimit，只不过lowerLimit在所有region的memstores所占用内存达到Heap的[35%]时，不flush所有的memstore。它会找一个memstore内存占用最大的region，做个别flush，此时写更新还是会被block。lowerLimit算是一个在所有region强制flush导致性能降低前的补救措施。在日志中，表现为 “** Flush thread woke up with memory above low water.”
推荐设置：false
在index写入的时候允许put无根（non-root）的多级索引块到block cache里，默认是false，设置为true，或许读性能更好，但是是否有副作用还需调查。
推荐设置：false
默认为false，需调查其作用。
6.13、hbase.regionserver.regionSplitLimit
推荐设置：默认即可
控制最大的region数量，超过则不可以进行split操作，默认是Integer.MAX，可设置为1，禁止自动的split，通过人工，或者写脚本在集群空闲时执行。如果不禁止自动的split，则当region大小超过hbase.hregion.max.filesize时会触发split操作（具体的split有一定的策略，不仅仅通过该参数控制，前期的split会考虑region数据量和memstore大小），每次flush或者compact之后，regionserver都会检查是否需要Split，split会先下线老region再上线split后的region，该过程会很快，但是会存在两个问题：1、老region下线后，新region上线前client访问会失败，在重试过程中会成功但是如果是提供实时服务的系统则响应时长会增加；2、split后的compact是一个比较耗资源的动作。
推荐设置：180000
默认值：3分钟（180000ms）；RegionServer与Zookeeper间的连接超时时间。当超时时间到后，ReigonServer会被Zookeeper从RS集群清单中移除，HMaster收到移除通知后，会对这台server负责的regions重新balance，让其他存活的RegionServer接管.这个timeout决定了RegionServer是否能够及时的failover。设置成1分钟或更低，可以减少因等待超时而被延长的failover时间。不过需要注意的是，对于一些Online应用，RegionServer从宕机到恢复时间本身就很短的（网络闪断，crash等故障，运维可快速介入），如果调低timeout时间，反而会得不偿失。因为当ReigonServer被正式从RS集群中移除时，HMaster就开始做balance了（让其他RS根据故障机器记录的WAL日志进行恢复）。当故障的RS在人工介入恢复后，这个balance动作是毫无意义的，反而会使负载不均匀，给RS带来更多负担。特别是那些固定分配regions的场景。
