MAP TASK内存泄露-低调大师

MAP TASK内存泄露

2017-11-14 682

这几天于遇到一个略诡异的CASE：线上报警一个MR Job的一个MAP TASK使用的物理内存过大，仔细一看超过了Xmx=1.3GB，而物理内存消耗到1.7GB，第一反应是不是遇到JVM内存泄露了.先对MAP TASK做个dump分析：

发现实际JVM使用不到300MB，算上Perm（MaxPermSize=128MB），那其余的1.XGB的内存是哪里来的呢？想到了non-heap memoryleak，常见的主要几种：JNI，NIO,ZIP和AWT，查看MAP日志发现处理大量的GZIP文件是不是可能由于这个导致的呢，由于MAP启动具有一定的随机性，常见的non-heap 分析工具可能比较困难，不过先Google了一下果然有所发现：http://code.google.com/p/bigstreams/issues/detail?id=30

Hadoop native gzip存在内存泄露！解决的办法就是用Javabuiltin GZIP或者其他压缩格式.线上是并用GZIP和SNAPPY的，历史的GZIP还没有转到SNAPPY，看来有活干了...BTW,对于Sqoop的导入Job默认是gzip的，可以通过

--compression-codec org.apache.hadoop.io.compress.SnappyCodec来改变，同时最好结合--as-sequencefile

另外一个问题就是线上的内存使用率太低，因为io.sort.mb设置了256MB，怪不得JVM的old generation（主要就是mapoutput buffer）只用到了25%左右...因此这里的引出另外一个best practise是将io.sort.mb设置接近Xmx

最后，针对内存限制在HADOOP-0.20.0/1分别提出了几个参数来限制TASK的虚拟内存和物理内存的大小：HADOOP-5883：https://issues.apache.org/jira/browse/HADOOP-5883，MAPREDUCE-1221:https://issues.apache.org/jira/browse/HADOOP-5883 .

Have fun.

本文转自MIKE老毕 51CTO博客，原文链接：http://blog.51cto.com/boylook/1323554，如需转载请自行联系原作者

微信关注我们

原文链接：https://yq.aliyun.com/articles/476799

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

hadoop随记（一）

现在是一个大数据的年代，每天全球已电子方式存储数据的数据总量非常大。下面是部分例子： 1，facebook存储这约100亿张照片，越1PB存储容量 2，The Internet Archive(互联网档案馆)存储这约2PB数据，并以每月至少20TB的速度增长 3，瑞士日内瓦附近的大型强子对撞机每年产生15PB数据我们有了大量的数据，可以从中分析出我们有用的信息，如单个用户浏览网页内容的偏好，发现潜在用户等，还有很多用于科学技术上的用处。那么数据怎么存放呢？这么大的数据量，首要解决的是数据读写速度，数据安全性，硬件故障等问题，要有高可用的方案。而hadoop就提供了这样的解决办法：hadoop提供了一个可靠的共享存储和分析系统。HDFS实现存储，而MapReduce实现分析处理。关系型数据库和MapReduce：数据库系统只更新一部分记录，比mapreduce有优势。但是，如果更新大量数据时，效率就要比mapreduce低很多，因为需要使用“排序/合并”来重建数据库。mapreduce比较适合以批处理方式处理需要分析整个数据集的问题；而RDBMS适用于...

2017-11-15

490

线上一个查询简化如下： Selectdt,count(distinct c1) , count(distinct case when c2>0 and c1=0 then c1 end),count(distinct case when c2>0 and c1>0 then c1 end) from t where dtbetween ‘20131108’ and ‘20131110’ group by dt; 一个让人头痛的multi-distinct问题，为什么说很头痛，看看执行计划就清楚了： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83...

2017-11-15

632

资源下载

更多资源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。