Haz todo lo posible por entender el código correctamente antes de adaptarlo a tu trabajo y si tquieres aportar algo puedes compartirlo con nosotros.
Solución:
Actualizar
Nota: Para responder a esta pregunta, usé Lambdash, aunque tuve que modificar la versión lambda que se usa para node8.10. Lambdash es una pequeña biblioteca simple que puede usar para ejecutar comandos de shell en una lambda desde su terminal local.
El directorio / tmp en AWS Lambdas se monta como un dispositivo de bucle. Puede verificar esto (después de seguir las instrucciones de configuración para lambdash), ejecutando el siguiente comando:
./lambdash df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 30G 4.0G 26G 14% /
/dev/loop0 526M 872K 514M 1% /tmp
/dev/loop1 6.5M 6.5M 0 100% /var/task
Según https://unix.stackexchange.com/questions/278647/overhead-of-using-loop-mounted-images-under-linux,
los datos a los que se accede a través del dispositivo de bucle tienen que pasar por dos capas del sistema de archivos, cada una con su propio almacenamiento en caché para que los datos terminen en caché dos veces, desperdiciando mucha memoria (el infame problema de la “doble caché”)
Sin embargo, mi conjetura es que /tmp se guarda en la memoria. Para probar esto, ejecuté los siguientes comandos:
./lambdash df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 30G 4.0G 26G 14% /
/dev/loop0 526M 1.9M 513M 1% /tmp
/dev/loop1 6.5M 6.5M 0 100% /var/task
./lambdash dd if=/dev/zero of=/tmp/file.txt count=409600 bs=1024
409600+0 records in
409600+0 records out
419430400 bytes (419 MB) copied, 1.39277 s, 301 MB/s
./lambdash df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 30G 4.8G 25G 17% /
/dev/loop2 526M 401M 114M 78% /tmp
/dev/loop3 6.5M 6.5M 0 100% /var/task
./lambdash df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 30G 4.8G 25G 17% /
/dev/loop2 526M 401M 114M 78% /tmp
/dev/loop3 6.5M 6.5M 0 100% /var/task
Tenga en cuenta que cada vez que lo ejecuté, se ejecutó el lambda. A continuación se muestra el resultado de los registros de Cloudwatch de Lambda:
07:06:30 START RequestId: 4143f502-14a6-11e9-bce4-eff8b92bf218 Versión: $ LATEST 07:06:30 END RequestId: 4143f502-14a6-11e9-bce4-eff8b92bf218 07:06:30 REPORT RequestId: 4143f502-14a6- 11e9-bce4-eff8b92bf218 Duración: 3.60 ms Duración facturada: 100 ms Tamaño de memoria: 1536 MB Memoria máxima utilizada: 30 MB
07:06:32 START RequestId: 429eca30-14a6-11e9-9b0b-edfabd15c79f Versión: $ LATEST 07:06:34 END RequestId: 429eca30-14a6-11e9-9b0b-edfabd15c79f 07:06:34 REPORT RequestId: 429eca30-14a6- 11e9-9b0b-edfabd15c79f Duración: 1396.29 ms Duración facturada: 1400 ms Tamaño de memoria: 1536 MB Memoria máxima utilizada: 430 MB
07:06:36 START RequestId: 44a03f03-14a6-11e9-83cf-f375e336ed87 Versión: $ LATEST 07:06:36 END RequestId: 44a03f03-14a6-11e9-83cf-f375e336ed87 07:06:36 REPORT RequestId: 44a03f03 11e9-83cf-f375e336ed87 Duración: 3.69 ms Duración facturada: 100 ms Tamaño de memoria: 1536 MB Memoria máxima utilizada: 431 MB
07:06:38 START RequestId: 4606381a-14a6-11e9-a32d-2956620824ab Versión: $ ÚLTIMA 07:06:38 END RequestId: 4606381a-14a6-11e9-a32d-2956620824ab 07:06:38 REPORT RequestId: 4606381a-14a6- 11e9-a32d-2956620824ab Duración: 3.63 ms Duración facturada: 100 ms Tamaño de memoria: 1536 MB Memoria máxima utilizada: 431 MB
¿Qué pasó y qué significa esto?
La lambda se ejecutó 4 veces. En la primera ejecución, mostré dispositivos montados. En la segunda ejecución, llené un archivo en el /tmp directorio, utilizando 401Mb de los 500Mb permitidos. En las ejecuciones posteriores, enumeré los dispositivos montados, mostrando su espacio disponible.
La utilización de memoria en la primera ejecución fue de 30 Mb. La utilización de la memoria para las ejecuciones posteriores estuvo en el rango de 400Mb.
Esto confirma que /tmp de hecho, la utilización contribuye a la utilización de la memoria.
Respuesta original
Supongo que lo que está observando es python, o el contenedor lambda en sí, almacenando el archivo en la memoria durante las operaciones de escritura.
Según https://docs.python.org/3/library/functions.html#open,
el almacenamiento en búfer es un número entero opcional que se utiliza para establecer la política de almacenamiento en búfer. Pase 0 para desactivar el almacenamiento en búfer (solo se permite en modo binario), 1 para seleccionar el almacenamiento en búfer de línea (solo se puede usar en modo de texto) y un número entero> 1 para indicar el tamaño en bytes de un búfer de fragmentos de tamaño fijo. Cuando no se proporciona ningún argumento de almacenamiento en búfer, la política de almacenamiento en búfer predeterminada funciona de la siguiente manera:
Los archivos binarios se almacenan en el búfer en fragmentos de tamaño fijo; el tamaño del búfer se elige mediante una heurística que intenta determinar el “tamaño de bloque” del dispositivo subyacente y recurre a io.DEFAULT_BUFFER_SIZE. En muchos sistemas, el búfer suele tener una longitud de 4096 u 8192 bytes. Los archivos de texto “interactivos” (archivos para los que isatty () devuelve True) usan búfer de línea. Otros archivos de texto utilizan la política descrita anteriormente para archivos binarios.
El tempfile.TemporaryFile() la función tiene un parámetro de palabra clave, buffering, que básicamente se pasa directamente a la open llamada descrita anteriormente.
Entonces mi conjetura es que el tempfile.TemporaryFile() la función utiliza el valor predeterminado open() ajuste de almacenamiento en búfer de la función. Podrías intentar algo como tempfile.TemporaryFile(buffering=0) para deshabilitar el almacenamiento en búfer, o tempfile.TemporaryFile(buffering=512) para establecer explícitamente la cantidad máxima de memoria que se utilizará al escribir datos en un archivo.
Uso de /tmp no cuenta para el uso de memoria. El único caso en el que esto podría estar correlacionado es cuando lee el contenido del archivo en la memoria.
Al final de la web puedes encontrar las acotaciones de otros administradores, tú aún puedes dejar el tuyo si te apetece.