Что означает избыточная выделенная память для Lambda в AWS Cloudwatch?

Question

Я пытаюсь узнать больше о мониторинге и анализе функций лямд в моей безсерверной среде, чтобы понять, как указать «подозрительные» лямбды, которые требуют внимания. У меня есть несколько примеров запросов в разделах Logs Insights, и у меня есть несколько лямбд, которые имеют такой результат.

Я в основном пытаюсьПонимаете, если это что-то, что требует быстрого исправления, или если это не имеет большого значения, если имеется слишком много памяти с избыточным выделением ресурсов?

Стоит ли мне больше беспокоиться о проблемах Duration / Concurrency, чем об этом показателе?

Answer 1

TLDR : чрезмерно выделенная память и длительность влияют на стоимость биллинга. Оба параметра можно контролировать, где это возможно, до экономически выгодных значений.

Выделенная память вместе с продолжительностью и числом раз, которое лямбда выполняется за месяц, используется для вычисления стоимости биллинга за месяц. ^[1]

В настоящее время лямбда использует примерно 14% выделенной памяти при максимальной загрузке, оставшаяся часть может быть использована.

Есливы обрабатываете огромное количество запросов, сокращение перерасходованной памяти и продолжительности может быть экономически эффективным.

Я рекомендую выделить объем памяти sum of max load plus (50% - 75%) of max load и просмотреть продолжительность.

Параллельность не влияет на ежемесячную стоимость биллинга.
Некоторые цифры: ^[2]

• Default concurrency limit for functions = 100
• Hard set concurrency limit for account = 1000

Сокращение продолжительности означает, что вы можете обслуживать больше запросов одновременно. Предел параллелизма на учетную запись может быть увеличен при запросе в службу поддержки AWS.

Другой типичный обходной путь для проблем параллелизма - регулирование запросов с использованием очереди. Это может быть более дорогостоящим.

1. Лямбда, получающая запрос, создает новую тему SNS, конвертирует ее вместе с запросом, помещает в очередь сообщений и возвращает вызывающей стороне тему.
2. Вызывающий абонент получает тему и подписывается на нее.
3. Другая лямбда-функция обрабатывает очередь и сообщает состояние задания для темы.
4. Вызывающая сторона получает сообщение.

Ограничение учетной записи дляколичество тем установлено на 100 000 ^[3] .
Этот предел можно увеличить, обратившись в службу поддержки AWS. Хотя очистка тем, которые больше не нужны для хранения, может быть более подходящей.

Необходимость проектирования с помощью этих обходных путей для ограничений параллелизма может означать, что требования приложения больше подходят для традиционных веб-приложений, поддерживаемыхдолго работающий сервер.