HDFS FileSystem 导致的内存泄露

这篇具有很好参考价值的文章主要介绍了HDFS FileSystem 导致的内存泄露。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

HDFS FileSystem 导致的内存泄露

                                感谢点赞和关注 ,每天进步一点点!加油!

目录

一、问题描述

二、问题定位和源码分析


一、问题描述


ftp程序读取windows本地文件写入HDFS,5天左右程序 重启一次,怀疑是为OOM挂掉,马上想着就分析 GC日志了。

### 打印gc日志
/usr/java/jdk1.8.0_162/bin/java  \
  -Xmx1024m -Xms512m -XX:+UseG1GC -XX:MaxGCPauseMillis=100 \
  -XX:-ResizePLAB -verbose:gc -XX:-PrintGCCause -XX:+PrintAdaptiveSizePolicy \
  -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/hadoop/datadir/windeploy/log/ETL/DS/gc.log-`date +'%Y%m%d%H%M'` \
  -classpath $jarPath com.winnerinf.dataplat.ftp.FtpUtilDS

HDFS FileSystem 导致的内存泄露

程序分配内存 1024M ,从gc日志可以看出,old区域的占用大小一直从100M上升到了1G,后面频繁的fullGc,但是释放的空间并不多,最后程序由于内存空间不足导致OOM。

我们使用 jmap 命令将该进程的 JVM 快照导出来进行分析:

jmap -dump:live,format=b,file=dump.hprof PID

这个命令会在当前目录下生成一个dump.hrpof文件,这里是二进制的格式,你不能直接打开看的,其把这一时刻JVM堆内存里所有对象的快照放到文件里去了,供你后续去分析。

Memory Analyzer Mat下载地址:Eclipse Memory Analyzer Open Source Project | The Eclipse Foundation

https://kangll.blog.csdn.net/article/details/130222759?spm=1001.2014.3001.5502https://kangll.blog.csdn.net/article/details/130222759?spm=1001.2014.3001.5502Mat 工具给出了两个问题:

HDFS FileSystem 导致的内存泄露

问题一

"org.apache.hadoop.fs.FileSystem$Cache"”的一个实例文件系统被"sun.misc.Launcher$AppClassLoader @ 0xc04e9290"加载。占用208,987,664字节(20.36%)。内存在“"org.apache.hadoop.fs.FileSystem$Cache"”的一个实例中累积。文件系统被程序"sun.misc.Launcher$AppClassLoader @ 0xc04e9290"加载。

问题二

7,670个“org.apache.hadoop.conf.Configuration”实例。配置”,由“sun.misc”加载。"sun.misc.Launcher$AppClassLoader @ 0xc04e9290" 占用813,527,552字节(79.25%)。这些实例是从"java.util.HashMap$Node[]",的一个实例中引用的。由"<系统类加载器>"加载。


二、问题定位和源码分析


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

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

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

Configuration conf = new Configuration();
conf.set("fs.hdfs.impl", "org.apache.hadoop.hdfs.DistributedFileSystem");
conf.set("fs.file.impl", "org.apache.hadoop.fs.LocalFileSystem");
FileSystem fileSystem = FileSystem.get(conf);

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

