由ttl引发的responseTooSlow
2017-11-23 09:57
204 查看
前段时间业务反应数据查询速度慢,大批量的数据出现查询时间超过多少多少秒。看了下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的时候才会删除。
在这个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的时候才会删除。
相关文章推荐
- Docker 私有仓库,pull镜像报错:server gave HTTP response to HTTPS client
- composer报错:Failed to decode response: zlib_decode(): data error
- 【问题及解决】Elasticsearch--Failed to deserialize exception response from stream
- VisualSVN Server issue: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY
- org.elasticsearch.transport.TransportSerializationException: Failed to deserialize response解决方案
- render_to_response() got an unexpected keyword argument 'context_instance'
- 一个toLocaleDateString引发的错误
- response.sendRedirect所引发的问题及解决
- NoHttpResponseException:api.mch.weixin.qq.com:443 failed to respond
- 少写了 @ResponseBody 引发的古怪问题
- Jmeter性能测试NoHttpResponseException (the target server failed to respond)
- sudo gem install: Unable to download data from http://ruby.taobao.org/ - bad response Not Found 404
- why Must initial form when render_to_response
- MongoDB2.2 的 Time To Live (TTL) 集合一些注意事项
- Struggling trying to get cookie out of response with HttpClient in .net 4.5
- RuntimeException could not be mapped to a response, re-throwing to the HTTP container java.lang.Null
- StringBuffer.toString误用引发的血案
- 【LR】The Vuser Generator is unable to create a text check in this manner .To create a text check,swich to the Server Response vie
- nginx+tomcat 报错:『an upstream response is buffered to a temporary file 』
- WebSocket connection to,Error during WebSocket handshake: Unexpected response code: 404