由ttl引发的responseTooSlow

       前段时间业务反应数据查询速度慢，大批量的数据出现查询时间超过多少多少秒。看了下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的时候才会删除。