[ 
https://issues.apache.org/jira/browse/HIVE-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15092672#comment-15092672
 ] 

Sergey Shelukhin edited comment on HIVE-12837 at 1/11/16 9:01 PM:
------------------------------------------------------------------

{noformat}
// Destination partition being empty indicates a write buffer
// will be allocated, thus need to check if memory is full
{noformat}
WB can also be allocated if one has already been allocated, if the previous one 
is close to full. This seems to handle only the small subset of the edge 
cases... Would the cases where we have one partition with 0 and one with 2 
buffers, or the case where we have enough memory for 2N-1 buffers, be handled 
elsewhere?


was (Author: sershe):
{noformat}
// Destination partition being empty indicates a write buffer
// will be allocated, thus need to check if memory is full
{noformat}
WB can also be allocated if one has already been allocated, if the previous one 
is close to full. This seems to handle only the small subset of the edge 
cases...

> Better memory estimation/allocation for hybrid grace hash join during hash 
> table loading
> ----------------------------------------------------------------------------------------
>
>                 Key: HIVE-12837
>                 URL: https://issues.apache.org/jira/browse/HIVE-12837
>             Project: Hive
>          Issue Type: Bug
>          Components: Hive
>    Affects Versions: 2.1.0
>            Reporter: Wei Zheng
>            Assignee: Wei Zheng
>         Attachments: HIVE-12837.1.patch
>
>
> This is to avoid an edge case when the memory available is very little (less 
> than a single write buffer size), and we start loading the hash table. Since 
> the write buffer is lazily allocated, we will easily run out of memory before 
> even checking if we should spill any hash partition.
> e.g.
> Total memory available: 210 MB
> Size of ref array of BytesBytesMultiHashMap for each hash partition: ~16 MB
> Size of write buffer: 8 MB (lazy allocation)
> Number of hash partitions: 16
> Number of hash partitions created in memory: 13
> Number of hash partitions created on disk: 3
> Available memory left after HybridHashTableContainer initialization: 
> 210-16*13=2MB
> Now let's say a row is to be loaded into a hash partition in memory, it will 
> try to allocate an 8MB write buffer for it, but we only have 2MB, thus OOM.
> Solution is to perform the check for possible spilling earlier so we can 
> spill partitions if memory is about to be full, to avoid OOM.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to