/****************************************************************
* 
* </ol>
*****************************************************************/
@SuppressWarnings("DeprecatedIsStillUsed")
@InterfaceAudience.Public
@InterfaceStability.Stable
public abstract class FileSystem extends Configured
implements Closeable, DelegationTokenIssuer {
  public static final String FS_DEFAULT_NAME_KEY =
  CommonConfigurationKeys.FS_DEFAULT_NAME_KEY;
  public static final String DEFAULT_FS =
  CommonConfigurationKeys.FS_DEFAULT_NAME_DEFAULT;
  /**
   * 获取这个URI的方案和权限的文件系统
   *  如果配置有属性{@code "fs.$SCHEME.impl.disable。缓存"}设置为true,
   *  将创建一个新实例,并使用提供的URI和进行初始化配置,然后返回而不被缓存
   * 
   *  如果有一个缓存的FS实例匹配相同的URI,它将被退回
   *  否则:将创建一个新的FS实例,初始化配置和URI,缓存并返回给调用者。
   */
  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 FS
      return get(conf);
    }

        if (scheme != null && authority == null) {     // no authority
      URI defaultUri = getDefaultUri(conf);
      if (scheme.equals(defaultUri.getScheme())    // if scheme matches default
            && defaultUri.getAuthority() != null) {  // & default has authority
          return get(defaultUri, conf);              // return default
        }
    }
        //  //如果cache被关闭了,每次都会创建一个新的FileSystem
        String disableCacheName = String.format("fs.%s.impl.disable.cache", scheme);
        if (conf.getBoolean(disableCacheName, false)) {
      LOGGER.debug("Bypassing cache to create filesystem {}", uri);
      return createFileSystem(uri, conf);
    }

        return CACHE.get(uri, conf);
     }

  /** Caching FileSystem objects. */
  static class Cache {
    // ....
    FileSystem get(URI uri, Configuration conf) throws IOException{
      // key 的问题 ,详细我们看下 Key 
      Key key = new Key(uri, conf);
      return getInternal(uri, conf, key);
    }
  }
     /**
     *如果键映射到实例,则获取FS实例,如果没有找到FS,则创建并初始化FS。
    * 如果这是映射中的第一个条目,并且JVM没有关闭,那么它会注册一个关闭钩子来关闭文件系统,并将这个FS添加到{@code toAutoClose}集合中,
     * 如果{@code " FS .automatic。Close "}在配置中设置(默认为true)。
     */
    private 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);
      final long timeout = conf.getTimeDuration(SERVICE_SHUTDOWN_TIMEOUT,
          SERVICE_SHUTDOWN_TIMEOUT_DEFAULT,
          ShutdownHookManager.TIME_UNIT_DEFAULT);
      synchronized (this) { // refetch the lock again
        FileSystem oldfs = map.get(key);
        if (oldfs != null) { // a file system is created while lock is releasing
          fs.close(); // close the new file system
          return oldfs;  // return the old file system
        }

        // now insert the new file system into the map
        if (map.isEmpty()
                && !ShutdownHookManager.get().isShutdownInProgress()) {
          ShutdownHookManager.get().addShutdownHook(clientFinalizer,
              SHUTDOWN_HOOK_PRIORITY, timeout,
              ShutdownHookManager.TIME_UNIT_DEFAULT);
        }
        fs.key = key;
        map.put(key, fs);
        if (conf.getBoolean(
            FS_AUTOMATIC_CLOSE_KEY, FS_AUTOMATIC_CLOSE_DEFAULT)) {
          toAutoClose.add(key);
        }
        return fs;
      }
    }

}

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

 /** FileSystem.Cache.Key */
    static class Key {
      final String scheme;
      final String authority;
      final UserGroupInformation ugi;
      final long unique;   // an artificial way to make a key unique

      Key(URI uri, Configuration conf) throws IOException {
        this(uri, conf, 0);
      }

      Key(URI uri, Configuration conf, long unique) throws IOException {
        scheme = uri.getScheme()==null ?
            "" : StringUtils.toLowerCase(uri.getScheme());
        authority = uri.getAuthority()==null ?
            "" : StringUtils.toLowerCase(uri.getAuthority());
        this.unique = unique;

        this.ugi = UserGroupInformation.getCurrentUser();
      }

      @Override
      public int hashCode() {
        return (scheme + authority).hashCode() + ugi.hashCode() + (int)unique;
      }

      static boolean isEqual(Object a, Object b) {
        return a == b || (a != null && a.equals(b));
      }

      @Override
      public boolean equals(Object obj) {
        if (obj == this) {
          return true;
        }
        if (obj instanceof Key) {
          Key that = (Key)obj;
          return isEqual(this.scheme, that.scheme)
                 && isEqual(this.authority, that.authority)
                 && isEqual(this.ugi, that.ugi)
                 && (this.unique == that.unique);
        }
        return false;
      }

      @Override
      public String toString() {
        return "("+ugi.toString() + ")@" + scheme + "://" + authority;
      }
    }

我们使用 Mat工具 看下对象对比 scheme ,authority,ugi 的 哈希值

HDFS FileSystem 导致的内存泄露

查看外部应用对象

  • java.util.HashMap$Node @ 0xc6756200
  • java.util.HashMap$Node @ 0xca5f51f8

HDFS FileSystem 导致的内存泄露

我们集群开启了kerberos配置,可以看到 UGI对象的 hashCode不一样。

HDFS FileSystem 导致的内存泄露

我们来看下 UGI类 

  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>() {
      @Override
      public FileSystem run() throws IOException {
        return get(uri, conf);
      }
    });
  }
  // UserGroupInformation.getBestUGI
  public 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.createRemoteUser
  public 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;
  }

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

ugi对象的不同是由于我们获取FileSystem时指定了用户有关 ,我们开启了 Kereros 而且指定了用户,根据下图的 UGI 对象可以看出每次请求都会生成一个新的实例,就会出现内存泄露的问题。

HDFS FileSystem 导致的内存泄露

最后我们再看下程序的DEBUG日志:

