Hdfs FileSystem 使用姿势不对导致的内存泄露

2024-09-04 17:18
文章标签 使用 内存 filesystem 导致 hdfs 泄露 姿势

本文主要是介绍Hdfs FileSystem 使用姿势不对导致的内存泄露，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章目录

    • 一、问题描述
    • 二、问题排查
      • Java Heap Dump文件
      • 使用Jmap获取运行中的jvm内存
      • 在Jhat页面查找对应类实例具体的引用
      • 问题定位
    • 三、解决方案
    • 四、总结

一、问题描述

有用户反馈访问httpfs服务偶尔出现502的情况，所以上httpfs服务器看了下，发现有一台因为OOM挂掉了（运维告警没弄好，所以没及时通知到）。

目前有两台HttpFs，通过nginx转发，如果刚好请求转发到挂掉的那台，就会出现502的问题。

因为是OOM问题，所以马上就想着去分析gc日志了。后面简单分析了gc日志，发现从httpfs启动以来，old区域内存呈不断递增的趋势：

在这里插入图片描述

以上图表是通过 https://gceasy.io 网站分析得到

从gc日志可以看出，old区域的占用大小一直从100M上升到了8G，后面有进行了几次fullGc，但是释放的空间并不多，最后程序由于内存空间不足导致OOM。同时看了一下另外一台没挂的httpfs服务，old区域也非常大了，接近OOM。

httpfs只是一个很简单的web代理服务，功能只有下载和上传数据，大部分对象应该在young gc就会清理回收掉才对。所以可以判断应该是哪里代码写的有问题导致了内存泄露。

二、问题排查

Java Heap Dump文件

在java程序启动时加上参数-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/toPath/heapdump.hprof可以在程序出现OOM时输出head dump文件。这样我们就可以通过这个heapdump文件分析哪些对象导致的内存泄露，最终定位到问题。

我们可以通过jhat来分析heapdump.hprof文件：

# heapdump.hprof比较大的话，需要调大jhat的堆内存，防止jhat分析过程中内存溢出
jhat -J-Xmx2048M heapdump.hprof

由于我们的httpfs服务在启动时已经加上了上面的JVM参数，所以在OOM时也输出了heapdump.hprof，但是比较尴尬的是，我们服务的堆内存比较大，因此OOM生成的heapdump.hprof也很大，达到14G的大小。

heapdump.hprof文件太大导致基本无法使用jhat分析。（我们尝试将jhat的堆内存调整到20G，但是在jhat运行一段时间后还是因为OOM而退出），所以放弃直接去分析这个14G的heapdump.hprof。

使用Jmap获取运行中的jvm内存

由于OOM生成的heapdump.hprof无法分析，我们只能让程序先运行一段时间，之后再通过jmap来获取jvm对象的相关信息，甚至也可以使用jmap输出heapdump文件来给jhat分析。

jmap -histo:live pid输出java堆的对象相关信息

在这里插入图片描述

也可以先输出dump文件，然后通过jhat分析：

jmap -dump:live,format=b,file=/path/heapdump.hprof pid
jhat -J-Xmx2048M heapdump.hprof
# jhat启动后在浏览器输入  http://ip:7000 就可以看到对应的信息了

在Jhat页面查找对应类实例具体的引用

通过上面的jmap -histo:live我们可以看出，内存中有大量的Hashtable$Entity和ConcurrentHashMap$Entity对象。但是使用Hashtable和ConcurrentHashMap可能存在很多，我们依旧无法很直观的看出是代码的哪部分出现问题。因此我们还需要借助jhat来找到这些Hashtable和ConcurrentHashMap对象是被哪些对象所引用的。

下面我们随机找一个类演示一下如何通过jhat查看对象实例之间的引用：

先通过http://ip:7000进入jhat的首页面，然后拉到最下方

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

按照上面的方法，通过不断的查询，最终我们会发现到底是哪些类引用了这些类。

问题定位

经过排查，我们发现问题的源头在于org.apache.hadoop.fs.FileSystem这个类，httpfs仅仅运行一天，这个类就产生了几千个实例。这些实例虽然占用的大小不大，但是每产生一个FileSystem实例时，它都会维护一个Properties对象(Hashtable的子类)，用来存储hadoop的那些配置信息。hadoop的配置有几百个很正常，因此一个FileSystem实例实例就会对应上百个的Hashtable$Entity实例，就会占用大量内存。

那为什么会有如此多的FileSystem实例呢？

以下是我们获取FIleSystem的方式：

FileSystem fileSystem = FileSystem.get(uri, conf, "hadoopuser");

FileSystem.get底层是有使用缓存的，因此我们在每次使用完并没有关闭fileSystem，只是httpfs服务关闭时才去关闭FileSystem。

