Hi, I am using hbase 0.94.6 version. We are developing a java application and using it as our storage for a high load web application. The average ration is about 500 requests per second. From time to time I see high latency (more then 300 ms!!!) when trying to store data object within hbase (using Put).
When there is more than 3 files for a region (default setting), HBase will trigger a minor compaction for this region. However, if all the regions need to be compacted, then it will promote it as a major compaction. So even by disabling major compaction so can still see some of it in the logs.
If you can run major compaction one a day it's better than once a week. Also, this might be related to your design (too many column families?), your usage and your configuration (compaction triggers, memory configuration, etc.).
I think, the major issue here - not a sudden major compaction, but why everything, literally, stalls when major compaction kicks off? Is there any clear explanation, somewhere, how does major compaction can affect tput, latency, availability of HBase? 300ms latency is possible, of course , as an rare outlier, but if its 90% percentile - its totally different story.
-Vladimir On Sun, Feb 2, 2014 at 1:49 PM, Kevin O'dell <[EMAIL PROTECTED]>wrote:
"Memory sizing" generally means how much RAM you have allocated to HBase. The amount of heap, the total size of your memstores and the number of them. This will impact the size of an individual memstore and thus the size of the new HFiles flushed to disk. This impacts the frequency and character of compactions. More column families => more memstores => (usually) smaller flush sizes => more compactions. On Mon, Feb 3, 2014 at 4:34 AM, yanivG <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
Apache Lucene, Apache Solr and all other Apache Software Foundation project and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext