写入临时文件的数据是否会影响 AWS lambda 中的内存使用？在 lambda 函数中，我将文件流式传输到临时文件。在 lambda 日志中，我看到使用的最大内存大于下载的文件。奇怪的是，如果快速连续多次调用 lambda，下载较小文件的调用仍然报告下载较大文件的调用使用的最大内存。我将并发限制设置为 2。

当我在本地运行代码时，我的内存使用量如预期的那样在 20MB 左右。在 lambda 上它是 180MB，大约是流式传输文件的大小。代码只是使用 python 请求库来流式传输文件下载，shutil.copyfileobj() 写入 tempfile.TemporaryFile()，然后通过管道传输到 postgres“从标准输入复制”。

这使得/tmp 存储空间似乎计入了内存使用量，但没有发现任何提及。 lambda 文档中唯一提到的/tmp 是有 512mb 的限制。

示例代码:

import sys
import json
import os
import io
import re
import traceback
import shutil
import tempfile

import boto3
import psycopg2
import requests


def handler(event, context):
    try:
        import_data(event["report_id"])
    except Exception as e:
        notify_failed(e, event)
        raise

def import_data(report_id):
    token = get_token()
    conn = psycopg2.connect(POSTGRES_DSN, connect_timeout=30)
    cur = conn.cursor()

    metadata = load_metadata(report_id, token)
    table = ensure_table(metadata, cur, REPLACE_TABLE)
    conn.commit()
    print(f"report {report_id}: downloading")
    with download_report(report_id, token) as f:
        print(f"report {report_id}: importing data")
        with conn, cur:
            cur.copy_expert(f"COPY {table} FROM STDIN WITH CSV HEADER", f)
        print(f"report {report_id}: data import complete")
    conn.close()


def download_report(report_id, token):
    url = f"https://some_url"
    params = {"includeHeader": True}
    headers = {"authorization": f"Bearer {token['access_token']}"}

    with requests.get(url, params=params, headers=headers, stream=True) as r:
        r.raise_for_status()
        tmp = tempfile.TemporaryFile()
        print("streaming contents to temporary file")
        shutil.copyfileobj(r.raw, tmp)
        tmp.seek(0)
        return tmp


if __name__ == "__main__":
    if len(sys.argv) > 1:
        handler({"report_id": sys.argv[1]}, None)

更新: 将代码更改为不使用临时文件，而是将下载直接流式传输到 postgres 复制命令后，内存使用量得到修复。让我觉得/tmp 目录有助于记录内存使用情况。

最佳答案

更新

注意: 为了回答这个问题，我使用了 Lambdash ，尽管我不得不修改用于 node8.10 的 lambda 版本。 Lambdash 是一个简单的小库，您可以使用它从本地终端对 lambda 运行 shell 命令。

AWS Lambdas 上的/tmp 目录挂载为 loop device .您可以通过(在遵循 lambdash 的设置说明之后)运行以下命令来验证这一点:

./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

根据 https://unix.stackexchange.com/questions/278647/overhead-of-using-loop-mounted-images-under-linux ,

data accessed through the loop device has to go through two filesystem layers, each doing its own caching so data ends up cached twice, wasting much memory (the infamous "double cache" issue)

但是，我的猜测是 /tmp 实际上保存在内存中。为了对此进行测试，我运行了以下命令:

./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

请记住，每次我运行它时，都会执行 lambda。以下是 Lambda 的 Cloudwatch 日志的输出:

07:06:30 START RequestId: 4143f502-14a6-11e9-bce4-eff8b92bf218 Version: $LATEST 07:06:30 END RequestId: 4143f502-14a6-11e9-bce4-eff8b92bf218 07:06:30 REPORT RequestId: 4143f502-14a6-11e9-bce4-eff8b92bf218 Duration: 3.60 ms Billed Duration: 100 ms Memory Size: 1536 MB Max Memory Used: 30 MB

07:06:32 START RequestId: 429eca30-14a6-11e9-9b0b-edfabd15c79f Version: $LATEST 07:06:34 END RequestId: 429eca30-14a6-11e9-9b0b-edfabd15c79f 07:06:34 REPORT RequestId: 429eca30-14a6-11e9-9b0b-edfabd15c79f Duration: 1396.29 ms Billed Duration: 1400 ms Memory Size: 1536 MB Max Memory Used: 430 MB

07:06:36 START RequestId: 44a03f03-14a6-11e9-83cf-f375e336ed87 Version: $LATEST 07:06:36 END RequestId: 44a03f03-14a6-11e9-83cf-f375e336ed87 07:06:36 REPORT RequestId: 44a03f03-14a6-11e9-83cf-f375e336ed87 Duration: 3.69 ms Billed Duration: 100 ms Memory Size: 1536 MB Max Memory Used: 431 MB

07:06:38 START RequestId: 4606381a-14a6-11e9-a32d-2956620824ab Version: $LATEST 07:06:38 END RequestId: 4606381a-14a6-11e9-a32d-2956620824ab 07:06:38 REPORT RequestId: 4606381a-14a6-11e9-a32d-2956620824ab Duration: 3.63 ms Billed Duration: 100 ms Memory Size: 1536 MB Max Memory Used: 431 MB

发生了什么，这是什么意思？

lambda 被执行了 4 次。在第一次执行时，我显示了已安装的设备。在第二次执行时，我在 /tmp 目录中填充了一个文件，使用了允许的 500Mb 中的 401Mb。在随后的执行中，我列出了已安装的设备，显示了它们的可用空间。

第一次执行的内存使用率为 30Mb。后续执行的内存利用率在 400Mb 范围内。

这证实了 /tmp 利用率确实有助于内存利用率。

原始答案

我的猜测是您正在观察的是 python，或者 lambda 容器本身，在写入操作期间在内存中缓冲文件。

根据 https://docs.python.org/3/library/functions.html#open ,

buffering is an optional integer used to set the buffering policy. Pass 0 to switch buffering off (only allowed in binary mode), 1 to select line buffering (only usable in text mode), and an integer > 1 to indicate the size in bytes of a fixed-size chunk buffer. When no buffering argument is given, the default buffering policy works as follows:

Binary files are buffered in fixed-size chunks; the size of the buffer is chosen using a heuristic trying to determine the underlying device’s “block size” and falling back on io.DEFAULT_BUFFER_SIZE. On many systems, the buffer will typically be 4096 or 8192 bytes long. “Interactive” text files (files for which isatty() returns True) use line buffering. Other text files use the policy described above for binary files.

tempfile.TemporaryFile() 函数有一个关键字参数buffering，它基本上直接传递到上述open 调用中。

所以我猜测 tempfile.TemporaryFile() 函数使用默认的 open() 函数的缓冲设置。您可以尝试使用 tempfile.TemporaryFile(buffering=0) 来禁用缓冲，或者尝试使用 tempfile.TemporaryFile(buffering=512) 来显式设置最大内存量在将数据写入文件时使用。

关于python - AWS lambda 内存使用与 python 代码中的临时文件，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/53899574/