Hive中跑MapReduce Job出现OOM问题分析及解决_OopsOutOfMemory的博客-CSDN博客
Hive中跑MapReduce Job出现OOM问题分析及解决
OopsOutOfMemory
于 2014-11-21 20:02:47 发布
28721
收藏
22
分类专栏：
hive
文章标签：
hive
gc
oom
mapreduce
hadoop
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/oopsoom/article/details/41356251
版权
hive
专栏收录该内容
8 篇文章
0 订阅
订阅专栏
一、引子
今天在跑一段很复杂而且涉及数据量10多年的N个表join的长SQL时，发生了OOM的异常。
由于一个map通常配置只有64MB或者128MB，则在Map阶段出现OOM的情况很少见。所以一般发生在reduce阶段。
但是今天这个异常详细的看后，会发现既不是map阶段，也不是reduce阶段，发现不是执行过程，而是driver提交job阶段就OOM了。
Hive中XMLEncoder序列化MapredWork引发OutOfMemoryError
XMLEncoder导致java.lang.OutOfMemoryError: GC overhead limit exceeded
二、概括回顾先概括下，Hive中出现OOM的异常原因大致分为以下几种：
1. Map阶段OOM。2. Reduce阶段OOM。3. Driver提交Job阶段OOM。
Map阶段OOM：1. 发生OOM的几率很小，除非你程序的逻辑不正常，亦或是程序写的不高效，产生垃圾太多。
Reduce阶段OOM：
1. data skew 数据倾斜data skew是引发这个的一个原因。 
key分布不均匀，导致某一个reduce所处理的数据超过预期，导致jvm频繁GC。
2. value对象过多或者过大
某个reduce中的value堆积的对象过多，导致jvm频繁GC。
解决办法：
1. 增加reduce个数，set mapred.reduce.tasks=300，。
2. 在hive-site.xml中设置，或者在hive shell里设置 set  mapred.child.java.opts = -Xmx512m
   或者只设置reduce的最大heap为2G，并设置垃圾回收器的类型为并行标记回收器，这样可以显著减少GC停顿，但是稍微耗费CPU。
   set mapred.reduce.child.java.opts=-Xmx2g -XX:+UseConcMarkSweepGC;
3. 使用map join 代替 common join. 可以set hive.auto.convert.join = true
4. 设置 hive.optimize.skewjoin = true 来解决数据倾斜问题
Driver提交job阶段OOM：
 job产生的执行计划的条目太多，比如扫描的分区过多，上到4k-6k个分区的时候，并且是好几张表的分区都很多时，这时做join。
究其原因，是 因为序列化时，会将这些分区，即hdfs文件路径，封装为Path对象，这样，如果对象太多了，而且Driver启动的时候设置的heap size太小，则会导致在Driver内序列化这些MapRedWork时，生成的对象太多，导致频繁GC，则会引发如下异常:
java.lang.OutOfMemoryError: GC overhead limit exceeded
at sun.nio.cs.UTF_8.newEncoder(UTF_8.java:53)
at java.beans.XMLEncoder.createString(XMLEncoder.java:572)
三、诊断问题
如何诊断到了问题：
在网上搜异常，在Hive的IRA发现一个issues，和我的情况类似：
HIVE-2988
问题描述：
Use of XMLEncoder to serialize MapredWork causes OOM in hive cli
When running queries on tables with 6000 partitions, hive cli if configured with 128M runs into OOM. Heapdump showed 37MB occupied by one XMLEncoder object while the MapredWork was 500K which is highly inefficient. We should switch to using something more efficient like XStream.
比较相近的解释：
I ran with 128M to investigate the OOM. We have resorted to running with 1G as XmX because we keep hitting OOM with bigger tables in hive. There were other things that contributed to the memory usage - mostly Path objects because of the higher number of partitions. But they are absolutely needed. XMLEncoder is something that created too much garbage in a very short span and caused GC. That would be something easy to change/fix without having to touch the core logic.
We should be looking at fixing the root cause of the problem instead of keeping on increasing the memory requirements. Ours is a highly multi-tenant system and there are lot of other programs(pig,etc) running too in the gateway. So running with a lower memory(256-512MB) will help.
Found two other reports of this issue:
http://mail-archives.apache.org/mod_mbox/hive-user/201106.mbox/%3CBANLkTik4THLNkxV87UygvqhoLri3UL9R3Q@mail.gmail.com%3E
https://issues.apache.org/jira/browse/HIVE-1316
This fix increased the max heap size of CLI client and disabled GC overhead limit.
于是亲自确认一下问题处在哪个地方：
因为这段复杂的sql有22个job，每次到第20个job的时候就会出现oom，所以我特意将数据置空，调试这在shell下跑。
发现跑到第20个job，扫描的正是扫描了14年的注册表，推断是分区太多，造成的序列化时对象太多OOM。
以下是调试图：
将查询计划打印出来，会发现很大，主要是因为有一个注册表，扫描了近14年的历史数据，14×365 = 5110 个分区。除去早些年份数据的不完整性，大约3138个分区。
每个分区都会生成一个Path对象，这样仅仅是这一个表，生成的查询计划被序列化为对象会耗去大半内存，如果在和其它的表好几年的数据继续做join的话，又会耗去更多内存来序列化成对象，这样就会频繁GC，GC不出来，就会抛出OOM的异常。
仅仅是一个查询，都打印出了25MB，说明扫描的数据量是在是太多了。
explain extended a_complex_hql_query > /app/hadoop/shengli/large_plan
du -sh large_plan
25M large_plan
详细日志如下：
2014-11-21 13:13:28,334 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Hadoop job information for Stage-23: number of mappers: 12; number of reducers: 1
2014-11-21 13:13:28,354 INFO [Thread-2] AbstractBaseAction$StreamDrainer - 2014-11-21 13:13:28,347 Stage-23 map = 50%, reduce = 0%, Cumulative CPU 42.04 sec
2014-11-21 13:13:48,370 INFO [Thread-2] AbstractBaseAction$StreamDrainer - 2014-11-21 13:13:48,363 Stage-23 map = 100%, reduce = 33%, Cumulative CPU 262.39 sec
2014-11-21 13:14:29,228 INFO [Thread-2] AbstractBaseAction$StreamDrainer - 2014-11-21 13:14:29,222 Stage-23 map = 100%, reduce = 69%, Cumulative CPU 262.39 sec
2014-11-21 13:14:49,248 INFO [Thread-2] AbstractBaseAction$StreamDrainer - 2014-11-21 13:14:49,239 Stage-23 map = 100%, reduce = 92%, Cumulative CPU 324.73 sec
2014-11-21 13:15:11,952 INFO [Thread-2] AbstractBaseAction$StreamDrainer - 2014-11-21 13:15:11,944 Stage-23 map = 100%, reduce = 100%, Cumulative CPU 360.1 sec
2014-11-21 13:15:36,740 INFO [Thread-2] AbstractBaseAction$StreamDrainer - 2014-11-21 13:15:36,734 Stage-23 map = 100%, reduce = 100%, Cumulative CPU 360.1 sec
2014-11-21 13:15:36,741 INFO [Thread-2] AbstractBaseAction$StreamDrainer - MapReduce Total cumulative CPU time: 6 minutes 0 seconds 100 msec
2014-11-21 13:15:36,749 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Ended Job = job_201411141019_68657
2014-11-21 13:15:40,306 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Launching Job 20 out of 21
2014-11-21 13:15:42,162 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Number of reduce tasks not specified. Estimated from input data size: 252
2014-11-21 13:15:42,163 INFO [Thread-2] AbstractBaseAction$StreamDrainer - In order to change the average load for a reducer (in bytes):
2014-11-21 13:15:42,163 INFO [Thread-2] AbstractBaseAction$StreamDrainer - set hive.exec.reducers.bytes.per.reducer=<number>
2014-11-21 13:15:42,163 INFO [Thread-2] AbstractBaseAction$StreamDrainer - In order to limit the maximum number of reducers:
2014-11-21 13:15:42,163 INFO [Thread-2] AbstractBaseAction$StreamDrainer - set hive.exec.reducers.max=<number>
2014-11-21 13:15:42,163 INFO [Thread-2] AbstractBaseAction$StreamDrainer - In order to set a constant number of reducers:
2014-11-21 13:15:42,163 INFO [Thread-2] AbstractBaseAction$StreamDrainer - set mapred.reduce.tasks=<number>
2014-11-21 13:16:40,377 INFO [Thread-2] AbstractBaseAction$StreamDrainer - java.lang.OutOfMemoryError: GC overhead limit exceeded
2014-11-21 13:16:40,378 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at sun.nio.cs.UTF_8.newEncoder(UTF_8.java:53)
2014-11-21 13:16:40,378 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.createString(XMLEncoder.java:572)
2014-11-21 13:16:40,378 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.outputValue(XMLEncoder.java:543)
2014-11-21 13:16:40,378 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.outputStatement(XMLEncoder.java:682)
2014-11-21 13:16:40,378 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.outputStatement(XMLEncoder.java:687)
2014-11-21 13:16:40,378 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.outputValue(XMLEncoder.java:552)
2014-11-21 13:16:40,378 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.outputStatement(XMLEncoder.java:682)
2014-11-21 13:16:40,378 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.outputStatement(XMLEncoder.java:687)
2014-11-21 13:16:40,379 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.outputValue(XMLEncoder.java:552)
2014-11-21 13:16:40,379 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.outputStatement(XMLEncoder.java:682)
2014-11-21 13:16:40,379 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.outputStatement(XMLEncoder.java:687)
2014-11-21 13:16:40,379 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.outputValue(XMLEncoder.java:552)
2014-11-21 13:16:40,379 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.outputStatement(XMLEncoder.java:682)
2014-11-21 13:16:40,379 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.outputStatement(XMLEncoder.java:687)
2014-11-21 13:16:40,379 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.outputValue(XMLEncoder.java:552)
2014-11-21 13:16:40,380 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.outputStatement(XMLEncoder.java:682)
2014-11-21 13:16:40,380 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.outputStatement(XMLEncoder.java:687)
2014-11-21 13:16:40,380 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.outputValue(XMLEncoder.java:552)
2014-11-21 13:16:40,380 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.flush(XMLEncoder.java:398)
2014-11-21 13:16:40,380 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at java.beans.XMLEncoder.close(XMLEncoder.java:429)
2014-11-21 13:16:40,380 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at org.apache.hadoop.hive.ql.exec.Utilities.serializeMapRedWork(Utilities.java:532)
2014-11-21 13:16:40,380 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at org.apache.hadoop.hive.ql.exec.Utilities.setMapRedWork(Utilities.java:376)
2014-11-21 13:16:40,381 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at org.apache.hadoop.hive.ql.exec.ExecDriver.execute(ExecDriver.java:418)
2014-11-21 13:16:40,381 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at org.apache.hadoop.hive.ql.exec.MapRedTask.execute(MapRedTask.java:138)
2014-11-21 13:16:40,381 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at org.apache.hadoop.hive.ql.exec.Task.executeTask(Task.java:144)
2014-11-21 13:16:40,381 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at org.apache.hadoop.hive.ql.exec.TaskRunner.runSequential(TaskRunner.java:57)
2014-11-21 13:16:40,381 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at org.apache.hadoop.hive.ql.Driver.launchTask(Driver.java:1355)
2014-11-21 13:16:40,381 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at org.apache.hadoop.hive.ql.Driver.execute(Driver.java:1139)
2014-11-21 13:16:40,381 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at org.apache.hadoop.hive.ql.Driver.run(Driver.java:945)
2014-11-21 13:16:40,381 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at org.apache.hadoop.hive.cli.CliDriver.processLocalCmd(CliDriver.java:259)
2014-11-21 13:16:40,381 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at org.apache.hadoop.hive.cli.CliDriver.processCmd(CliDriver.java:216)
2014-11-21 13:16:40,381 INFO [Thread-2] AbstractBaseAction$StreamDrainer - at org.apache.hadoop.hive.cli.CliDriver.processLine(CliDriver.java:413)
2014-11-21 13:16:40,381 INFO [Thread-2] AbstractBaseAction$StreamDrainer - FAILED: Execution Error, return code -101 from org.apache.hadoop.hive.ql.exec.MapRedTask
2014-11-21 13:16:40,382 INFO [Thread-2] AbstractBaseAction$StreamDrainer - MapReduce Jobs Launched:
2014-11-21 13:16:40,382 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 0: Map: 33 Reduce: 5 Cumulative CPU: 903.59 sec HDFS Read: 4225680985 HDFS Write: 123129169 S
UCCESS
2014-11-21 13:16:40,382 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 1: Map: 192 Reduce: 4 Cumulative CPU: 3215.94 sec HDFS Read: 3036813878 HDFS Write: 322647287
SUCCESS
2014-11-21 13:16:40,382 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 2: Map: 52 Reduce: 4 Cumulative CPU: 1314.04 sec HDFS Read: 3278902794 HDFS Write: 435711878
SUCCESS
2014-11-21 13:16:40,382 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 3: Map: 959 Reduce: 70 Cumulative CPU: 55831.24 sec HDFS Read: 69728403753 HDFS Write: 457377
8468 SUCCESS
2014-11-21 13:16:40,382 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 4: Map: 154 Reduce: 1 Cumulative CPU: 1809.45 sec HDFS Read: 483233734 HDFS Write: 25999761 S
UCCESS
2014-11-21 13:16:40,382 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 5: Map: 84 Reduce: 6 Cumulative CPU: 2466.01 sec HDFS Read: 5618486947 HDFS Write: 1649704865
SUCCESS
2014-11-21 13:16:40,382 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 6: Map: 450 Reduce: 55 Cumulative CPU: 22239.14 sec HDFS Read: 54635746333 HDFS Write: 728231
5124 SUCCESS
2014-11-21 13:16:40,382 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 7: Map: 359 Reduce: 27 Cumulative CPU: 14699.06 sec HDFS Read: 26702083597 HDFS Write: 236403
3090 SUCCESS
2014-11-21 13:16:40,382 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 8: Map: 83 Reduce: 6 Cumulative CPU: 2410.03 sec HDFS Read: 5514015601 HDFS Write: 628742985
SUCCESS
2014-11-21 13:16:40,382 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 9: Map: 84 Reduce: 6 Cumulative CPU: 2200.0 sec HDFS Read: 5618486947 HDFS Write: 853325331 S
UCCESS
2014-11-21 13:16:40,383 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 10: Map: 365 Reduce: 27 Cumulative CPU: 13274.58 sec HDFS Read: 27143622450 HDFS Write: 29912
35104 SUCCESS
2014-11-21 13:16:40,383 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 11: Map: 959 Reduce: 70 Cumulative CPU: 55145.65 sec HDFS Read: 69728403753 HDFS Write: 43358
51625 SUCCESS
2014-11-21 13:16:40,383 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 12: Map: 172 Reduce: 1 Cumulative CPU: 1561.64 sec HDFS Read: 945050606 HDFS Write: 40445679
SUCCESS
2014-11-21 13:16:40,383 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 13: Map: 260 Reduce: 9 Cumulative CPU: 5965.67 sec HDFS Read: 8639664681 HDFS Write: 38277094
9 SUCCESS
2014-11-21 13:16:40,383 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 14: Map: 212 Reduce: 15 Cumulative CPU: 7573.68 sec HDFS Read: 14849298755 HDFS Write: 109518
4574 SUCCESS
2014-11-21 13:16:40,383 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 15: Map: 16 Reduce: 2 Cumulative CPU: 981.37 sec HDFS Read: 1660614485 HDFS Write: 795259370
SUCCESS
2014-11-21 13:16:40,383 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 16: Map: 27 Reduce: 3 Cumulative CPU: 1357.34 sec HDFS Read: 2991246795 HDFS Write: 238860030
1 SUCCESS
2014-11-21 13:16:40,383 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 17: Map: 70 Reduce: 5 Cumulative CPU: 2138.48 sec HDFS Read: 4573808778 HDFS Write: 290957162
1 SUCCESS
2014-11-21 13:16:40,383 INFO [Thread-2] AbstractBaseAction$StreamDrainer - Job 18: Map: 12 Reduce: 1 Cumulative CPU: 360.1 sec HDFS Read: 853346317 HDFS Write: 705875733 SU
CCESS
三、Driver阶段OOM解决方案：
原因找到了，是因为扫描的表的分区太多，上到3千到6千个分区，这样在对计划进行序列化时，仅仅是路径对象Path就会耗去大半Driver，如果Driver设置的heap太小，甚至都会OOM。
解决思路：
1.  减少分区数量，将历史数据做成一张整合表，做成增量数据表，这样分区就很少了。
2. 调大Hive CLI Driver的heap size, 默认是256MB，调节成512MB或者更大。
具体做法是在bin/hive bin/hive-config里可以找到启动CLI的JVM OPTIONS。
这里我们设置
export HADOOP_HEAPSIZE=512
我的解决方法是，双管齐下。
即做成了整合，方便使用，又调节了Hive CLI Driver的heap size，保证线上的运行稳定。
四、总结：
  写在结尾，今天只顾折腾这个问题了，遇到这种问题：
  一是HiveQL的写法上，尽量少的扫描同一张表，并且尽量少的扫描分区。扫太多，一是job数多，慢，二是耗费网络资源，慢。
  二是Hive的参数调优和JVM的参数调优，尽量在每个阶段，选择合适的jvm max heap size来应对OOM的问题。
——EOF——
原创文章，转载请注明出自：
http://blog.csdn.net/oopsoom/article/details/41356251
OopsOutOfMemory
关注
关注
点赞
22
收藏
打赏
评论
Hive中跑MapReduce Job出现OOM问题分析及解决
一、引子今天在跑一段很复杂而且涉及数据量10年的N个表join的长SQL时，发生了OOM的异常。由于一个map通常配置只有64MB或者128MB，则在Map阶段出现OOM的情况很少见。所以一般发生在reduce阶段。但是今天这个异常详细的看后，会发现既不是map阶段，也不是reduce阶段，发现不是执行过程，而是driver提交job阶段就OOM了。Hive中XMLEncoder序列化Mapred
复制链接
扫一扫
专栏目录
使用Hive SQL插入动态分区的Orc表OOM异常分析
小陌成长之路
06-18
590
执行语句‘insert into table xxx partition(dt) select …’ 向ORC格式的表中插入数据时报错
运行MapReduce的时候OOM
dacoolbaby的专栏
12-13
255
出错如下：
java.lang.OutOfMemoryError: Java heap space
at org.apache.hadoop.mapred.MapTask$MapOutputBuffer.<init>(MapTask.java:498)
at org.apache.hadoop.mapred.MapTask.run(Map...
参与评论
您还未登录，请先
登录
后发表或查看评论
[hive]return code -101 from org.apache.hadoop.hive.ql.exec.mr.MapRedTask. GC overhead limit exceeded
最新发布
胖胖的博客
11-10
413
2、group by 数据倾斜。1、调大reduce个数。
Hive运行报错：Java heap space
|银河就这么大|的博客
07-05
1842
后来去hive的环境配置文件hive-env.sh里面（第40行）配置heap大小，这里我配置了2G，重新运行无报错。
hive sql性能调优参数设置
飞翔的牛
03-11
1470
set hive.map.aggr=true;
set hive.optimize.skewjoin=true;
set hive.groupby.skewindata=true;
set hive.optimize.skewjoin=true;
set hive.map.aggr=true;
set mapred.child.java.opts=-Xmx8000m;
set mapreduce...
Hive的parquet表导入多分区时OOM问题
善皮之的博客
05-12
661
场景
有一个parquet的表table_A，然后创建一个多分区表table_B
A表的数据大小大约是1.21G（parquet压缩之后的大小，数据记录大概有270W条。Table_B的分区是根据年、月、日三个条件进行分区的。
insert overwrite table table_B partition (year,month,day) select id,name,... B_year as...
hadoop报错总结02
李孟的博客
02-13
735
hadoop报错总结01:https://blog.csdn.net/qq_19968255/article/details/82803768
1.当脚本在运行时报错信息如下：
Examining task ID: task_201201061122_0007_m_000002 (and more) from job job_201201061122_0007
Exception in th...
大数据开发之Hive篇11-Hive分析函数及窗口语句
只是甲的博客
01-04
634
备注:
Hive 版本 2.1.1
文章目录一.row_number、rank、dense_rank二.lag、lead三.first_value、last_value四.percent_rank、CUME_DIST五.ntile参考
测试数据
-- create table
create table dept
deptno int,
dname varchar(14),
loc varchar(13)
);
insert into dept(deptno, dname, loc)
HashMap大数据量扩容OOM问题
weixin_34233856的博客
07-31
2594
2019独角兽企业重金招聘Python工程师标准>>>
...
Hive Map 端OOM 异常
diaokaijing6889的博客
08-24
332
怪异现象：数据量不大，且不是Reduce端OOM,是Map端OOM
Map Task运行的时候数据流中包含了非法字符例如：EOF、NOP等东西，导致BufferedReader读取和StreamDecoder解码出错，
进一步导致了OOM，需要剔除这些记录，可以通过length来限制。
PS:当然，这只是Map 端OOM出现的其中一种原因，仅供参考。
转载于:h...
java map 内存_内存整了个map处理数据，但是太大了，经常OOM
weixin_39603609的博客
02-12
843
阿里给的一个笔试题，要我分析一个10G的文本，当时在线面试，没多想，随便写了写。现在自己写了一下，问题蛮多的。我有三个4G的样本，都是我写程序随机生成的，字符集合不同，有的字符集很广，这样就会导致OOMpublicclassSolution{mapwordsCountmap=newHashmap<>();mapcomputeWordsFromBufferReadFile...
hive 导出数据到csv报错 java.lang.OutOfMemoryError: Java heap space
yy的博客
11-02
486
问题:
导出hive外部表到本地csv文件,报错 java.lang.OutOfMemoryError: Java heap space
导出语句: hive -e "set hive.cli.print.header=true;select * from dwd.dwd_fact_issue_issue_and_reply" | sed 's/[\t]/,/g' > /opt/dwd.dwd_fact_issue_issue_and_reply.csv
解决方法:
...
java.lang.OutOfMemoryError: Java heap space
俊辑的地盘
06-01
1485
三种可能导致OutOfMemoryError。
第一，此JVM有真实的内存泄漏，导致此JVM堆在内部实现时产生了一个Bug。
第二，你没有为你的应用程序运行时给予足够多的可用内存。这种情况，有两种可能的方案，或者增加 JVM堆可用大小，或者减少你的应用程序所需的内存总量。提高JVM可用堆大小可以简单的使用JVM的 -Xmx 参数。假如你将此参数设置尽可能的大（可用内存极限不要超过系统物理
使用hive报 return code 2 from org.apache.hadoop.hive.ql.exec.mr.MapRedTask解决方法
热门推荐
wangxizhen123的博客
04-10
1万+
当我使用hive进行如下查询时 select * from t_t inner join t_te on t_t.id=t_te.id;出现如下错误：Query ID = root_20180410193117_e9d36b57-54ce-4ad5-a48c-df876f449de1
Total jobs = 1
18/04/10 19:31:20 WARN conf.Configuration:...
记一则罕见的hive字段值异常引起map阶段的OOM
weixin_34007020的博客
05-19
137
前段时间遇到了一个很诡异的发生的Map阶段的OOM异常，花了些时间才找到原因，这个简要记录一下。 先看log。 节点一的TaskTracker的log：节点二的TaskTracker的log：节点三的TaskTracker的log：其他节点的TaskTracker中的log都和slave4的一样的：故障分析： OOM是一个比较常见的故障，其中发生在reduce阶段最为常见，最有...
android bitmap oom 最新处理办法,【移动开发】Android中图片过大造成内存溢出，OOM（OutOfMemory）异常解决方法...
weixin_30068505的博客
05-25
247
当我们在做项目过程中，一遇到显示图片时，就要考虑图片的大小，所占内存的大小，原因就是Android分配给Bitmap的大小只有8M,试想想我们用手机拍照，普通的一张照片不也得1M以上，所以android处理图片时不得不考虑图片过大造成的内存异常。那时候只是简单地缓存图片到本地 然后将图片进行压缩，但是感觉这个问题没有很好的解决办法，只是减小了发生的几率这里，我将前辈们解决的方法重新整理一番,方便自...
频繁GC导致OOM内存溢出的问题排查
阿拉的博客
08-28
986
频繁GC导致OOM内存溢出的问题排查1.问题发现2. 导出内存dump3.用mat分析dump下载mat配置mat运行mat4. 分析5. 解决方案
1.问题发现
日志中打印如下，发现频繁GC并导致OOM
[2021-08-25 15:14:33, 948] [ERROR] [] [] [DubboServerHandler-74.0.2.41:11306-thread-488]- org.apache.dubbo.rpc.filter.ExceptionFilter$ExceptionListener.o
详细讲解MapReduce过程
专注于后端开发，时常接触大数据 、人工智能等
10-10
1139
关于整理
此文百分之七十摘自我认为讲的很清楚的博客，我都贴了地址，很感谢这些博主的无私奉献！我再将一些自己的实例代码和知识点的补充加入进去，希望能更好的理解mapreduce的整个过程。
从启动和资源调度来看MapReduce过程
首先-先了解一下必知概念
From：MapReduce工作原理图文详解，JobTracker和TaskTracker概述
客户端（Client）：编写...
hive参数配置调优
manweizhizhuxia的博客
03-16
2592
参数设置方式
1、配置文件 （全局有效）
2、命令行参数（对 hive 启动实例有效）
3、命令行参数声明 （对 hive 的连接 session 有效）
作业设置
set mapreduce.job.name=${fileName}_0; --作业名称set mapreduce.job.priorite=NORMAL; --作业优先级set mapreduce.job.queuename=default; --作业队列
适当加大map
set mapreduce.input.fileinputform
HIVE SQL运行内存溢出OOM（MR/TEZ）：java.lang.OutOfMemoryError: GC overhead limit exceeded
wangkuangood3200的专栏
02-03
1894
【现象】
今天用户反馈运行HQL作业失败，报OOM，于是来排查该问题
查看tez，intialmap大量失败，重试失败。
进入具体一个task，报错指向OOM，溢出原因是在单个map中产生大量对象导致。
HQL语句查询借据号——逾期金额信息，借据号重复率低，导致map维护key（借据号）-value（逾期金额信息）的内存超过了JVM配置的map进程内存大小限制，从而内存溢出。
【原因】
对于group by语句，在MR中，当数据量很大，且没有map聚合时，所有的记录将会被..
“相关推荐”对你有帮助么？
非常没帮助
没帮助
一般
有帮助
非常有帮助
提交
©️2022 CSDN
皮肤主题：大白
设计师：CSDN官方博客
返回首页
OopsOutOfMemory
CSDN认证博客专家
CSDN认证企业博客
码龄9年
暂无认证
80
原创
7万+
周排名
124万+
总排名
77万+
访问
等级
6662
积分
549
粉丝
103
获赞
81
评论
192
收藏
私信
关注
热门文章
Spark SQL 源码分析系列文章
31159
Spark Hadoop集群部署与Spark操作HDFS运行详解---Spark学习笔记10
28820
Hive中跑MapReduce Job出现OOM问题分析及解决
28721
Scala的foldLeft和foldRight
27603
Lateral View用法 与 Hive UDTF explode
26998
分类专栏
Spark SQL源码分析系列
11篇
spark
41篇
hive
8篇
scala
8篇
machine learning
2篇
shark
3篇
java
4篇
hadoop
3篇
监控
2篇
mahout
hbase
alogrithm
storm
kafka
flume
etl
1篇
ubuntu
1篇
mesos
nio
tachyon
1篇
docker
1篇
cubert
4篇
helix
1篇
最新评论
Spark Executor Driver资源调度小结
Lii_:
学到的很多，谢谢
jvm调优--查找最耗CPU的代码
万物皆字节:
pid 不是线程id，是进程（Process）id哦亲
Docker 安装 on Mac OS X
Tisfy:
真棒！就像：天涯静处无征战，兵气销为日月光。
Scala的foldLeft和foldRight
书忆江南:
补充一下，通俗点说两个括号中的参数是这样：foldLeft(初始值)(如何把多个值从右到左折叠成一个值的函数表达式)，两个括号存放多个传入参数，而不是一个括号放所有传入参数，是用到了“柯里化”
Spark SQL源码分析之核心流程
Leagues:
赞!
您愿意向朋友推荐“博客详情页”吗？
强烈不推荐
不推荐
一般般
推荐
强烈推荐
提交
最新文章
Apache Helix简介
HDFS之Node角色
LinkedIn Cubert 实践指南
2015年9篇
2014年72篇
目录
目录
分类专栏
Spark SQL源码分析系列
11篇
spark
41篇
hive
8篇
scala
8篇
machine learning
2篇
shark
3篇
java
4篇
hadoop
3篇
监控
2篇
mahout
hbase
alogrithm
storm
kafka
flume
etl
1篇
ubuntu
1篇
mesos
nio
tachyon
1篇
docker
1篇
cubert
4篇
helix
1篇
目录
评论
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
查看更多评论
打赏作者
OopsOutOfMemory
你的鼓励将是我创作的最大动力
¥2
¥4
¥6
¥10
¥20
输入1-500的整数
余额支付
(余额：-- )
扫码支付
扫码支付：¥2
获取中
扫码支付
您的余额不足，请更换扫码支付或充值
打赏作者
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额
抵扣说明：
1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。 2.余额无法直接购买下载，可以购买VIP、C币套餐、付费专栏及课程。
余额充值