【问题标题】:How to deal with a big dataset with H2O如何使用 H2O 处理大数据集
【发布时间】:2017-08-31 08:04:57
【问题描述】:

我正在尝试使用 H2O (3.14) 训练机器学习模型。我的数据集大小是 4Gb,我的计算机 RAM 是 2Gb,带有 2G 交换,JDK 1.8。参考这个article,H2O 可以处理具有 2Gb RAM 的巨大数据集。

  • 关于大数据和 GC 的说明:当 Java 堆太满时,我们会执行用户模式交换到磁盘,即您使用的大数据比 物理DRAM。我们不会死于 GC 死亡螺旋,但我们会 降级到核外速度。我们会像磁盘一样快 允许。我亲自测试了将 12Gb 数据集加载到 2Gb (32位)JVM;加载数据大约需要 5 分钟,另外 5 分钟 运行 Logistic 回归的分钟数。

关于这个问题的一些问题:

解决方法 1:

我使用选项java -Xmx10g -jar h2o.jar 配置了Java 堆。当我加载数据集时。 H2O信息如下:

但是,JVM 消耗了所有 RAM 内存和 Swap,然后操作系统停止了 java h2o 程序。

解决方法 2:

我安装了H2O spark。我可以加载数据集,但 spark 挂起以下日志并带有完整的交换内存:

 + FREE:426.8 MB == MEM_MAX:2.67 GB), desiredKV=841.3 MB OOM!
09-01 02:01:12.377 192.168.233.133:54321 6965   Thread-47 WARN: Swapping!  OOM, (K/V:1.75 GB + POJO:513.2 MB + FREE:426.8 MB == MEM_MAX:2.67 GB), desiredKV=841.3 MB OOM!
09-01 02:01:12.377 192.168.233.133:54321 6965   Thread-48 WARN: Swapping!  OOM, (K/V:1.75 GB + POJO:513.2 MB + FREE:426.8 MB == MEM_MAX:2.67 GB), desiredKV=841.3 MB OOM!
09-01 02:01:12.381 192.168.233.133:54321 6965   Thread-45 WARN: Swapping!  OOM, (K/V:1.75 GB + POJO:513.3 MB + FREE:426.7 MB == MEM_MAX:2.67 GB), desiredKV=803.2 MB OOM!
09-01 02:01:12.382 192.168.233.133:54321 6965   Thread-46 WARN: Swapping!  OOM, (K/V:1.75 GB + POJO:513.4 MB + FREE:426.5 MB == MEM_MAX:2.67 GB), desiredKV=840.9 MB OOM!
09-01 02:01:12.384 192.168.233.133:54321 6965   #e Thread WARN: Swapping!  GC CALLBACK, (K/V:1.75 GB + POJO:513.4 MB + FREE:426.5 MB == MEM_MAX:2.67 GB), desiredKV=802.7 MB OOM!
09-01 02:01:12.867 192.168.233.133:54321 6965   FJ-3-1    WARN: Swapping!  OOM, (K/V:1.75 GB + POJO:513.4 MB + FREE:426.5 MB == MEM_MAX:2.67 GB), desiredKV=1.03 GB OOM!
09-01 02:01:13.376 192.168.233.133:54321 6965   Thread-46 WARN: Swapping!  OOM, (K/V:1.75 GB + POJO:513.2 MB + FREE:426.8 MB == MEM_MAX:2.67 GB), desiredKV=803.2 MB OOM!
09-01 02:01:13.934 192.168.233.133:54321 6965   Thread-45 WARN: Swapping!  OOM, (K/V:1.75 GB + POJO:513.2 MB + FREE:426.8 MB == MEM_MAX:2.67 GB), desiredKV=841.3 MB OOM!
09-01 02:01:12.867 192.168.233.133:54321 6965   #e Thread WARN: Swapping!  GC CALLBACK, (K/V:1.75 GB + POJO:513.2 MB + FREE:426.8 MB == MEM_MAX:2.67 GB), desiredKV=803.2 MB OOM!

在这种情况下,我认为gc 收集器正在等待清理交换中一些未使用的内存。

如何在 RAM 内存有限的情况下处理庞大的数据集?

【问题讨论】:

  • 为什么是r 标签?
  • 我删除了r 标签。我的客户是r 程序

标签: java garbage-collection jvm h2o


【解决方案1】:

如果这有任何商业用途,请购买更多 RAM,或花几美元在云服务器上租用几个小时。

这是因为在太小的机器上进行机器学习的额外时间和精力是不值得的。

如果它是一个学习项目,完全没有预算:将数据集切成 8 个大小相等的部分 (*),然后只使用第一部分来制作和调整模型。 (如果数据不是随机排序的,则将其切成 32 等份,然后将第 1、9、17 和 25 部分连接起来;或类似的东西。)

如果你真的,真的,真的,必须使用整个数据集建立一个模型,那么仍然执行上述操作。但是然后保存模型,然后移动到 8 个数据集中的第 2 个。此时您已经调整了超参数,因此您只是在生成一个模型,而且速度很快。重复第 3 到第 8 部分。现在您有 8 个模型,可以在一个整体中使用它们。

*:我选择了 8,它给你一个 0.5GB 的数据集,这是可用内存的四分之一。对于早期的实验,我实际上建议做得更小,例如50MB,因为它会使迭代更快。

还有一些想法:

  • H2O 压缩内存中的数据。因此,如果 4GB 是未压缩的数据大小,那么您可能会使用较小的内存。 (但是,请记住,建议内存是数据大小的 3-4 倍。)
  • 如果您有朋友使用类似的小内存计算机,您可以将它们联网。 4 到 8 台计算机可能足以加载您的数据。它可能运行良好,也可能非常慢,这取决于算法(以及您的网络有多快)。

【讨论】:

  • 有没有像keras框架这样的生成器方法来拟合模型的解决方案?
  • @khant 我不知道。 H2O 的理念是内存机器学习,它可以在集群上高效工作:不断添加机器,直到集群总内存足够大以容纳您的数据集。 (我只是在我的答案中添加了一些想法,希望对您有所帮助。)
【解决方案2】:

引自 2014 年的文章已经过时多年,并且指的是 H2O-2。在 H2O 内用户模式交换到磁盘的概念当时是实验性的。

但正如引用的 StackOverflow 帖子所解释的那样,H2O-3(它在 2015 年初左右成为主要的 H2O 代码库)中从未支持此功能,因为性能很差。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2015-07-17
    • 1970-01-01
    • 2012-02-21
    • 2012-09-22
    • 1970-01-01
    • 2023-04-02
    • 2020-05-28
    相关资源
    最近更新 更多