Astropy: Posible error en memmap: memmap simplemente no funciona.

Creado en 26 ago. 2013  ·  12Comentarios  ·  Fuente: astropy/astropy

Estoy tratando de cargar algunas tablas de registros FITS gigantes usando memmap=True , y obtengo error: [Errno 12] Cannot allocate memory .

Una sesión de ejemplo:

filename = '/home/sdfits/AGBT12B_221_01/AGBT12B_221_01.raw.acs.fits'
import astropy.io.fits as fits
filefits = fits.open(filename,memmap=True)
data = filefits[2].data[:50]

El error está en esta línea:

/users/aginsbur/anaconda/lib/python2.7/site-packages/numpy/core/memmap.py(253)__new__()
--> 253             mm = mmap.mmap(fid.fileno(), bytes, access=acc, offset=start)

ipdb> bytes
23718381056L
ipdb> bytes/1024**2
22619L
ipdb> start
413921280
ipdb> acc
3

Realmente no sé qué está pasando, pero sospecho que memmap está decidiendo incorrectamente cuántos datos leer. ¿Algún consejo sobre cómo seguir depurando? ¿Es esto realmente un problema de FITS o un problema numpy?

Detalles:

In [15]: numpy.__version__
Out[15]: '1.7.1'

In [16]: astropy.__version__
Out[16]: '0.2.4'

In [18]: sys.maxint
Out[18]: 9223372036854775807
Bug Effort-medium Package-intermediate io.fits

Todos 12 comentarios

¿Qué sistema operativo?

¿Qué devuelve ulimit -v ?

OS es una especie de linux; no sé de la parte superior de mi cabeza o el
comando más fácil de averiguar.

Además, estaba usando la instalación anaconda de python / astropy / numpy pero actualizado
astropía a través de pip.

$ ulimit -v
ilimitado

El martes 27 de agosto de 2013 a las 4:02 p.m., Erik Bray [email protected] escribió:

¿Qué sistema operativo?

¿Qué devuelve ulimit -v?

-
Responda a este correo electrónico directamente o véalo en Gi
.

Adán

¿Qué muestra cat /proc/meminfo ?

$ cat /proc/meminfo
MemTotal:        1903396 kB
MemFree:          203864 kB
Buffers:          215320 kB
Cached:           884708 kB
SwapCached:         2268 kB
Active:           492052 kB
Inactive:         954324 kB
Active(anon):     165684 kB
Inactive(anon):   181096 kB
Active(file):     326368 kB
Inactive(file):   773228 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       1048568 kB
SwapFree:        1031460 kB
Dirty:                24 kB
Writeback:             0 kB
AnonPages:        344352 kB
Mapped:            65676 kB
Shmem:               432 kB
Slab:             191348 kB
SReclaimable:     151148 kB
SUnreclaim:        40200 kB
KernelStack:        2312 kB
PageTables:        22940 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     2000264 kB
Committed_AS:     847268 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      286128 kB
VmallocChunk:   34359439336 kB
HardwareCorrupted:     0 kB
AnonHugePages:     12288 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        8188 kB
DirectMap2M:     2070528 kB

... eso parece una pequeña cantidad de memoria; 2 GB? Hrmph.

@keflavich : ¿sigues viendo este problema?

Me olvidé por completo de esto. MemTotal es solo la memoria física total disponible. Estos 2GB no son mucho, claro, pero ese no debería ser el problema. Tiene alrededor de 32 TB por VmallocTotal que es lo que debería importar aquí; en principio, mmap debería poder usar la mayor parte de eso. Así que hay algo sospechoso aquí.

¡Ah! Creo que veo el problema aquí. Por defecto, PyFITS usa MAP_PRIVATE al abrir un archivo en modo de solo lectura para que los usuarios aún puedan modificar la matriz de datos en su lugar como lo harían si todo el archivo estuviera mapeado en la memoria principal.

El problema es que eso significa que, en principio, se puede sobrescribir todo el archivo, por lo que mmap debe poder asignar suficiente memoria con anticipación si eso ocurre. Por eso está sucediendo esto aquí. PyFITS / Astropy definitivamente debería detectar ese escenario y proporcionar un error más útil.

Actualmente hay dos formas de evitar esto: puede abrir el archivo con mode='denywrite . Lo agregué hace un tiempo específicamente para este caso, pero rara vez se usa. Eso abre el mmap con MAP_SHARED | PROT_READ esto significa que las páginas son de solo lectura (cualquier intento de modificar la matriz resultará en una excepción). Pero si todo lo que necesita es leer los datos, esto funciona bien y no creo que sea necesario asignar ningún espacio de intercambio.

Otra posibilidad es abrir con mode='update' . Luego, cualquier cambio en la matriz se puede sincronizar directamente con el archivo, lo cual está bien si lo desea, pero obviamente no tanto si no lo desea.

Mirando la página del manual, parece que también hay una marca, al menos en Linux, llamada MAP_NORESERVE que evitará que se asigne previamente espacio para copiar sobre escritura. Entonces, si no _necesita_ escribir ningún cambio en toda la matriz, eso también podría funcionar. Pero tendríamos que ser capaces de captar el SIGSEGV resultante si acabas quedando sin espacio de intercambio.

Logré reproducir esto directamente; de ​​hecho, las dos soluciones que ofrecí ( mode='denywrite' y mode='update' funcionan. Aún intentaré ver qué puedo hacer con MAP_NORESERVE , y de lo contrario detectando este error y proporcionando un mejor mensaje de error.

Molestia: numpy.memmap no permite modificar las banderas que se pasan a la llamada mmap . Aunque mirándolo, no es mucho más que una subclase ligera de ndarray que maneja el trabajo de crear un mmap con las banderas correctas y luego llamar a ndarray.__new__ con el mmap como su búfer. También agrega un método flush .

Debería ser bastante fácil evitar el uso de numpy.memmap y manejar mmap nosotros mismos. Pero eso es más de lo que quiero hacer con esto por ahora. Entonces, en cambio, resolveré este problema detectando el error y sugiriendo una de las soluciones existentes.

Tenga en cuenta que con # 7597 ya no usamos np.memmap , por lo que debería ser más fácil usar otras banderas si eso es útil.

Esto ahora se puede cerrar, ya que se ha combinado una solución en https://github.com/astropy/astropy/pull/7926. MAP_NORESERVE no está disponible en Python, por lo que lamentablemente esa no es una solución.

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

simontorres picture simontorres  ·  3Comentarios

JWDobken picture JWDobken  ·  3Comentarios

pllim picture pllim  ·  3Comentarios

Iko-7 picture Iko-7  ·  3Comentarios

larrybradley picture larrybradley  ·  3Comentarios