&nbsp>&nbsp
&nbsp>&nbsp
&nbsp>&nbsp
记一次hive的内存溢出(OutOfMemoryError: Java heap space)排查
摘要：转载请注明出处:http://blog.csdn.net/gklifg/article/details/刚刚从java组转岗找数据组,学习大数据的知识,开发语言也从java转到python新奇之外也遇到了诸多问题,其中最令我头疼的就是在hive上的统计任务总是三天两头地报告OutOfMemory一开始因为有别的同事的任务干扰,我以为是计算资源不够导致的,但后来把任务转移到了另一个集群后,问题仍然存在,让我百思不得其解。问题的具体描述如下:统计逻辑使用pytho
转载请注明出处:http://blog.csdn.net/gklifg/article/details/
刚刚从java组转岗找数据组,学习大数据的知识,开发语言也从java转到python新奇之外也遇到了诸多问题,其中最令我头疼的就是在hive上的统计任务总是三天两头地报告OutOfMemory一开始因为有别的同事的任务干扰,我以为是计算资源不够导致的,但后来把任务转移到了另一个集群后,问题仍然存在,让我百思不得其解。
问题的具体描述如下:
统计逻辑使用python&pyhs2连接hive,执行HQL查询。单独执行时都很顺利,定时执行时,基本上4天中必有一天会挂掉,报OutOfMemory:&Java heap space,这时候一般会重启hiveServer2,于是各个问题就又不见了,直到下一个4天。
现在看起来一切都很清晰,但是当身处问题之中的时候,很多噪音是会扰乱视线,比如说不定期的其他任务(spark、mapreduce)插入,因为其他问题引起的其他同事手动重启hiveServer2,这些都会扰乱整个问题的外在表现形式。以至于很难看出内存溢出是有一个明显的周期的。
由于是OutOfMemory,想来想去也没什么好的办法,只能监控一下jvm,看看那时候到底发生了什么。不知什么问题在AWS上没法使用jmap -heap,无奈就先使用jstat
监控语句如下:
jstat -gcutil [进程号] 5000 --每5秒打印一次jvm各个内存区的状态
另外找了一个监控系统内存的语句:
vmstat | sed -n '/[0-9]/p'
设定两个语句将结果输出到文件里后就开始等待问题出现,因为本人也是现学现卖,对于jvm的了解非常浅,当时发现jvm的永久代空间很开变成近100%,但不知道是不是有问题。
过了一个周末,HIVE果然还是挂了,查日志的时候发现当时的jvm内存是这样的:
S0 & & &S1 & & &E & & & & &O & & & & & P & & & & YGC & & &YGCT & & &FGC & & & & FGCT & & & &GCT
0.00 & 0.00 100.00 100.00 &99.37 &14086 & 39.094 & 13348 &
& 0.00 & 0.00 100.00 100.00 &99.37 &14086 & 39.094 & 13348 &
& 0.00 & 0.00 100.00 100.00 &99.37 &14086 & 39.094 & 13348 &
& 0.00 & 0.00 100.00 100.00 &99.37 &14086 & 39.094 & 13348 &
& 0.00 & 0.00 100.00 100.00 &99.37 &14086 & 39.094 & 13348 &
& 0.00 & 0.00 100.00 100.00 &99.37 &14086 & 39.094 & 13348 &
& 0.00 & 0.00 100.00 100.00 &99.37 &14086 & 39.094 & 13349 &
& 0.00 & 0.00 100.00 100.00 &99.37 &14086 & 39.094 & 13349 &
& 0.00 & 0.00 100.00 100.00 &99.37 &14086 & 39.094 & 13349 &
& 0.00 & 0.00 100.00 100.00 &99.37 &14086 & 39.094 & 13349 &
可以看到新生代和老年代都已经爆满,永久代几乎爆满,jvm一直在做full GC,但是没有效果,各个内存区都被占用了。这种情况发生后同事直接重启了hiveServer2,我没有来的及查看一下当时堆中的对象信息,不知道有没有什么有价值的信息在里面。就现在的日志来看,我发现老年代和持久代的内存只要上去了,就再没有下降过,而当这两块区域饱和后,新生代也出现了这种现象。这时候忽然意识到,是有什么资源没释放吧!?
一看代码,果然,有两个脚本pyhs2的连接没有关闭!
java里面连接都是框架管理的,平时没管过,换到python来,忽视了这个重要的步骤,血的教训啊,连接一定要关闭!另外总的来说这次问题的原因虽然相当低级,但是排查用到的手段和思维方式给了我很多收获,自责的同时也有战胜困难的喜悦,记录下来,自勉。
以上是的内容，更多
的内容，请您使用右上方搜索功能获取相关信息。
若你要投稿、删除文章请联系邮箱：zixun-group@service.aliyun.com,工作人员会在五个工作日内给你回复。
云服务器 ECS
可弹性伸缩、安全稳定、简单易用
&40.8元/月起
预测未发生的攻击
&24元/月起
邮箱低至5折
推荐购买再奖现金，最高25%
&200元/3月起
你可能还喜欢
你可能感兴趣
阿里云教程中心为您免费提供
记一次hive的内存溢出(OutOfMemoryError: Java heap space)排查相关信息，包括
的信息，所有记一次hive的内存溢出(OutOfMemoryError: Java heap space)排查相关内容均不代表阿里云的意见！投稿删除文章请联系邮箱：zixun-group@service.aliyun.com，工作人员会在五个工作日内答复
售前咨询热线
支持与服务
资源和社区
关注阿里云
InternationalHive一些参数设置 - cfox - 博客园
随笔 - 50, 文章 - 8, 评论 - 0, 引用 - 0
在使用union all的时候，系统资源足够的情况下，为了加快hive处理速度，可以设置如下参数实现并发执行
set mapred.job.priority=VERY_HIGH;
set hive.exec.parallel=
&设置map reduce个数
-- 设置map capacity
set mapred.job.map.capacity=2000;
set mapred.job.reduce.capacity=2000;
-- 设置每个reduce的大小
set hive.exec.reducers.bytes.per.reducer=;
-- 直接设置个数
set mapred.reduce.tasks = 15;
&设置任务名称
-- 设置名称
set mapred.job.name=my_job_{DATE};
&Hive文件合并
-- 设置文件合并
set abaci.is.dag.job=
set hive.merge.mapredfiles=
set mapred.combine.input.format.local.only=
set hive.merge.smallfiles.avgsize=;
-- 在map only的情况下，如上的参数如果没有生效，可以设置如下
-- 在HQL的最外层增加distribute by rand()
select * from XXX distribute by rand()
use namespace udw_
set mapred.job.name=job_name_{DATE};
set hive.mapred.mode=
set mapred.reduce.tasks = 600;
set hive.exec.dynamic.partition.mode=
set hive.exec.dynamic.partition=
set hive.exec.compress.output=
set mapred.output.compress=
set mapred.output.compression.codec=org.apache.hadoop.io.compress.LzoC
dfs.block.size
& 决定HDFS文件block数量的多少(文件个数),它会间接的影响Job Tracker的调度和内存的占用(更影响内存的使用),
mapred.map.tasks.speculative.execution=true&
mapred.reduce.tasks.speculative.execution=true
这是两个推测式执行的配置项,默认是true
所谓的推测执行，就是当所有task都开始运行之后，Job Tracker会统计所有任务的平均进度，如果某个task所在的task node机器配
置比较低或者CPU load很高（原因很多），导致任务执行比总体任务的平均执行要慢，此时Job Tracker会启动一个新的任务
（duplicate task），原有任务和新任务哪个先执行完就把另外一个kill掉，这也是我们经常在Job Tracker页面看到任务执行成功，但
是总有些任务被kill，就是这个原因。
mapred.child.java.opts
一般来说，都是reduce耗费内存比较大，这个选项是用来设置JVM堆的最大可用内存，但不要设置过大，如果超过2G(这是数字有
待考证)，就应该考虑一下优化程序。
Input Split的大小，决定了一个Job拥有多少个map，默认64M每个Split，如果输入的数据量巨大，那么默认的64M的block会有特
别多Map Task，集群的网络传输会很大，给Job Tracker的调度、队列、内存都会带来很大压力。
mapred.min.split.size
这个配置决定了每个Input Split 的最小值,也间接决定了一个job的map数量
HDFS块大小是在job写入时决定的,而分片的大小,是由三个元素决定的(在3各种去最大的那个)
(1) 输入的块数 (2) Mapred.min.split.size (3) Job.setNumMapTasks()
mapred.compress.map.output
压缩Map的输出，这样做有两个好处：a)压缩是在内存中进行，所以写入map本地磁盘的数据就会变小，大大减少了本地IO次数b) Reduce从每个map节点copy数据，也会明显降低网络传输的时间注：数据序列化其实效果会更好，无论是磁盘IO还是数据大小，都会明显的降低。
io.sort.mb以MB为单位，默认100M，这个值比较小map节点没运行完时，内存的数据过多，要将内存中的内容写入洗盘，这个设置就是设置内存缓冲的大小，在suffle之前这个选项定义了map输出结果在内存里占用buffer的大小，当buffer达到某个阈值(后面那条配置)，会启动一个后台线程来对buffer
的内容进行排序，然后写入本地磁盘(一个spill文件)
根据map输出数据量的大小，可以适当的调整buffer的大小，注意是适当的调整，并不是越大越好，假设内存无限大，
io.sort.mb=1024(1G), 和io.sort.mb=300 (300M)，前者未必比后者快：（1）1G的数据排序一次（2）排序3次，每次300MB一定是后者快（归并排序）
io.sort.spill.percent这个值就是上面提到的buffer的阈值，默认是0.8，既80%，当buffer中的数据达到这个阈值，后台线程会起来对buffer中已有的数
据进行排序，然后写入磁盘，此时map输出的数据继续往剩余的20% buffer写数据，如果buffer的剩余20%写满，排序还没结束，
map task被block等待。如果你确认map输出的数据基本有序，排序时间很短，可以将这个阈值适当调高，更理想的，如果你的map输出是有序的数据，那
么可以把buffer设的更大，阈值设置为1.
Io.sort.factor同时打开的文件句柄的数量，默认是10当一个map task执行完之后，本地磁盘上(mapred.local.dir)有若干个spill文件，map task最后做的一件事就是执行merge sort，
把这些spill文件合成一个文件（partition，combine阶段）。执行merge sort的时候，每次同时打开多少个spill文件，就是由io.sort.factor决定的。打开的文件越多，不一定merge sort就越
快，也要根据数据情况适当的调整。注：merge排序的结果是两个文件，一个是index，另一个是数据文件，index文件记录了每个不同的key在数据文件中的偏移量（即partition）。在map节点上，如果发现map所在的子节点的机器io比较重，原因可能是io.sort.factor这个设置的比较小，io.sort.factor设置小的
话，如果spill文件比较多，merge成一个文件要很多轮读取操作，这样就提升了io的负载。io.sort.mb小了，也会增加io的负载。如果设置了执行combine的话，combine只是在merge的时候，增加了一步操作，不会改变merge的流程，所以combine不会减少
或者增加文件个数。另外有个min.num.spills.for.combine的参数，表示执行一个merge操作时，如果输入文件数小于这个数字，就
不调用combiner。如果设置了combiner，在写spill文件的时候也会调用，这样加上merge时候的调用，就会执行两次combine。
提高Reduce的执行效率，除了在Hadoop框架方面的优化，重点还是在代码逻辑上的优化.比如：对Reduce接受到的value可能有重
复的，此时如果用Java的Set或者STL的Set来达到去重的目的，那么这个程序不是扩展良好的(non-scalable)，受到数据量的限制，
当数据膨胀，内存势必会溢出
mapred.reduce.parallel.copiesReduce copy数据的线程数量，默认值是5Reduce到每个完成的Map Task 拷贝数据（通过RPC调用），默认同时启动5个线程到map节点取数据。这个配置还是很关键的，
如果你的map输出数据很大，有时候会发现map早就100%了，reduce却在缓慢的变化，那就是copy数据太慢了，比如5个线程
copy 10G的数据，确实会很慢，这时就要调整这个参数，但是调整的太大，容易造成集群拥堵，所以 Job tuning的同时，也是个权
衡的过程，要熟悉所用的数据！mapred.job.shuffle.input.buffer.percent当指定了JVM的堆内存最大值以后，上面这个配置项就是Reduce用来存放从Map节点取过来的数据所用的内存占堆内存的比例，默
认是0.7，既70%，通常这个比例是够了，但是对于大数据的情况，这个比例还是小了一些，0.8-0.9之间比较合适。（前提是你的
reduce函数不会疯狂的吃掉内存）mapred.job.shuffle.merge.percent(默认值0.66)mapred.inmem.merge.threshold(默认值1000)第一个指的是从Map节点取数据过来，放到内存，当达到这个阈值之后，后台启动线程（通常是Linux native process）把内存中的
数据merge sort，写到reduce节点的本地磁盘；第二个指的是从map节点取过来的文件个数，当达到这个个数之后，也进行merger sort，然后写到reduce节点的本地磁盘；这两
个配置项第一个优先判断，其次才判断第二个thresh-hold。从实际经验来看，mapred.job.shuffle.merge.percent默认值偏小，完全可以设置到0.8左右；第二个默认值1000，完全取决于
map输出数据的大小，如果map输出的数据很大，默认值1000反倒不好，应该小一些，如果map输出的数据不大（light
weight），可以设置2000或者以上。mapred.reduce.slowstart.completed.maps&（map完成多少百分比时，开始shuffle）
当map运行慢，reduce运行很快时，如果不设置mapred.reduce.slowstart.completed.maps会使job的shuffle时间变的很长，
map运行完很早就开始了reduce，导致reduce的slot一直处于被占用状态。mapred.reduce.slowstart.completed.maps 这个值是
和&运行完的map数除以总map数&做判断的，当后者大于等于设定的值时，开始reduce的shuffle。所以当map比reduce的执行
时间多很多时，可以调整这个值（0.75,0.80,0.85及以上）
下面从流程里描述一下各个参数的作用：当map task开始运算，并产生中间数据时，其产生的中间结果并非直接就简单的写入磁盘。这中间的过程比较复杂，并且利用到了
内存buffer来进行已经产生的部分结果的缓存，并在内存buffer中进行一些预排序来优化整个map的性能。每一个map都会对应存
在一个内存buffer（MapOutputBuffer），map会将已经产生的部分结果先写入到该buffer中，这个buffer默认是100MB大小，但
是这个大小是可以根据job提交时的参数设定来调整的，该参数即为：io.sort.mb。当map的产生数据非常大时，并且把io.sort.mb
调大，那么map在整个计算过程中spill的次数就势必会降低，map task对磁盘的操作就会变少，如果map tasks的瓶颈在磁盘上，
这样调整就会大大提高map的计算性能。map在运行过程中，不停的向该buffer中写入已有的计算结果，但是该buffer并不一定能将全部的map输出缓存下来，当map输出
超出一定阈值（比如100M），那么map就必须将该buffer中的数据写入到磁盘中去，这个过程在mapreduce中叫做spill。map并
不是要等到将该buffer全部写满时才进行spill，因为如果全部写满了再去写spill，势必会造成map的计算部分等待buffer释放空间的
情况。所以，map其实是当buffer被写满到一定程度（比如80%）时，就开始进行spill。这个阈值也是由一个job的配置参数来控
制，即io.sort.spill.percent，默认为0.80或80%。这个参数同样也是影响spill频繁程度，进而影响map task运行周期对磁盘的读写
频率的。但非特殊情况下，通常不需要人为的调整。调整io.sort.mb对用户来说更加方便。当map task的计算部分全部完成后，如果map有输出，就会生成一个或者多个spill文件，这些文件就是map的输出结果。map在正
常退出之前，需要将这些spill合并（merge）成一个，所以map在结束之前还有一个merge的过程。merge的过程中，有一个参数
可以调整这个过程的行为，该参数为：io.sort.factor。该参数默认为10。它表示当merge spill文件时，最多能有多少并行的stream
向merge文件中写入。比如如果map产生的数据非常的大，产生的spill文件大于10，而io.sort.factor使用的是默认的10，那么当
map计算完成做merge时，就没有办法一次将所有的spill文件merge成一个，而是会分多次，每次最多10个stream。这也就是说，
当map的中间结果非常大，调大io.sort.factor，有利于减少merge次数，进而减少map对磁盘的读写频率，有可能达到优化作业的
目的。当job指定了combiner的时候，我们都知道map介绍后会在map端根据combiner定义的函数将map结果进行合并。运行combiner
函数的时机有可能会是merge完成之前，或者之后，这个时机可以由一个参数控制，即min.num.spill.for.combine（default 3），
当job中设定了combiner，并且spill数最少有3个的时候，那么combiner函数就会在merge产生结果文件之前运行。通过这样的方
式，就可以在spill非常多需要merge，并且很多数据需要做conbine的时候，减少写入到磁盘文件的数据数量，同样是为了减少对磁
盘的读写频率，有可能达到优化作业的目的。减少中间结果读写进出磁盘的方法不止这些，还有就是压缩。也就是说map的中间，无论是spill的时候，还是最后merge产生的结
果文件，都是可以压缩的。压缩的好处在于，通过压缩减少写入读出磁盘的数据量。对中间结果非常大，磁盘速度成为map执行瓶
颈的job，尤其有用。控制map中间结果是否使用压缩的参数为：mapred.compress.map.output(true/false)。将这个参数设置为
true时，那么map在写中间结果时，就会将数据压缩后再写入磁盘，读结果时也会采用先解压后读取数据。这样做的后果就是：写
入磁盘的中间结果数据量会变少，但是cpu会消耗一些用来压缩和解压。所以这种方式通常适合job中间结果非常大，瓶颈不在
cpu，而是在磁盘的读写的情况。说的直白一些就是用cpu换IO。根据观察，通常大部分的作业cpu都不是瓶颈，除非运算逻辑异常
复杂。所以对中间结果采用压缩通常来说是有收益的。当采用map中间结果压缩的情况下，用户还可以选择压缩时采用哪种压缩格式进行压缩，现在hadoop支持的压缩格式有：
GzipCodec，LzoCodec，BZip2Codec，LzmaCodec等压缩格式。通常来说，想要达到比较平衡的cpu和磁盘压缩比，LzoCodec
比较适合。但也要取决于job的具体情况。用户若想要自行选择中间结果的压缩算法，可以设置配置参数：
mapred.map.output.compression.codec=org.apache.hadoop.io.compress.DefaultCodec或者其他用户自行选择的压缩方式。用最简单的语言，记录最难理解的问题，交流qq群：
Hive内存溢出的问题
nullPointException
，我看了一下50030，发现是内存溢出问题。如何解决？？？我们需要更改如下配置。
再次运行，成功！！！
没有更多推荐了，java非堆内存溢出求教
[问题点数：20分]
本版专家分：0
CSDN今日推荐
本版专家分：35901
本版专家分：35901
本版专家分：14049
匿名用户不能发表回复！|
CSDN今日推荐