Hi all,
Just to draw your attention of a patch, I'd like to share an incident with you.
Two months ago we encountered an incident in one of our Impala clusters in
version 2.5-cdh5.7.3. Queries were pilled up and most of them were in CREATED
state. It looks like an infamous incident when the catalogd is loading metadata
of huge tables and finally OOM so metadata loading requests from impalad are
stuck. However, the catalogd looks good this time. The logs showed it's not
loading any metadata. Then I looked into the statestored and found many timeout
logs like "Unable to send topic update message to subscriber impalad@xxx:22000,
received error: RPC timed out". Chose one of the problematic impalad and dug
into its log, I found most of them are OOM. Logs look like:
E0524 13:46:46.200798 4405impala-server.cc:1344] There was an error processing
the impalad catalog update. Requesting a full topic update to recover:
OutOfMemoryError: Java heap space
at
com.cloudera.impala.hive.executor.UdfExecutor.evaluate(UdfExecutor.java:402)
at
com.cloudera.impala.hive.executor.UdfExecutor.evaluate(UdfExecutor.java:329)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)E0524
13:49:06.433274 4405impala-server.cc:1344] There was an error processing the
impalad catalog update. Requesting a full topic update to recover:
OutOfMemoryError: Java heap space
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.cloudera.impala.hive.executor.UdfExecutor.evaluate(UdfExecutor.java:394)
... 1 more
Caused by: java.lang.OutOfMemoryError: Java heap space
E0524 13:56:44.460489 4405impala-server.cc:1344] There was an error processing
the impalad catalog update. Requesting a full topic update to recover:
OutOfMemoryError: Java heap space
E0524 14:03:45.630472 4405impala-server.cc:1344] There was an error processing
the impalad catalog update. Requesting a full topic update to recover:
OutOfMemoryError: Java heap space
At that time I can only restart the whole cluster since most of the impalads
were showing OOM errors. It's quite painful but after that the cluster
recovered.
After I dug into the query history and replayed the queries in a test cluster,
I realized it's caused by a UDF we added one day before. Our users want to
parse JSON strings, but there're no builtin functions for this (IMPALA-376). So
we simply added the Hive UDF get_json_object by
create function get_json_object location
'hdfs://xxx/hive-exec-1.1.0-cdh5.7.3.jar'
SYMBOL='org.apache.hadoop.hive.ql.udf.UDFJson';
No problem with this query. But there's a bug in hive-1.1.0-cdh5.7.3 that would
cause memory leak if more than one UdfJson objects are running in a JVM
(HIVE-16196). That's why the impalads got OOM. Memory in the JVM is not
tracked. The bug in UdfJson is fixed in later hive versions
(https://github.com/cloudera/hive/commit/8397f933ea3ee5e2087b4def6b58ed5d77026108#diff-e0b4cff52301169fede5c9550e968b67
). However, using new hive jars (e.g.
hive-exec-1.1.0-cdh5.16.0-SNAPSHOT-core.jar) in the CREATE FUNCTION statement
does not work, since the class name is still the same and the hive jars in
version cdh5.7.3 are already in the CLASSPATH. Impala will still load the old
implementation of UDFJson. To work around this, I copied the implementation of
UDFJson and use another class name, then use my custom jar file instead.
This is not the final fix since memory used in java UDFs are not tracked. It's
still unsafe. Looking into the C++ implementation of get_json_object
(https://github.com/nazgul33/impala-get-json-object-udf) provided by an early
comment in IMPALA-376, it still not tracks the memory. So I give another
implementation and it's ready for code review:
https://gerrit.cloudera.org/c/10950/ (It has passed the pre-view-test:
https://jenkins.impala.io/job/pre-review-test/189/ ) Yes, this's the purpose of
this email. Thank you for reading!
Further thoughts:
* We might need to mention in the docs that adding java UDFs may not use the
given jar file if the impala CLASSPATH already contains a jar file containing
the same class.
* We should avoid using Hive builtin UDFs and any other Java UDFs since their
memory is not tracked.
* How to track memory used in JVM? HBase, a pure java project, is able to track
its MemStore and BlockCache size. Can we learn from it?
Thanks,
Quanlong
--
Quanlong Huang
Software Developer, Hulu