2015-12-04 17 views
7

Sto sperimentando il caricamento di dati più grandi della dimensione della memoria in h2o.Caricamento di dati più grandi della dimensione della memoria in h2o

H2o blog cita: 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.

Ecco il codice per la connessione a Rh2o 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 

ho provato a caricare un 169 MB CSV in h2o.

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

che ha generato un errore,

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 

che è indicativo di fuori della memoria error.

Domanda: Se H2o promette di caricare un set di dati più grande della sua capacità di memoria (meccanismo di scambio su disco come dice la citazione del blog sopra), è questo il modo corretto di caricare i dati?

risposta

5

Swap-to-disk è stato disabilitato per impostazione predefinita un po 'di tempo fa, perché le prestazioni erano così negative. Il bleeding-edge (non l'ultima stable) ha un flag per abilitarlo: "--cleaner" (per "memory cleaner").
Nota che il tuo cluster ha una memoria ESTREMAMENTE piccola: H2O cluster total memory: 0.06 GB Questo è 60 MB! Appena sufficiente per avviare una JVM con, molto meno eseguire H2O. Sarei sorpreso se l'H2O potesse venire correttamente lì, per non parlare dello swap-to-disk. Lo scambio è limitato allo scambio dei dati da solo. Se stai provando a fare uno swap-test, sali la tua JVM su 1 o 2 ram di Gigs e poi carica i set di dati che sommano più di quello.

Cliff

+0

Grazie cliff. Stavo cercando di testare la funzione 'swap-to-disk' per limitare l'uso della RAM di H2O. Farò quel rilascio sanguinante e più RAM. – talegari

+0

@Cliff, ha qualcuno che conosci, ha provato a usare lo swap-to-disk su un dispositivo a disco a stato solido PCIE3-NMVe-M.2 molto più veloce (ordine di grandezza più veloce) come un Samsung 960 Pro? La mia fortuna è stata che continuo a trovare set di dati che sono solo un po 'troppo grandi per il mio sistema ... Potrei costruire un data mining rig specifico per l'uso con H2O e uno di questi, e con tutta la RAM che posso permettermi . –

Problemi correlati