[jira] [Created] (HBASE-27002) Config BucketCache as victim of LRUCache
Xuesen Liang created HBASE-27002:
Summary: Config BucketCache as victim of LRUCache
Key: HBASE-27002
URL: https://issues.apache.org/jira/browse/HBASE-27002
Project: HBase
Issue Type: Improvement
Components: BlockCache, BucketCache
Reporter: Xuesen Liang
Assignee: Xuesen Liang
Bucket cache is no longer as a victim handler for LRU by HBASE-19357.
{noformat}
When BC is used, data blocks will be strictly on BC only where as index/bloom
blocks are on LRU L1 cache.
{noformat}
In this situation, the LRU cache's memory is totally on heap.
If the index and bloom filters on a region server are big, then a big LRU cache
will introduce more GC cost.
So we should add a *configuration for user* to choose victim handler.
A small LRU cache with a big victim offheap bucket cache can reduce GC cost.
For example: a region server has 5GB index, 80 GB bloom filter, and 256GB DRAM,
its configurations can be as follow:
{code:xml}
export HBASE_REGIONSERVER_OPTS="-Xms40g -Xmx40g -XX:MaxDirectMemorySize=180g"
{code}
{code:xml}
hbase.bucketcache.as.lrucache.victim
true
hfile.block.cache.size
0.3
hbase.bucketcache.ioengine
offheap
hbase.bucketcache.size
16
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (HBASE-26982) Add index and bloom filter statistics of LruBlockCache on rs web UI
Xuesen Liang created HBASE-26982: Summary: Add index and bloom filter statistics of LruBlockCache on rs web UI Key: HBASE-26982 URL: https://issues.apache.org/jira/browse/HBASE-26982 Project: HBase Issue Type: Improvement Components: BlockCache, UI Reporter: Xuesen Liang Assignee: Xuesen Liang When _CombinedBlockCache_ is configured, _LruBlockCache_ is used for index/bloom/meta block cache, and _BucketCache_ is used for data block cache. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (HBASE-26980) Update javadoc of BucketCache.java
Xuesen Liang created HBASE-26980: Summary: Update javadoc of BucketCache.java Key: HBASE-26980 URL: https://issues.apache.org/jira/browse/HBASE-26980 Project: HBase Issue Type: Improvement Reporter: Xuesen Liang Assignee: Xuesen Liang The feature of on-heap Bucket cache was removed by [HBASE-19187|https://issues.apache.org/jira/browse/HBASE-19187]. We should update its javadoc which now is inaccurate and confusing. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (HBASE-26978) Update inmemory_compaction.adoc
Xuesen Liang created HBASE-26978: Summary: Update inmemory_compaction.adoc Key: HBASE-26978 URL: https://issues.apache.org/jira/browse/HBASE-26978 Project: HBase Issue Type: Bug Components: documentation Reporter: Xuesen Liang Assignee: Xuesen Liang The default value of _hbase.hregion.compacting.memstore.type_ was changed from _BASIC_ to _DEFAULT_ by [HBASE-20539|https://issues.apache.org/jira/browse/HBASE-20539]. We should update its doc _inmemory_compaction.adoc_ accordingly. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (HBASE-26975) Add on heap and off heap memstore info in region web UI
Xuesen Liang created HBASE-26975: Summary: Add on heap and off heap memstore info in region web UI Key: HBASE-26975 URL: https://issues.apache.org/jira/browse/HBASE-26975 Project: HBase Issue Type: Improvement Components: UI Reporter: Xuesen Liang Assignee: Xuesen Liang There are _Memstore Size_ and _Memstore Limit_ info in rs-status page. These information is a little coarse granularity and confusing: * _Memstore Size_ means memstore data size, but we cannot tell the difference of on heap and off heap memstore data size. * _Memstore Limit_ is off heap memstore limit if off-heap is enabled, otherwise, it is on heap memstore limit. We should provide more detailed information. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (HBASE-26964) Fix java import in admin.rb
Xuesen Liang created HBASE-26964:
Summary: Fix java import in admin.rb
Key: HBASE-26964
URL: https://issues.apache.org/jira/browse/HBASE-26964
Project: HBase
Issue Type: Bug
Components: shell
Reporter: Xuesen Liang
Assignee: Xuesen Liang
The java_import for MobCompactPartitionPolicy in admin.rb is missed, which
cause an error message for creating table.
{code:bash}
hbase:006:0> create 't2', {NAME => 'f', IS_MOB => true, MOB_THRESHOLD =>
100, MOB_COMPACT_PARTITION_POLICY => 'weekly'}
ERROR: uninitialized constant Hbase::Admin::MobCompactPartitionPolicy
Did you mean? Hbase::Admin::MOB_COMPACT_PARTITION_POLICY
For usage try 'help "create"'
Took 0.6897 seconds
hbase:007:0> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (HBASE-26962) Add mob info in web UI
Xuesen Liang created HBASE-26962: Summary: Add mob info in web UI Key: HBASE-26962 URL: https://issues.apache.org/jira/browse/HBASE-26962 Project: HBase Issue Type: Improvement Components: UI Reporter: Xuesen Liang Assignee: Xuesen Liang Add mob store info in web UI. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (HBASE-26479) Print too slow/big scan's operation_id in region server log
Xuesen Liang created HBASE-26479: Summary: Print too slow/big scan's operation_id in region server log Key: HBASE-26479 URL: https://issues.apache.org/jira/browse/HBASE-26479 Project: HBase Issue Type: Improvement Components: regionserver Reporter: Xuesen Liang Assignee: Xuesen Liang Tracing is very important in large-scale distributed systems. The attribute *__operation.attributes.id_* of a scan request can be used as trace id between hbase client and region server. We should print operation id in region server's log if the scan request is too slow or too big. It will be very helpful for finding problematic requests. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (HBASE-17297) Single Filter in parenthesis cannot be parsed correctly
Xuesen Liang created HBASE-17297:
Summary: Single Filter in parenthesis cannot be parsed correctly
Key: HBASE-17297
URL: https://issues.apache.org/jira/browse/HBASE-17297
Project: HBase
Issue Type: Bug
Components: Filters
Reporter: Xuesen Liang
{code}
hbase(main):010:0* put 'testtable', 'row1', 'cf1:a', 'ab'
0 row(s) in 0.1800 seconds
hbase(main):011:0> scan 'testtable'
ROW COLUMN+CELL
row1column=cf1:a, timestamp=1481538756308,
value=ab
hbase(main):012:0> scan 'testtable', FILTER=>"(ValueFilter(=,'binary:ab'))"
ROW COLUMN+CELL
row1column=cf1:a, timestamp=1481538756308,
value=ab
hbase(main):013:0* scan 'testtable', FILTER=>"(ValueFilter(=,'binary:x') AND
ValueFilter(=,'binary:y')) OR ValueFilter(=,'binary:ab')"
ROW COLUMN+CELL
row1column=cf1:a, timestamp=1481538756308,
value=ab
hbase(main):014:0> scan 'testtable', FILTER=>"(ValueFilter(=,'binary:x') AND
(ValueFilter(=,'binary:y'))) OR ValueFilter(=,'binary:ab')"
ROW COLUMN+CELL
0 row(s) in 0.0100 seconds
{code}
In the last scan, we should got a row.
The inner cause is that the last filter is parsed incorrectly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