2022-12-22 09:49:35  INFO [main] (HDFS.java:384) - FileSystem is
2022-12-22 09:49:35 DEBUG [IPC Parameter Sending Thread #0] (Client.java:1122) - IPC Client (1861781750) connection to hdp103/192.168.2.152:8020 from winner_spark@WINNER.COM sending #9 org.apache.hadoop.hdfs.protocol.ClientProtocol.getFileInfo
2022-12-22 09:49:35 DEBUG [IPC Client (1861781750) connection to hdp103/192.168.2.152:8020 from winner_spark@WINNER.COM] (Client.java:1176) - IPC Client (1861781750) connection to hdp103/192.168.2.152:8020 from winner_spark@WINNER.COM got value #9
2022-12-22 09:49:35 DEBUG [main] (ProtobufRpcEngine.java:249) - Call: getFileInfo took 1ms
2022-12-22 09:49:35 DEBUG [main] (UserGroupInformation.java:254) - hadoop login
2022-12-22 09:49:35 DEBUG [main] (UserGroupInformation.java:187) - hadoop login commit
2022-12-22 09:49:35 DEBUG [main] (UserGroupInformation.java:199) - using kerberos user:winner_spark@WINNER.COM
2022-12-22 09:49:35 DEBUG [main] (UserGroupInformation.java:221) - Using user: "winner_spark@WINNER.COM" with name winner_spark@WINNER.COM
2022-12-22 09:49:35 DEBUG [main] (UserGroupInformation.java:235) - User entry: "winner_spark@WINNER.COM"
2022-12-22 09:49:35  INFO [main] (UserGroupInformation.java:1009) - Login successful for user winner_spark@WINNER.COM using keytab file /etc/security/keytabs/winner_spark.keytab
2022-12-22 09:49:35 DEBUG [IPC Parameter Sending Thread #0] (Client.java:1122) - IPC Client (1861781750) connection to hdp103/192.168.2.152:8020 from winner_spark@WINNER.COM sending #10 org.apache.hadoop.hdfs.protocol.ClientProtocol.getListing
2022-12-22 09:49:35 DEBUG [IPC Client (1861781750) connection to hdp103/192.168.2.152:8020 from winner_spark@WINNER.COM] (Client.java:1176) - IPC Client (1861781750) connection to hdp103/192.168.2.152:8020 from winner_spark@WINNER.COM got value #10
2022-12-22 09:49:35 DEBUG [main] (ProtobufRpcEngine.java:249) - Call: getListing took 15ms
2022-12-22 09:49:35 DEBUG [IPC Parameter Sending Thread #0] (Client.java:1122) - IPC Client (1861781750) connection to hdp103/192.168.2.152:8020 from winner_spark@WINNER.COM sending #11 org.apache.hadoop.hdfs.protocol.ClientProtocol.getListing
2022-12-22 09:49:35 DEBUG [IPC Client (1861781750) connection to hdp103/192.168.2.152:8020 from winner_spark@WINNER.COM] (Client.java:1176) - IPC Client (1861781750) connection to hdp103/192.168.2.152:8020 from winner_spark@WINNER.COM got value #11
2022-12-22 09:49:35 DEBUG [main] (ProtobufRpcEngine.java:249) - Call: getListing took 10ms
2022-12-22 09:49:35  INFO [main] (HDFS.java:279) - Get a list of files and sort them by access time!
2022-12-22 09:49:35  INFO [main] (FtpUtilDS.java:192) - ----------- not exist rename failure file ---------------

程序DEBUG 日志 也显示每次IPC 遍历HDFS的文件的时候kerberos 还会进行一次登录。虽然fileSystem使用cache,但是由于Key的判断问题,所以基本每次请求都会生成一个新的实例,就会出现内存泄露的问题。

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

 基于以上的分析,我将过去的旧代码做稍微修改:

Configuration conf = null;
FileSystem fileSystem = null;

....
finally {
            if (fileSystem != null) {
                fileSystem.close();
                conf.clear();
            }
        }

我们再看 程序运行了 两个多月没有重启,查看 堆内存发现 在新生代大部分的对象被回收,而且老年代占用内存持续维持在  10% 以下,至此问题解决。

HDFS FileSystem 导致的内存泄露文章来源地址https://www.toymoban.com/news/detail-433366.html

 感谢点赞和关注!

到了这里,关于HDFS FileSystem 导致的内存泄露的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 注意避坑!Java 内部类持有外部类会导致内存泄露。。。

    本文介绍 Java 内部类持有外部类导致内存泄露的原因以及其解决方案。 为什么内部类持有外部类会导致内存泄露 非静态内部类会持有外部类,如果有地方引用了这个非静态内部类,会导致外部类也被引用,垃圾回收时无法回收这个外部类(即使外部类已经没有其他地方在使

    2024年02月09日
    浏览(52)
  • .NET 6 在 Win7 系统证书链错误导致 HttpWebRequest 内存泄露

    本文记录我将应用迁移到 dotnet 6 之后,在 Win7 系统上,因为使用 HttpWebRequest 访问一个本地服务,此本地服务开启 https 且证书链在此 Win7 系统上错误,导致应用内存泄露问题。本文记录此问题的原因以及调查过程 核心原因是在 CRYPT32.dll 上的 CertGetCertificateChain 方法存在内存泄

    2024年02月06日
    浏览(51)
  • Day26: Redis入门、开发点赞功能、开发我收到的赞的功能、重构点赞功能、开发关注、取消关注、开发关注列表、粉丝列表、重构登录功能

    Redis是NoSQL数据库(Not only SQL) 值支持多种数据结构(key都是string): 字符串、哈希、列表、集合、有序集合 把数据存在内存中,速度惊人; 同时也可以讲数据快照(数据备份,定时跑一次)/日志**(AOF,实时存命令)**存在硬盘上,保证数据安全性; Redis典型的应用场景包

    2024年04月27日
    浏览(44)
  • Java 性能优化 创作不易,觉得好,点赞收藏关注博主!

    Java性能优化主要涉及以下这些方面: 1. 代码级别的优化 避免在循环中创建对象 :使用对象池或缓存来重用对象。 使用基本数据类型和数组 :替代对象以减少内存消耗和提高处理速度。 2. 数据结构和算法的选择 选择合适的数据结构 :根据实际需求选择合适的数据结构,例

    2024年02月01日
    浏览(54)
  • JavaScript 制作实时电子时钟 ,点赞加关注经典案例持续更新~

    效果动图,此动图时间仅为当时录制的时间,实际运行时间为实时时间 最主要是要通过 new Date()时间对象,获取各类实时时间,下面是一些常用的 Date对象的一些常用属性和方法: 获取: getFullYear() : 返回四位数的年份。 getMonth() : 返回月份,范围是0-11。 getDate() : 返回月份中

    2024年02月03日
    浏览(45)
  • 用auto.js写了一个抖音点赞、关注的脚本

    最近一直在找工作,有天就遇到一个要求使用auto.js写一些自动化控件的公司(我严重怀疑它其实就想白嫖。。。),于是就有了这个小demo... 因为没用过抖音,也不懂auto.js,所以看了一些教学视频,所以写成这个样子了。。。(有点烂,就单纯记录一下自己的学习过程,au

    2024年02月13日
    浏览(47)
  • 网络安全领域关键信息泄露事件引发关注

    近日,一家知名网络安全公司发布了一份报告揭露了一起重大信息泄露事件。据称,该事件涉及大量敏感用户数据的泄露引发了全球网络安全领域的广泛关注。 根据报道,该事件发生在全球范围内涉及多个国家和组织。专家指出,此次泄露事件的规模和影响力令人震惊突显了

    2024年02月09日
    浏览(38)
  • C语言实现万年历(附代码) 小白完成的第一个C语言程序,希望大家多多关注,点赞

    C语言实现万年历 前言:本文章向大家介绍如何使用C语言代码实现万年历使用实例,讲解编写万年历的方法,教你轻松学会写出万年历。这个小程序算是我自己写的第一个比较完整的小程序,算是对大一上学期学习的C语言程序设计基础的一个总结 知识强调 1.由于教皇格里戈

    2024年02月11日
    浏览(37)
  • 【HDFS】每天一个RPC系列----complete(二):客户端侧

    上图给出了最终会调用到complete RPC的客户端侧方法链路(除去Router那条线了)。 org.apache.hadoop.hdfs.DFSOutputStream#completeFile(org.apache.hadoop.hdfs.protocol.ExtendedBlock): 下面这个方法在complete rpc返回true之前,会进行重试,直到超过最大重试次数抛异常。 另外需要注意的是,这个方法在

    2024年02月13日
    浏览(47)
  • 什么是内存溢出?什么是内存泄露?

    文章目录 一、什么是内存溢出?  二、什么是内存泄露? 三、如何避免内存溢出和内存泄露? 一、什么是内存溢出?         假设我们JVM中可用的内存空间只有 3M ,但是我们要创建一个 5M 的对象,那么新创建的对象就放不进去了。这个时候,我们就叫做内存溢出。就好

    2024年02月08日
    浏览(67)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包