[
https://issues.apache.org/jira/browse/ASTERIXDB-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16157310#comment-16157310
]
Taewoo Kim commented on ASTERIXDB-2083:
---------------------------------------
Example Query: Find all records R that satisfy edit_distance(R, "president
donald trump") <= 2.
The way it works now in the master:
1. Tokenizes the given query into tokens: {president, donald, trump}
2. Initializes inverted index search cursors for each token. (the size of the
cursors list: 3)
3. Also initializes the searchResult class that will have Hyracks frames
(buffer) to contain the result (record IDs).
3. Decides the short lists *SL* that needs to be merged in the DivideSkip
algorithm.
4. For a list *L* in short lists *SL*,
Reads all record IDs (PK) from *L* into the buffer cache using
invListCursor.pinPages() method.
Conducts the prefix merge (the number of frames in the searchResult can be
expanded).
Releases all read pages in the buffer cache.
5. For a list *L* not in *SL*,
Reads all record IDs (PK) from *L* into the buffer cache using
invListCursor.pinPages() method.
Conducts the suffix merge (either probe or binary-search) : (the number of
frames in the searchResult can be expanded).
Releases all read pages in the buffer cache.
6. Return the result from this index-search.
Two issues:
#1. Although Hyracks processes token by token, for each token, AsterixDB reads
all record IDs (PKs) into the buffer cache at once.
If buffer cache can't read all record IDs, it will generate an exception
(after x,xxx cycle, still can't find available pages).
#2. In theory, number of frames in the SearchResult can be equal to that of the
longest inverted list.
If a frame can't be allocated to SearchResult, an OOM will be generated.
Thought for now:
#a. We may read a page by a page, not entire inverted list to the memory.
#b. Issue of consistency?
#c. *#a* can solve the buffer cache issue. But, the result should be kept in
memory during the operation. How do we solve #2?
Will be updated after getting more insights about this.
> An inverted index-search generates OOM Exception.
> -------------------------------------------------
>
> Key: ASTERIXDB-2083
> URL: https://issues.apache.org/jira/browse/ASTERIXDB-2083
> Project: Apache AsterixDB
> Issue Type: Bug
> Reporter: Taewoo Kim
> Assignee: Taewoo Kim
>
> An inverted index search can generate OOM Exception if the index size is
> large. This can apply to any inverted-index search related functions such as
> *ftcontains* and *contains*.
> An example exception message is as follows. We can see that this happens
> during an inverted-index search.
> {code}
> Aug 15, 2017 6:58:06 AM
> org.apache.hyracks.api.lifecycle.LifeCycleComponentManager uncaughtException
> SEVERE: Uncaught Exception from thread Executor-9:1
> java.lang.OutOfMemoryError: Java heap space
> Aug 15, 2017 6:58:06 AM
> org.apache.hyracks.api.lifecycle.LifeCycleComponentManager stopAll
> INFO: Attempting to stop
> org.apache.hyracks.api.lifecycle.LifeCycleComponentManager@69a3d1d
> Aug 15, 2017 6:58:06 AM
> org.apache.hyracks.api.lifecycle.LifeCycleComponentManager stopAll
> SEVERE: Stopping instance
> Aug 15, 2017 6:58:06 AM
> org.apache.hyracks.control.common.work.WorkQueue$WorkerThread run
> INFO: Executing: AbortTasks
> Aug 15, 2017 6:58:06 AM org.apache.hyracks.control.nc.Task run
> WARNING: Task TAID:TID:ANID:ODID:4:0:0:0 failed with exception
> org.apache.hyracks.api.exceptions.HyracksDataException:
> java.lang.OutOfMemoryError: Java heap space
> at
> org.apache.hyracks.api.exceptions.HyracksDataException.create(HyracksDataException.java:45)
> at
> org.apache.hyracks.api.rewriter.runtime.SuperActivityOperatorNodePushable.runInParallel(SuperActivityOperatorNodePushable.java:220)
> at
> org.apache.hyracks.api.rewriter.runtime.SuperActivityOperatorNodePushable.initialize(SuperActivityOperatorNodePushable.java:86)
> at org.apache.hyracks.control.nc.Task.run(Task.java:286)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at
> org.apache.hyracks.storage.am.btree.impls.BTree.createOpContext(BTree.java:753)
> at
> org.apache.hyracks.storage.am.btree.impls.BTree.access$100(BTree.java:67)
> at
> org.apache.hyracks.storage.am.btree.impls.BTree$BTreeAccessor.<init>(BTree.java:844)
> at
> org.apache.hyracks.storage.am.btree.impls.BTree.createAccessor(BTree.java:820)
> at
> org.apache.hyracks.storage.am.lsm.invertedindex.ondisk.OnDiskInvertedIndexOpContext.<init>(OnDiskInvertedIndexOpContext.java:42)
> at
> org.apache.hyracks.storage.am.lsm.invertedindex.ondisk.OnDiskInvertedIndex$OnDiskInvertedIndexAccessor.<init>(OnDiskInvertedIndex.java:422)
> at
> org.apache.hyracks.storage.am.lsm.invertedindex.ondisk.OnDiskInvertedIndex.createAccessor(OnDiskInvertedIndex.java:491)
> at
> org.apache.hyracks.storage.am.lsm.invertedindex.impls.LSMInvertedIndex.search(LSMInvertedIndex.java:275)
> at
> org.apache.hyracks.storage.am.lsm.common.impls.LSMHarness.search(LSMHarness.java:445)
> at
> org.apache.hyracks.storage.am.lsm.invertedindex.impls.LSMInvertedIndexAccessor.search(LSMInvertedIndexAccessor.java:77)
> at
> org.apache.hyracks.storage.am.common.dataflow.IndexSearchOperatorNodePushable.nextFrame(IndexSearchOperatorNodePushable.java:193)
> at
> org.apache.hyracks.dataflow.common.comm.io.AbstractFrameAppender.write(AbstractFrameAppender.java:92)
> at
> org.apache.hyracks.algebricks.runtime.operators.base.AbstractOneInputOneOutputOneFramePushRuntime.flushAndReset(AbstractOneInputOneOutputOneFramePushRuntime.java:66)
> at
> org.apache.hyracks.algebricks.runtime.operators.base.AbstractOneInputOneOutputOneFramePushRuntime.flushIfNotFailed(AbstractOneInputOneOutputOneFramePushRuntime.java:72)
> at
> org.apache.hyracks.algebricks.runtime.operators.base.AbstractOneInputOneOutputOneFramePushRuntime.close(AbstractOneInputOneOutputOneFramePushRuntime.java:55)
> at
> org.apache.hyracks.algebricks.runtime.operators.std.AssignRuntimeFactory$1.close(AssignRuntimeFactory.java:119)
> at
> org.apache.hyracks.algebricks.runtime.operators.std.EmptyTupleSourceRuntimeFactory$1.close(EmptyTupleSourceRuntimeFactory.java:65)
> at
> org.apache.hyracks.algebricks.runtime.operators.meta.AlgebricksMetaOperatorDescriptor$1.initialize(AlgebricksMetaOperatorDescriptor.java:104)
> at
> org.apache.hyracks.api.rewriter.runtime.SuperActivityOperatorNodePushable$$Lambda$57/871672554.run(Unknown
> Source)
> at
> org.apache.hyracks.api.rewriter.runtime.SuperActivityOperatorNodePushable.lambda$runInParallel$1(SuperActivityOperatorNodePushable.java:204)
> at
> org.apache.hyracks.api.rewriter.runtime.SuperActivityOperatorNodePushable$$Lambda$59/686827126.call(Unknown
> Source)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ... 3 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
