前段时间业务反应数据查询速度慢,大批量的数据出现查询时间超过多少多少秒。看了下io,发现io一直都很高,基本上很多都达到了400M/s。有点可以飙到600M/s。然后在日志出现了很多responseTooSlow的现象。但是问题是,数据量却没有很明显的增长。于是,我们初步判定是由于io的原因。
在这个hdfs上,有两个hbase实例,每个实例都有一个业务应用。
1.初步缓解
为了初步解决这个io问题,我们进行了扩容,在原有的60台rs的基础上,又扩充了12台rs。扩充完成后,io有所下降,但没有从根本解决问题。
2.找到根本原因以及最终解决
在一系列分析后,我们感觉问题可能出在另一个应用上。于是,我们开始查看另一个应用上的实例,包括日志等等。无意中发现,另一个应用的日志中,出现了大量的compact日志,统计发现,平均3s一次,而且还有排队现象。这个时候我们就断定io那么大的现象是由于compact导致的,一直在读写文件。
那么问题又来了,为什么现在会有那么多的compact呢,为什么会引起那么大的io呢?
这个时候我们又去研究了,发现表的ttl时间已经到了。那会不会是ttl时间到了,后台major compact已经在开始删除数据了,导致有如此多的io了呢?所以我们进行了一下两点修改:
a.调整compact有关的参数,具体为
hbase.hstore.compaction.kv.max 10>200
hbase.hstore.compaction.min 3>6
hbase.hstore.compactionThreshold 3>6
hbase.hstore.compaction.max.size 9223372036854775807>5368709120
hbase.regionserver.thread.compaction.large 5>10
hbase.hstore.blockingStoreFiles 7>20
hbase.hregion.max.filesize 10737418240>21474836480
hbase.master.initializationmonitor.timeout 1200000>3600000
b.去掉ttl
其实我们是先做了第一步,compact从原来的3s一次改成了20s一次。情况又有所好转。后来为了从根本解决问题又做了b步骤。然后经过一段时间的观察,发现情况彻底好了。业务侧反应查询正常了。
3.分析
对于这一现象,我在网上搜了下,发现也有人和我的情况是一样的。
http://blog.csdn.net/vbaspdelphi/article/details/55655459
在一些大神的帮助下,我知道了,原来minor compact也会删除数据,他会删除ttl过期的数据。
如果表设置了ttl,那么当某条数据ttl时间到了,会给该数据产生一个tombstone(墓碑)标识。在minor compact的时候,它会删除这些ttl过期的数据,但不会删除tombstone标识。这个tombstone标识只有在major compact的时候才会删除。