FileSystem.get底层的一些代码：

  public static FileSystem get(URI uri, Configuration conf) throws IOException {String scheme = uri.getScheme();String authority = uri.getAuthority();if (scheme == null && authority == null) {     // use default FSreturn get(conf);}if (scheme != null && authority == null) {     // no authorityURI defaultUri = getDefaultUri(conf);if (scheme.equals(defaultUri.getScheme())    // if scheme matches default&& defaultUri.getAuthority() != null) {  // & default has authorityreturn get(defaultUri, conf);              // return default}}//如果cache被关闭了，每次都会创建一个新的FileSystemString disableCacheName = String.format("fs.%s.impl.disable.cache", scheme);if (conf.getBoolean(disableCacheName, false)) {return createFileSystem(uri, conf);}//直接从cache获取return CACHE.get(uri, conf);}//Cache.classFileSystem get(URI uri, Configuration conf) throws IOException{Key key = new Key(uri, conf);return getInternal(uri, conf, key);}//Cache.classprivate FileSystem getInternal(URI uri, Configuration conf, Key key) throws IOException{FileSystem fs;synchronized (this) {fs = map.get(key);}if (fs != null) {return fs;}fs = createFileSystem(uri, conf);synchronized (this) { // refetch the lock againFileSystem oldfs = map.get(key);if (oldfs != null) { // a file system is created while lock is releasingfs.close(); // close the new file systemreturn oldfs;  // return the old file system}// now insert the new file system into the mapif (map.isEmpty()&& !ShutdownHookManager.get().isShutdownInProgress()) {ShutdownHookManager.get().addShutdownHook(clientFinalizer, SHUTDOWN_HOOK_PRIORITY);}fs.key = key;map.put(key, fs);if (conf.getBoolean("fs.automatic.close", true)) {toAutoClose.add(key);}return fs;}}

我们httpfs服务的fs.%s.impl.disable.cache并没有开启，因此肯定有使用cache。所以问题很可能是Cache的key判断有问题。

看了下Cache的Key，判断Key是否相等主要有三个因素

   static class Key {final String scheme;final String authority;final UserGroupInformation ugi;}

scheme和authority基本都是一样的，因此问题大概率是出在ugi上面。后面我们通过arthas查看了此处的ugi的hashcode，确实每次请求的都不一样。

虽然使用cache，但是由于Key的判断问题，所以基本每次请求都会生成一个新的实例，就会出现内存泄露的问题。

最后我们发现，ugi对象的不同是由于我们获取FileSystem时指定了用户有关，我们看一下指定用户时的方法:

  public static FileSystem get(final URI uri, final Configuration conf,final String user) throws IOException, InterruptedException {String ticketCachePath =conf.get(CommonConfigurationKeys.KERBEROS_TICKET_CACHE_PATH);//这里每次获取的ugi的hashcode都不一样UserGroupInformation ugi =UserGroupInformation.getBestUGI(ticketCachePath, user);return ugi.doAs(new PrivilegedExceptionAction<FileSystem>() {@Overridepublic FileSystem run() throws IOException {return get(uri, conf);}});}
//UserGroupInformation.getBestUGIpublic static UserGroupInformation getBestUGI(String ticketCachePath, String user) throws IOException {if (ticketCachePath != null) {return getUGIFromTicketCache(ticketCachePath, user);} else if (user == null) {return getCurrentUser();} else {//最终走到这里return createRemoteUser(user);}    }
//UserGroupInformation.createRemoteUserpublic static UserGroupInformation createRemoteUser(String user, AuthMethod authMethod) {if (user == null || user.isEmpty()) {throw new IllegalArgumentException("Null user");}Subject subject = new Subject();subject.getPrincipals().add(new User(user));UserGroupInformation result = new UserGroupInformation(subject);result.setAuthenticationMethod(authMethod);return result;}

我们没有开启kerberos配置。UserGroupInformation其实只是对JAAS进行了一些封装，因此UserGroupInformation的hashcode其实就是计算其封装的Subject的hashcode。

从代码可以看出，如果指定了用户，每次都会构造一个新的Subject，因此计算出来的UserGroupInformation的hashcode也都不一样。这样也最终导致FileSystem的Cache不生效。

三、解决方案

  1. 修改源码:Cache$Key的hashcode方法，让其直接根据UserGroupInformation的userName来判定是否相等。
  2. 自己构建一个简单的Cache

四、总结

这个内存泄露的问题其实并不难，只需要进行简单的排查即可找到问题所在，解决方法也很简单。写这篇博客主要还是为了记录一下排查这种内存泄露的问题一个大体思路。

本文也详细介绍了如何使用jmap和jhat来定位问题，另外，我们平常也要记得在启动java程序时都带上-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/toPath/heapdump.hprof参数，这样当出现OOM时，我们才可以更方便的排查问题所在。

这篇关于Hdfs FileSystem 使用姿势不对导致的内存泄露的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/1136542。

相关文章

中文分词jieba库的使用与实景应用（一）

中文分词jieba库的使用与实景应用（一）

知识星球：https://articles.zsxq.com/id_fxvgc803qmr2.html 目录 一.定义： 精确模式（默认模式）： 全模式： 搜索引擎模式： paddle 模式（基于深度学习的分词模式）： 二 自定义词典 三.文本解析   调整词出现的频率 四. 关键词提取 A. 基于TF-IDF算法的关键词提取 B. 基于TextRank算法的关键词提取
阅读更多...
使用SecondaryNameNode恢复NameNode的数据

使用SecondaryNameNode恢复NameNode的数据

1）需求： NameNode进程挂了并且存储的数据也丢失了，如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2）故障模拟 （1）kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 （2）删除NameNode存储的数据（/opt/module/hadoop-3.1.4/data/tmp/dfs/na
阅读更多...
HDFS—存储优化（纠删码）

HDFS—存储优化（纠删码）

纠删码原理 HDFS 默认情况下，一个文件有3个副本，这样提高了数据的可靠性，但也带来了2倍的冗余开销。 Hadoop3.x 引入了纠删码，采用计算的方式，可以节省约50％左右的存储空间。 此种方式节约了空间，但是会增加 cpu 的计算。 纠删码策略是给具体一个路径设置。所有往此路径下存储的文件，都会执行此策略。 默认只开启对 RS-6-3-1024k
阅读更多...
HDFS—集群扩容及缩容

HDFS—集群扩容及缩容

白名单：表示在白名单的主机IP地址可以，用来存储数据。 配置白名单步骤如下： 1）在NameNode节点的/opt/module/hadoop-3.1.4/etc/hadoop目录下分别创建whitelist 和blacklist文件 （1）创建白名单 [lytfly@hadoop102 hadoop]$ vim whitelist 在whitelist中添加如下主机名称，假如集群正常工作的节
阅读更多...
NameNode内存生产配置

NameNode内存生产配置

Hadoop2.x 系列，配置 NameNode 内存 NameNode 内存默认 2000m ，如果服务器内存 4G ， NameNode 内存可以配置 3g 。在 hadoop-env.sh 文件中配置如下。 HADOOP_NAMENODE_OPTS=-Xmx3072m Hadoop3.x 系列，配置 Nam
阅读更多...
Hadoop数据压缩使用介绍

Hadoop数据压缩使用介绍

一、压缩原则 （1）运算密集型的Job，少用压缩 （2）IO密集型的Job，多用压缩 二、压缩算法比较 三、压缩位置选择 四、压缩参数配置 1）为了支持多种压缩/解压缩算法，Hadoop引入了编码/解码器 2）要在Hadoop中启用压缩，可以配置如下参数
阅读更多...
Makefile简明使用教程

Makefile简明使用教程

文章目录 规则makefile文件的基本语法：加在命令前的特殊符号：.PHONY伪目标: Makefilev1 直观写法v2 加上中间过程v3 伪目标v4 变量 make 选项-f-n-C Make 是一种流行的构建工具，常用于将源代码转换成可执行文件或者其他形式的输出文件(如库文件、文档等)。Make 可以自动化地执行编译、链接等一系列操作。 规则 makefile文件
阅读更多...
使用opencv优化图片（画面变清晰）

使用opencv优化图片（画面变清晰）

文章目录 需求影响照片清晰度的因素 实现降噪测试代码 锐化空间锐化Unsharp Masking频率域锐化对比测试 对比度增强常用算法对比测试 需求 对图像进行优化，使其看起来更清晰，同时保持尺寸不变，通常涉及到图像处理技术如锐化、降噪、对比度增强等 影响照片清晰度的因素 影响照片清晰度的因素有很多，主要可以从以下几个方面来分析 1. 拍摄设备 相机传感器：相机传
阅读更多...
安卓链接正常显示，ios#符被转义%23导致链接访问404

安卓链接正常显示，ios#符被转义%23导致链接访问404

原因分析： url中含有特殊字符 中文未编码 都有可能导致URL转换失败，所以需要对url编码处理  如下： guard let allowUrl = webUrl.addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed) else {return} 后面发现当url中有#号时，会被误伤转义为%23，导致链接无法访问
阅读更多...
pdfmake生成pdf的使用

pdfmake生成pdf的使用

实际项目中有时会有根据填写的表单数据或者其他格式的数据，将数据自动填充到pdf文件中根据固定模板生成pdf文件的需求 文章目录 利用pdfmake生成pdf文件1.下载安装pdfmake第三方包2.封装生成pdf文件的共用配置3.生成pdf文件的文件模板内容4.调用方法生成pdf 利用pdfmake生成pdf文件 1.下载安装pdfmake第三方包 npm i pdfma
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2