hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sahil Takiar (JIRA)" <>
Subject [jira] [Commented] (HIVE-17684) HoS memory issues with MapJoinMemoryExhaustionHandler
Date Thu, 13 Sep 2018 21:46:00 GMT


Sahil Takiar commented on HIVE-17684:

[] I attached an updated path. I did a good amount of re-factoring to the
patch. The main reason is that we only want these changes to apply to Hive-on-Spark, not Hive-on-MR
(at least for now). The reason is that we are only seeing issues when running Hive-on-Spark,
not Hive-on-MR.

The main changes are as follows:
* Created a new interface called {{MemoryExhaustionChecker}} which has two implementations:
** {{DefaultMemoryExhaustionChecker}} preserves the old logic - e.g. uses {{MapJoinMemoryExhaustionHandler}}
** {{SparkMemoryExhaustionChecker}} uses the new logic you added - e.g. {{GcTimeMonitor}}
* Depending on the execution engine, {{HashTableSinkOperator}} will use one of the above classes
to check if memory has been exhausted
* I changed {{hive.mapjoin.max.gc.time.percentage}} to be a value between 0 and 1 to make
the config more consistent with the rest of Hive configs.

Let me know what you think. These new changes should also fix the test failures you were seeing.

> HoS memory issues with MapJoinMemoryExhaustionHandler
> -----------------------------------------------------
>                 Key: HIVE-17684
>                 URL:
>             Project: Hive
>          Issue Type: Bug
>          Components: Spark
>            Reporter: Sahil Takiar
>            Assignee: Misha Dmitriev
>            Priority: Major
>         Attachments: HIVE-17684.01.patch, HIVE-17684.02.patch, HIVE-17684.03.patch, HIVE-17684.04.patch,
HIVE-17684.05.patch, HIVE-17684.06.patch, HIVE-17684.07.patch, HIVE-17684.08.patch
> We have seen a number of memory issues due the {{HashSinkOperator}} use of the {{MapJoinMemoryExhaustionHandler}}.
This handler is meant to detect scenarios where the small table is taking too much space in
memory, in which case a {{MapJoinMemoryExhaustionError}} is thrown.
> The configs to control this logic are:
> {{hive.mapjoin.localtask.max.memory.usage}} (default 0.90)
> {{hive.mapjoin.followby.gby.localtask.max.memory.usage}} (default 0.55)
> The handler works by using the {{MemoryMXBean}} and uses the following logic to estimate
how much memory the {{HashMap}} is consuming: {{MemoryMXBean#getHeapMemoryUsage().getUsed()
/ MemoryMXBean#getHeapMemoryUsage().getMax()}}
> The issue is that {{MemoryMXBean#getHeapMemoryUsage().getUsed()}} can be inaccurate.
The value returned by this method returns all reachable and unreachable memory on the heap,
so there may be a bunch of garbage data, and the JVM just hasn't taken the time to reclaim
it all. This can lead to intermittent failures of this check even though a simple GC would
have reclaimed enough space for the process to continue working.
> We should re-think the usage of {{MapJoinMemoryExhaustionHandler}} for HoS. In Hive-on-MR
this probably made sense to use because every Hive task was run in a dedicated container,
so a Hive Task could assume it created most of the data on the heap. However, in Hive-on-Spark
there can be multiple Hive Tasks running in a single executor, each doing different things.

This message was sent by Atlassian JIRA

View raw message