Description
The multi-threaded performance takes a serious hit when LLAP shares hashtables between the probe threads running in parallel.
This is an explicit synchronized block inside ReusableRowContainer which triggers this particular pattern.
Looking deeper into the code, the synchronization seems to be caused due to the fact that WriteBuffers.setReadPoint modifies the otherwise read-only hashtable.
To generate this sort of result, run LLAP at a WARN log-level, to avoid all the log synchronization that otherwise affects the thread sync.
Attachments
Attachments
Issue Links
- duplicates
-
HIVE-10112 LLAP: query 17 tasks fail due to mapjoin issue
- Resolved
- relates to
-
HIVE-10219 BytesBytesMultiHashMap::clear() can't be concurrently used with reads
- Closed
- supercedes
-
HIVE-10112 LLAP: query 17 tasks fail due to mapjoin issue
- Resolved