[
https://issues.apache.org/jira/browse/HBASE-28692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17861209#comment-17861209
]
Andrew Kyle Purtell edited comment on HBASE-28692 at 7/1/24 4:27 PM:
---------------------------------------------------------------------
Ok, so the flamegraph shows that a significant proportion of the CPU is spent
comparing keys for entries in the memstore CSLM when processing queries. This
appears normal.
If you enable the in-memory compacting memstore, does the performance change?
https://hbase.apache.org/book.html#inmemory_compaction
Also make sure your test scenario accurately reflects what you can expect in
production. Regions will flush. If you expect real production conditions to be
similar to your test, collecting into memstore a ton of updates processed in a
short interval, so the memstore really will be loaded like this, consider
modifying the flush related configuration parameters to trigger flushes more
frequently.
We have also considered replacing the CSLM with another data type optimized for
HBase specific requirements, although any replacement for CLSM will bring its
own trade offs, so such a change will have a very high bar for acceptance.
Refer to HBASE-20312.
was (Author: apurtell):
Ok, so the flamegraph shows that a significant proportion of the CPU is spent
comparing keys for entries in the memstore CSLM when processing queries. This
appears normal.
If you enable the in-memory compacting memstore, does the performance change?
https://hbase.apache.org/book.html#inmemory_compaction
Also make sure your test scenario accurately reflects what you can expect in
production. Regions will flush. If you expect real production conditions to be
similar to your test, collecting into memstore a ton of updates processed in a
short interval, consider modifying the flush related configuration parameters
to trigger flushes more frequently.
We have also considered replacing the CSLM with another data type optimized for
HBase specific requirements, although any replacement for CLSM will bring its
own trade offs, so such a change will have a very high bar for acceptance.
Refer to HBASE-20312.
> The GET call for column keys becomes significantly slower when it follows
> lexicographically prior deleted cells. [PERFORMANCE BLOAT]
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-28692
> URL: https://issues.apache.org/jira/browse/HBASE-28692
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 2.5.5
> Environment: Ubuntu 22.04.4 LTS - 64 Bit
> Reporter: Robin Infant A
> Priority: Critical
> Attachments: DataFlow.png, HbaseGet.java, RegionServerFlame.png
>
>
> *Steps to Reproduce :*
> 1. Ensure the column family of the table is configured with MIN_VERSION = 1
> and KEEP_DELETED_CELLS = true to ensure that deleted cells remain even after
> deletion (this is to ensure that flush/compaction doesn't remove deleted
> cells).
> 2. Add multiple column keys against a single row key. In this case, use a
> timestamp (SET1).
> 3. Use a GET call (GET1) with an iterator-based design to get all the keys.
> Use the ColumnPaginationFilter and RangeKeyFilter to achieve this (refer to
> the attached HbaseGet.java file for implementation details).
> 4. Note the time taken for GET1 (e.g., ~1 second for 100,000 entries).
> 5. Delete all the added column keys (SET1).
> 6. Add another set of 100,000 entries (SET2).
> 7. Use the GET call again (GET2) to retrieve the data and note the time taken.
> *Expected Behavior:*
> The time taken for GET2 should be similar to GET1, approximately ~1 second.
> *Actual Behavior:*
> The time taken for GET2 increases significantly, approximately 60 seconds,
> which is ~50 times longer than GET1.
> *Additional Information:*
> i) If, after the first delete (SET1), data with lexicographically prior
> characters (e.g., "0") are added before the deleted cells (timestamp), the
> GET call time remains consistent with GET1, approximately 1200 ms.
> ii) If all 200,000 entries are retrieved without deleting the first set
> (SET1), the total time is around 2 to 3 seconds. However, deleting SET1
> causes GET2 to take 50 times longer than GET1.
> *Suggested Fix:*
> Temporarily, to fix this issue, add a dummy column key with a
> lexicographically prior character (e.g., "0") to ensure consistent GET call
> times.
> *Note:*
> Please refer to the attached [^HbaseGet.java], RegionserverFlameGraph and
> dataFlow for detailed steps to reproduce the issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
