phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Poon (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-3806) IndexUpdateManager spending a lot of time sorting mutations on Index rebuild
Date Mon, 24 Apr 2017 18:57:05 GMT


Vincent Poon commented on PHOENIX-3806:

Some more detail on this issue:

What we found was that the sorting being doing in IndexUpdateManager#fixUpCurrentUpdates can
potentially be called a large number of times, and it seems to only happen when triggered
from the BuildIndexScheduleTask code path.    In our case the collection being sorted had
50001 Deletes because even though the indexing rebuilding code batches the mutations it is
replaying, there is a raw scan that happens which can surface all the versions for the mutations.
 From a quick glance, it seems the raw scan is determined by whether BaseScannerRegionObserver.IGNORE_NEWER_MUTATIONS
is set.

So there are number of avenues to explore here - can the batching be done better?  Do we need
all versions?  Certainly it seems the sorting in fixUpCurrentUpdates can be done better, by
sorting once rather than on every loop iteration.  I'll look into that further.

Steps to reproduce (perhaps can be converted to a unit test):
1)  Produce a large number of versions for a single row
2)  Disable the index on the table with "alter index <index> on <table> disable"
3)  Make sure the index_disable_timestamp is set (filed PHOENIX-3810)
4) The rebuilder should trigger the sort for a large number of deletes

> IndexUpdateManager spending a lot of time sorting mutations on Index rebuild
> ----------------------------------------------------------------------------
>                 Key: PHOENIX-3806
>                 URL:
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Lars Hofhansl
> Here's the stack trace. The Array contains 50001 Delete Mutations in this case.
> It seems the code is sorting this over and over again.
> {code}
> Thread 170 (B.DefaultRpcServer.handler=67,queue=7,port=60020):
>   State: RUNNABLE
>   Blocked count: 220598
>   Waited count: 377933
>   Stack:
>     java.util.TimSort.binarySort(
>     java.util.TimSort.sort(
>     java.util.Arrays.sort(
>     org.apache.phoenix.hbase.index.covered.update.SortedCollection.iterator(
>     org.apache.phoenix.hbase.index.covered.update.IndexUpdateManager.fixUpCurrentUpdates(
>     org.apache.phoenix.hbase.index.covered.update.IndexUpdateManager.addIndexUpdate(
>     org.apache.phoenix.hbase.index.covered.NonTxIndexBuilder.addCurrentStateMutationsForBatch(
>     org.apache.phoenix.hbase.index.covered.NonTxIndexBuilder.addUpdateForGivenTimestamp(
>     org.apache.phoenix.hbase.index.covered.NonTxIndexBuilder.addMutationsForBatch(
>     org.apache.phoenix.hbase.index.covered.NonTxIndexBuilder.batchMutationAndAddUpdates(
>     org.apache.phoenix.hbase.index.covered.NonTxIndexBuilder.getIndexUpdate(
>     org.apache.phoenix.hbase.index.builder.IndexBuildManager$
>     org.apache.phoenix.hbase.index.builder.IndexBuildManager$
>     org.apache.phoenix.hbase.index.parallel.BaseTaskRunner.submit(
>     org.apache.phoenix.hbase.index.parallel.BaseTaskRunner.submitUninterruptible(
>     org.apache.phoenix.hbase.index.builder.IndexBuildManager.getIndexUpdate(
>     org.apache.phoenix.hbase.index.Indexer.preBatchMutateWithExceptions(
> Thread 169 (B.DefaultRpcServer.handler=66,queue=6,port=60020):
> {code}
> [~jamestaylor]

This message was sent by Atlassian JIRA

View raw message