數據平台做一些計算需要通過hive jdbc方式連到hiveserver2執行job,但是hiveserver 正常運行一段時間后，總是會報如下OOM:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
Hive history file=/tmp/work/hive_job_log_ce580f37-05ff-4ca6-b4c8-bb4337e0ed47_1912327686.txt
Total MapReduce jobs = 1
Launching Job 1 out of 1
Number of reduce tasks not specified. Estimated from input data size: 1
In order to change the average load for a reducer (in bytes):
set hive.exec.reducers.bytes.per.reducer=<number>
In order to limit the maximum number of reducers:
set hive.exec.reducers.max=<number>
In order to set a constant number of reducers:
set mapred.reduce.tasks=<number>
java.lang.OutOfMemoryError: Java heap space
at org.apache.hadoop.hdfs.DFSOutputStream$Packet.<init>(DFSOutputStream.java:209)
at org.apache.hadoop.hdfs.DFSOutputStream.writeChunk(DFSOutputStream.java:1501)
at org.apache.hadoop.fs.FSOutputSummer.writeChecksumChunk(FSOutputSummer.java:173)
at org.apache.hadoop.fs.FSOutputSummer.write1(FSOutputSummer.java:116)
at org.apache.hadoop.fs.FSOutputSummer.write(FSOutputSummer.java:102)
at org.apache.hadoop.fs.FSDataOutputStream$PositionCache.write(FSDataOutputStream.java:54)
at java.io.DataOutputStream.write(DataOutputStream.java:107)
|
偶爾碰到未解決問題，重啟HiveServer2,印證了那句老話，重啟能解決80%以上的問題，但是好景不長，經過長期的觀察，發現是HiveServer進程GC狀況：
到這一步可以斷定有資源沒有釋放, 再看下Heap對象分布：
看到這里我確實找不到招了，HashMap HashTable代碼在Hive源碼遍地都是，壓根無法定位是哪個代碼片段存在內存泄漏
然后我嘗試去官網查下別人是否也碰到過同樣的問題，果然在jira里搜索 “HiveServer2 OutOfMemoryError” ，存在一個Case跟我的情況一模一樣，但Bug是Open狀態，也就是還未解決！！ https://issues.apache.org/jira/browse/HIVE-9893
有問題就解決問題，考慮到HiveServer2是單點，對系統高可用、穩定性都會帶來隱患；於是我想到了一個解決辦法——開啟多個HiveServer2，上層用Haprocxy來轉發請求,再通過服務撥測實時對OOM的節點報警通知，以便研發能第一時間發現問題。但OOM依然存在，治標不治本。
這個Bug一直持續了將近半年，直到最近在調研Spark並計划將Spark取代Mapreduce來提升平台的計算效率時，發現Spark-sql能完美的兼容Hive SQL，同時還提供了ThriftServer(就是SparkHiveServer)，不止於此，由於Spark更好的使用了內存，期執行效率是MR/Hive的10倍以上。
其實就是在Spark集群上執行$SPARK_HOME/sbin/start-thriftserver.sh –master=spark://MASTER:7077 就默認開啟了10000端口，該服務可以取代hiveserver2，如果與HiveServer2在同一台服務器上，可以先shutdown hiveserver2,再啟動spark thriftserver。運行了1個禮拜，服務非常穩定，GC也正常！