memory-leaks wolfram-mathematica memory-management

memory leaks - Reducir el uso de memoria en una sesión extendida de Mathematica



memory-leaks wolfram-mathematica (2)

Has intentado evaluar $HistoryLength=0; en todos los subkernels y también en el kernel maestro? El seguimiento de historial es la fuente más común para quedarse sin memoria.

¿Has intentado no utilizar Export lenta y que consuma Export memoria y usar en su lugar una Put rápida y eficiente?

No está claro en su publicación donde evalúa ClearSystemCache[] - en el kernel maestro o en subkernels? Parece que lo evalúas solo en el kernel maestro. Trate de evaluarlo en todos los subkernels también antes de cada iteración.

Estoy haciendo algunos cálculos bastante largos, que pueden abarcar fácilmente unos pocos días. En el curso de estos cálculos, a veces Mathematica se quedará sin memoria. Con este fin, he terminado recurriendo a algo como:

ParallelEvaluate[$KernelID]; (* Force the kernels to launch *) kernels = Kernels[]; Do[ If[Mod[iteration, n] == 0, CloseKernels[kernels]; LaunchKernels[kernels]; ClearSystemCache[]]; (* Complicated stuff here *) Export[...], (* If a computation ends early I don''t want to lose past results *) {iteration, min, max}]

Esto es genial y todo, pero con el tiempo el kernel principal acumula memoria. Actualmente, mi kernel principal está consumiendo aproximadamente 1.4 GB de RAM. ¿Hay alguna manera en que pueda obligar a Mathematica a borrar la memoria que está usando? He intentado tirar basura en Share y Clear largo de los muchos Modules que estoy usando en mi código, pero la memoria todavía parece acumularse con el tiempo.

También he intentado asegurarme de que no tengo nada complicado y grande ejecutando fuera de un Module , de modo que algo no permanezca en el alcance demasiado tiempo. Pero incluso con esto, todavía tengo problemas de memoria.

¿Hay algo que pueda hacer al respecto? Siempre voy a tener una gran cantidad de memoria en uso, ya que la mayoría de mis cálculos involucran varias matrices grandes y densas (generalmente 1200 x 1200, pero puede ser más), por lo que soy cauteloso sobre el uso de MemoryConstrained .

Actualizar:

El problema fue exactamente lo que Alexey Popkov declaró en su respuesta. Si usa el Module , la memoria se fugará lentamente con el tiempo. Sucedió que se exacerbó en este caso porque tuve múltiples declaraciones del Module[..] . El Module "principal" estaba dentro de una ParallelTable donde 8 núcleos se ejecutaban a la vez. Aproveche el (relativamente) gran número de iteraciones, y este fue un caldo de cultivo para muchas pérdidas de memoria debido al error con el Module .


Dado que está utilizando el Module extensamente, creo que le puede interesar conocer este error con las variables temporales del Module no eliminan.

Ejemplo (variables temporales no vinculadas no eliminadas con sus definiciones):

In[1]:= $HistoryLength=0; a[b_]:=Module[{c,d},d:=9;d/;b===1]; Length@Names[$Context<>"*"] Out[3]= 6 In[4]:= lst=Table[a[1],{1000}]; Length@Names[$Context<>"*"] Out[5]= 1007 In[6]:= lst=. Length@Names[$Context<>"*"] Out[7]= 1007 In[8]:= Definition@d$999 Out[8]= Attributes[d$999]={Temporary} d$999:=9

Tenga en cuenta que en el código anterior configuro $HistoryLength = 0; para enfatizar este comportamiento defectuoso del Module . Si no lo hace, las variables temporales aún se pueden vincular desde variables de historial (entrada y Out ) y no se eliminarán con sus definiciones debido a este motivo en un conjunto más amplio de casos (no es un error sino una característica, como Leonid mencionado).

ACTUALIZACIÓN: solo para el registro. Hay otro error anterior con las variables del Module sin eliminar sin referencia después de las asignaciones de Part en v.5.2 que no está completamente corregido, incluso en la versión 7.0.1:

In[1]:= $HistoryLength=0;$Version Module[{L=Array[0&,10^7]},L[[#]]++&/@Range[100];]; Names["L$*"] ByteCount@Symbol@#&/@Names["L$*"] Out[1]= 7.0 for Microsoft Windows (32-bit) (February 18, 2009) Out[3]= {L$111} Out[4]= {40000084}