¿Hay alguna restricción de memoria en una aplicación ASP.Net?
large-files out-of-memory (5)
Tengo una aplicación ASP.Net MVC que permite a los usuarios subir imágenes. Cuando intento subir un archivo realmente grande (400 MB), aparece un error.
Supuse que mi código de procesamiento de imágenes (home brew) era muy ineficiente, así que decidí intentar con una biblioteca de terceros para manejar las partes de procesamiento de imágenes.
Debido a que estoy usando TDD, primero quería escribir una prueba que falla. Pero cuando pruebo la acción del controlador con el mismo archivo grande, puedo hacer todo el procesamiento de la imagen sin ningún problema.
El error que recibo es "Sin memoria".
Estoy seguro de que mi código probablemente use mucha más memoria de la que necesita, pero solo quiero saber por qué pasa mi prueba.
La otra diferencia es que estoy usando SWFUpload que no se usa con la prueba. Podria ser esta la causa?
¿De dónde exactamente se origina la excepción?
AFAIK no hay un límite de calibre de 400 MB para los tamaños de imagen en ASP.net/.Net. Estoy escribiendo un proyecto donde algunos archivos son mucho más grandes. Puede que haya un límite más alto del que no estoy al tanto, por supuesto, pero parecería extraño y arbitrario.
¿Estás corriendo en una máquina de 64 bits? ¿Podría su archivo de imagen, sin comprimir (es 400 MB en jpg?), Probar el límite de 2 GB del espacio de direcciones de su proceso?
Debe asegurarse de desconectar los datos del flujo de entrada en una cadena de archivos de algún tipo para que no se necesite toda la entidad de solicitud en la memoria.
Desde MSDN :
Una forma de protegerse contra los ataques de denegación de servicio es limitar el tamaño de los archivos que se pueden cargar utilizando el control FileUpload. Debe establecer un límite de tamaño apropiado para los tipos de archivos que espera cargar. El límite de tamaño predeterminado es 4096 kilobytes (KB) o 4 megabytes (MB). Puede permitir que se carguen archivos más grandes estableciendo el atributo maxRequestLength del elemento httpRuntime. Para aumentar el tamaño de archivo máximo permitido para toda la aplicación, establezca el atributo maxRequestLength en el archivo Web.config. Para aumentar el tamaño de archivo máximo permitido para una página específica, establezca el atributo maxRequestLength dentro del elemento de ubicación en Web.config. Para ver un ejemplo, vea Elemento de ubicación (Esquema de configuración de ASP.NET).
Al cargar archivos de gran tamaño, un usuario también puede recibir el siguiente mensaje de error:
aspnet_wp.exe (PID: 1520) se recicló porque el consumo de memoria excedió los 460 MB (60 por ciento de RAM disponible).
Si los usuarios encuentran este mensaje de error, aumente el valor del atributo memoryLimit en el elemento processModel del archivo Web.config para la aplicación. El atributo memoryLimit especifica la cantidad máxima de memoria que puede usar un proceso de trabajo. Si el proceso de trabajo excede el importe de MemoryLimit, se crea un nuevo proceso para reemplazarlo, y todas las solicitudes actuales se reasignan al nuevo proceso.
Puede haber límites de memoria configurados en web.config o machine.config, o en ambos.
En web.config, la sección es:
<httpRuntime
executionTimeout="3600"
maxRequestLength="102400"
/>
En machine.config, la sección también puede ser la sección httpRunTime, similar a:
<httpRuntime
executionTimeout="90"
maxRequestLength="4096"
useFullyQualifiedRedirectUrl="false"
minFreeThreads="8"
minLocalRequestFreeThreads="4"
appRequestQueueLimit="100"
/>
El proceso aspnet también se puede limitar a un porcentaje de la memoria total usando la sección processModel, ver:
http://msdn.microsoft.com/en-us/library/7w2sway1.aspx
He encontrado problemas similares a los que describió por esos ajustes.
En particular, el atributo ProcessModel memorylimit.
Realmente no existe un límite estricto para los tamaños de carga. Sin embargo, si está en un proceso de 32 bits, puede estar limitado por la cantidad de memoria que su proceso de trabajo asp.net puede abordar. Una vez que llega a los 800mb, se vuelve muy inestable.
Los ajustes de tiempo de espera mencionados por Bravax también son un buen lugar para verificar.
¡Saludos al usar TDD!