[R-es] Cannot allocate vector of size
Julio Alejandro Di Rienzo
dirienzo.julio en gmail.com
Mar Dic 22 21:31:03 CET 2015
Si las matrices tiene gran cantidad de ceros, es posible reducir
sustancialmente la memoria utilizada cambiando las matrices convencionales
por matrices sparse (library(Matrix))
Dr. Julio Di Rienzo
Estadística y Biometría
FCA- U.N. Córdoba
http://sites.google.com/site/juliodirienzo
El 22 de diciembre de 2015, 15:41, Marcelino de la Cruz <
marcelino.delacruz en upm.es> escribió:
> Yo creo que el problema principal está en betapart.core(), que crea y
> mantiene simultáneamente en memoria varios objetos de alrededor de 1 Gb que
> luego combina en una lista... Probablemente es entre las líneas el código
> de betaper.core donde hay que ir eliminando objetos.
>
> Saludos,
>
> Marcelino
>
>
> El 22/12/2015 a las 18:26, Carlos J. Gil Bellosta escribió:
>
>> Hola, ¿qué tal?
>>
>> Yo no entré a comentar lo que hacen ni beta.pair ni betapart.core, que
>> es la función a la que esta llama. Pero tanto la una como la otra
>> hacen puras operaciones de álgebra lineal (sobre todo betapart.core).
>> Esas operaciones deberían ser muy livianas en términos de uso de
>> memoria. El objeto resultante no deberia ocupar más de 1GB (una matriz
>> 11k x 11k).
>>
>> Así que si conviertes tus datos de entrada a matriz (en lugar de DF),
>> borras el DF y haces un gc() (para borrar el objeto grande enseguida)
>> y operas con con esa matriz, es fácil que no tengas problemas. ¡No
>> deberías tenerlos!
>>
>> Un saludo,
>>
>> Carlos J. Gil Bellosta
>> http:///www.datanalytics.com
>>
>>
>>
>>
>>
>>
>> El día 22 de diciembre de 2015, 11:25, Francisco Rodriguez Sanchez
>> <f.rodriguez.sanc en gmail.com> escribió:
>>
>>> Hola Rubén,
>>>
>>> Totalmente de acuerdo con los consejos de Carlos. Ten en cuenta que
>>> aunque R
>>> disponga de varios (bastantes) GB de memoria, algunos de los objetos que
>>> va
>>> creando durante el proceso pueden consumirla por completo. Es decir, que
>>> aunque tu ordenador tenga 64GB de RAM, es posible que no queden 10 GB
>>> libres
>>> para almacenar un objeto (porque ya hay demasiados objetos grandes en la
>>> memoria).
>>>
>>> Sinceramente, más que intentar implementar los análisis en python 'de
>>> novo',
>>> creo que lo mejor es optimizar el código de R para evitar consumir toda
>>> la
>>> memoria. Por ejemplo, si miras el código de la función beta.pair del
>>> paquete
>>> betapart (pegado más abajo), verás que crea 3 objetos (beta.sim,
>>> beta.sne, y
>>> beta.sor) que probablemente son muy grandes. Y luego los convierte a cada
>>> uno en matriz de distancias (as.dist). En estas operaciones se te va la
>>> memoria, pues todos estos objetos están almacenados ahí.
>>>
>>> Por tanto, una solución fácil sería calcular cada una de estas cosas de
>>> una
>>> en una, y acto seguido almacenarla en disco y reiniciar R (o gestionar la
>>> memoria, con gc, etc, mira http://adv-r.had.co.nz/memory.html). Cuando
>>> ya lo
>>> tengas todo en disco puedes ir cargando objetos conforme los vayas
>>> necesitando. Si son demasiado grandes para leerlos, puedes usar el
>>> paquete
>>> ff y similares. Un manual muy bueno para big data en R:
>>> https://github.com/Robinlovelace/R-for-Big-Data.
>>>
>>> Así pues, desgranando y ejecutando una a unas las operaciones que
>>> ejecuta la
>>> función beta.pair, creo que puedes solucionar tu problema. O al menos eso
>>> espero!
>>>
>>> Mucha suerte
>>>
>>> Paco
>>>
>>>
>>>
>>> beta.pair <- function(x, index.family="sorensen"){
>>>
>>> # test for a valid index
>>> index.family <- match.arg(index.family, c('jaccard','sorensen'))
>>>
>>> # test for pre-existing betapart objects
>>> if (! inherits(x, "betapart")){
>>> x <- betapart.core(x)
>>> }
>>>
>>> # run the analysis given the index
>>> switch(index.family,
>>> sorensen = {
>>> beta.sim <- x$min.not.shared / (x$min.not.shared + x$shared)
>>> beta.sne <- ((x$max.not.shared - x$min.not.shared) / ((2 *
>>> x$shared) + x$sum.not.shared)) * (x$shared / (x$min.not.shared +
>>> x$shared))
>>> beta.sor <- x$sum.not.shared / (2 * x$shared +
>>> x$sum.not.shared)
>>>
>>> pairwise <- list(beta.sim=as.dist(beta.sim),
>>> beta.sne=as.dist(beta.sne),beta.sor=as.dist(beta.sor))},
>>> jaccard = {
>>> beta.jtu <- (2*x$min.not.shared) / ((2*x$min.not.shared) +
>>> x$shared)
>>> beta.jne <- ((x$max.not.shared - x$min.not.shared) /
>>> (x$shared +
>>> x$sum.not.shared)) * (x$shared / ((2*x$min.not.shared) + x$shared))
>>> beta.jac <- x$sum.not.shared / (x$shared + x$sum.not.shared)
>>>
>>> pairwise <- list(beta.jtu=as.dist(beta.jtu),
>>> beta.jne=as.dist(beta.jne),beta.jac=as.dist(beta.jac))})
>>>
>>> return(pairwise)
>>>
>>> }
>>>
>>> El 21/12/2015 a las 20:32, Carlos J. Gil Bellosta escribió:
>>>
>>>>
>>>> Hola, ¿qué tal?
>>>>
>>>> Haz tres cosas:
>>>>
>>>> 1) Prueba con subconjuntos de tus datos más pequeños: 1k, 2k, etc. a ver
>>>> si
>>>> funciona.
>>>> 2) Mientras tanto, vigila el uso de memoria de tu máquina. En
>>>> particular,
>>>> los del proceso R.
>>>> 3) Usa object.size para ver cuánto ocupan esos objetos que vas creando.
>>>>
>>>> Con eso verás dónde están los límites. Puede que la función beta.part no
>>>> sea muy eficiente en términos de uso de la memoria. Los objetos que
>>>> estás
>>>> creando deberían ocupar menos de 5GB.
>>>>
>>>> En un sistema operativo normal y moderno deberías poder usar toda la RAM
>>>> disponible. Usa (2) para ver cuánto come tu proceso de R.
>>>>
>>>> Un saludo,
>>>>
>>>> Carlos J. Gil Bellosta
>>>> http://www.datanalytics.com
>>>>
>>>> El 21 de diciembre de 2015, 11:08, Ruben Bermad <ruben_bm en hotmail.com>
>>>> escribió:
>>>>
>>>> Hola a tod en s,
>>>>> Soy nuevo en R-help-es, por lo que perdonadme si debería haber mandado
>>>>> este email a una sección en particular.
>>>>> Quería consultaros un error que me aparece en R al hacer una matriz de
>>>>> disimilitud a partir de una tabla con 6000 columnas x 11000 filas. El
>>>>> mensaje que da R es "cannot allocate vector of size 10Gb", y me resulta
>>>>> extraño ya que tengo 64 Gb de RAM disponible.
>>>>> He estado leyendo en los foros y manuales de R que si trabajo en una
>>>>> máquina de 64 bits sea Windows o Linux R no debería de tener un límite
>>>>> para
>>>>> ubicar un objeto, y que debería de usar toda la memoria física y
>>>>> virtual
>>>>> disponible, pero creo que no está siendo así.
>>>>> Por ello quisiera preguntaros si vosotros sabéis como puedo ampliar la
>>>>> memoria disponible (si este fuera de verdad el problema) o cómo puedo
>>>>> ubicar el vector en el disco y que no use la RAM.
>>>>> En concreto estoy intentando usar la función "beta.pair" del paquete
>>>>> "betapart"
>>>>> (https://cran.r-project.org/web/packages/betapart/betapart.pdf)
>>>>> sobre la matriz de 6000x11000. Es en este punto donde R me da el
>>>>> mensaje
>>>>> de
>>>>> error.
>>>>> Después me gustaría ejecutar la función "agnes" del paquete "cluster" o
>>>>> la
>>>>> función "hclust" del paquete "stats" sobre dicha matriz de
>>>>> disimilitud, y
>>>>> supongo que tendré un problema similar.
>>>>> El código exacto que he usado es:library(betapart)data_base # Base de
>>>>> datos de 6000 columnas x 11000 filasdistance <- beta.pair (data_base,
>>>>> index.family="sorensen") # Calculo de la matriz de disimilitud
>>>>> beta_similarity <- distance$beta.sim # Selecciono el tipo de medida que
>>>>> quiero
>>>>> library(cluster)UPGMA<- agnes (beta_similarity ) # Análisis UPGMA
>>>>>
>>>>> Soluciones que he intentado: Ante los problemas que he tenido, he
>>>>> intentado hacer la matriz de disimilitud en python. El problema es que
>>>>> no
>>>>> hay una función optimizada para la medida de disimilitud que quiero
>>>>> estimar
>>>>> (índice de simpson), y he tenido que escribir un código para que haga
>>>>> los
>>>>> cálculos por pares, pero va a tardar más de 8 días (y es un análisis
>>>>> que
>>>>> tengo que repetir muchas veces y no me parece muy viable). Por ello
>>>>> vuelvo
>>>>> a R para intentar buscar una solución con el manejo de esta gran base
>>>>> de
>>>>> datos.
>>>>> Os agradecería cualquier tipo de ayuda.
>>>>> Muchas gracias por adelantado,
>>>>> Un cordial saludo, Rubén
>>>>>
>>>>>
>>>>> [[alternative HTML version deleted]]
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> R-help-es mailing list
>>>>> R-help-es en r-project.org
>>>>> https://stat.ethz.ch/mailman/listinfo/r-help-es
>>>>>
>>>>> [[alternative HTML version deleted]]
>>>>
>>>> _______________________________________________
>>>> R-help-es mailing list
>>>> R-help-es en r-project.org
>>>> https://stat.ethz.ch/mailman/listinfo/r-help-es
>>>>
>>>
>>>
>>> --
>>> Dr Francisco Rodriguez-Sanchez
>>> Integrative Ecology Group
>>> Estacion Biologica de Doñana - CSIC
>>> Avda. Americo Vespucio s/n
>>> 41092 Sevilla (Spain)
>>> http://bit.ly/frod_san
>>>
>>>
>>> _______________________________________________
>>> R-help-es mailing list
>>> R-help-es en r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-help-es
>>>
>>
>> _______________________________________________
>> R-help-es mailing list
>> R-help-es en r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-help-es
>>
>>
> _______________________________________________
> R-help-es mailing list
> R-help-es en r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-help-es
>
[[alternative HTML version deleted]]
Más información sobre la lista de distribución R-help-es