当前位置: 首页 > 面试题库 >

加载大于h2o中的内存大小的数据

高奇
2023-03-14
问题内容

我正在尝试加载大于h2o中的内存大小的数据。

H2o 博客提到:A note on Bigger Data and GC: We do a user-mode swap-to-disk when the Java heap gets too full, i.e., you’re using more Big Data than physical DRAM. We won’t die with a GC death-spiral, but we will degrade to out-of-core speeds. We’ll go as fast as the disk will allow. I’ve personally tested loading a 12Gb dataset into a 2Gb (32bit) JVM; it took about 5 minutes to load the data, and another 5 minutes to run a Logistic Regression.

这是R连接到的代码h2o 3.6.0.8

h2o.init(max_mem_size = '60m') # alloting 60mb for h2o, R is running on 8GB RAM machine

java version "1.8.0_65"
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)

.Successfully connected to http://127.0.0.1:54321/

R is connected to the H2O cluster: 
    H2O cluster uptime:         2 seconds 561 milliseconds 
    H2O cluster version:        3.6.0.8 
    H2O cluster name:           H2O_started_from_R_RILITS-HWLTP_tkn816 
    H2O cluster total nodes:    1 
    H2O cluster total memory:   0.06 GB 
    H2O cluster total cores:    4 
    H2O cluster allowed cores:  2 
    H2O cluster healthy:        TRUE

Note:  As started, H2O is limited to the CRAN default of 2 CPUs.
       Shut down and restart H2O as shown below to use all your CPUs.
           > h2o.shutdown()
           > h2o.init(nthreads = -1)

IP Address: 127.0.0.1 
Port      : 54321 
Session ID: _sid_b2e0af0f0c62cd64a8fcdee65b244d75 
Key Count : 3

我试图将169 MB的csv加载到h2o中。

dat.hex <- h2o.importFile('dat.csv')

这引发了错误,

Error in .h2o.__checkConnectionHealth() : 
  H2O connection has been severed. Cannot connect to instance at http://127.0.0.1:54321/
Failed to connect to 127.0.0.1 port 54321: Connection refused

这表示内存不足错误。

问题:如果H2o承诺加载大于其内存容量的数据集(如上面的博客引文所述,交换到磁盘机制),这是加载数据的正确方法吗?


问题答案:

由于性能太差,默认情况下前一会默认禁用“交换到磁盘”。流血边缘(不是最新稳定的)具有启用它的标志:“-cleaner”(对于“内存清洁器”)。
请注意,您的群集有一个极小的内存: H2O cluster total memory: 0.06 GB60MB!勉强可以用运行H2O来启动JVM。如果H2O完全可以正常出现,我会感到惊讶,不用介意交换磁盘。交换仅限于单独交换数据。如果您要进行交换测试,请将JVM升级到1或2
Gigs内存,然后加载总和大于此值的数据集。

悬崖



 类似资料:
  • 我正在尝试在h2o中加载大于内存大小的数据。 H2o博客提到: 下面是连接到h2o 3.6.0.8的代码: 给 我试着把一个169 MB的csv加载到h2o中。 这抛出了一个错误, 这表示内存溢出错误。 问:如果H2opromise加载大于其内存容量的数据集(如上面的博客引述所说的交换到磁盘机制),这是加载数据的正确方法吗?

  • 有没有一种方法可以使用H2O迭代大于集群累积内存大小的数据?我有一个大数据集,我需要批量迭代并输入Tensorflow进行梯度下降。在给定的时间,我只需要在内存中加载一批(或少数)。有没有一种方法可以设置H2O来执行这种迭代,而无需将整个数据集加载到内存中? 这是一个相关的问题,一年多前就已经回答了,但没有解决我的问题:在h2o中加载大于内存大小的数据

  • 问题内容: 我的磁盘上只有168MB的文件。这只是一个逗号分隔的单词,id的列表。该单词的长度可以为1-5个字符。有650万行。 我在python中创建了一个字典,将其加载到内存中,因此我可以针对该单词列表搜索传入的文本。当python将其加载到内存中时,它显示已使用的1.3 GB RAM空间。知道为什么吗? 假设我的word文件如下所示… 然后再加上650万。然后,我遍历该文件并创建一个字典(p

  • 问题内容: 对于我的应用程序,Java进程使用的内存远远大于堆大小。 容器运行所在的系统开始出现内存问题,因为容器占用的内存比堆大小大得多。 堆大小设置为128 MB(-),而容器最多占用1GB的内存。正常情况下需要500MB。如果docker容器的限制低于(例如),则该进程将被操作系统的内存不足杀手杀死。 你能解释一下为什么Java进程使用的内存比堆多得多吗?如何正确调整Docker内存限制的大

  • 我有四个问题。假设在spark中有3个worker节点。每个工人节点有3个执行器,每个执行器有3个核心。每个执行器有5 gb内存。(总共6个执行器,27个内核,15GB内存)。如果: > 我有30个数据分区。每个分区的大小为6 GB。最佳情况下,分区的数量必须等于核心的数量,因为每个核心执行一个分区/任务(每个分区执行一个任务)。在这种情况下,由于分区大小大于可用的执行器内存,每个执行器核心将如何

  • 问题内容: 我只是尝试了内存中python数据结构的大小。我写了以下代码片段: 我在以下配置上测试了代码: Windows 7 64位,Python3.1:输出为:所以lst1有52个字节,lst2有40个字节。 使用Python3.2的Ubuntu 11.4 32bit:输出为 Ubuntu 11.4 32位Python2.7: 谁能向我解释为什么两个大小都不同,尽管它们都是包含1的列表? 在g