# Runtime de Python para instâncias gerenciadas do Lambda O runtime do Lambda usa vários processos do Python para lidar com solicitações simultâneas. Cada solicitação simultânea é executada em um processo separado com seu próprio espaço de memória e inicialização. Cada processo lida com uma solicitação por vez, de forma síncrona. Os processos não compartilham memória diretamente, então variáveis globais, caches em nível de módulo e objetos singleton são isolados entre solicitações simultâneas. ## Configuração de simultaneidade O número máximo de solicitações simultâneas que o Lambda envia para cada ambiente de execução é controlado pela definição `PerExecutionEnvironmentMaxConcurrency` da configuração da função. Essa é uma definição opcional e o valor padrão varia de acordo com o runtime. Para runtimes de Python, o padrão é 16 solicitações simultâneas por vCPU, ou é possível configurar seu próprio valor. Esse valor também determina o número de processos usados pelo runtime de Java. O Lambda ajusta automaticamente o número de solicitações simultâneas até o máximo configurado com base na capacidade de cada ambiente de execução de absorver essas solicitações. **Importante** Usar a simultaneidade baseada em processos significa que cada processo de operador de runtime executa sua própria inicialização. O uso total de memória é igual à memória por processo multiplicada pelo número de processos simultâneos. Se você estiver carregando grandes bibliotecas ou conjuntos de dados e tiver alta simultaneidade, ocupará uma grande quantidade de memória. De acordo com sua workload, talvez seja necessário ajustar a relação CPU/memória ou usar uma configuração de simultaneidade mais baixa para evitar exceder a memória disponível. É possível usar a métrica `MemoryUtilization` no CloudWatch para monitorar o consumo de memória. ## Funções de construção para multissimultaneidade Devido ao modelo de multissimultaneidade baseado em processos, as funções de instâncias gerenciadas do Lambda que usam runtimes de Python não acessam recursos na memória simultaneamente a partir de várias invocações. Não é preciso aplicar práticas de codificação para segurança de simultaneidade na memória. ## Diretório /tmp compartilhado O diretório `/tmp` é compartilhado entre todas as solicitações simultâneas no ambiente de execução. Gravações simultâneas no mesmo arquivo podem causar corrupção de dados, por exemplo, se outro processo sobrescrever o arquivo. Para resolver isso, implemente o bloqueio de arquivos para arquivos compartilhados ou use nomes de arquivo exclusivos por processo ou por solicitação para evitar conflitos. Lembre-se de limpar arquivos desnecessários para evitar o esgotamento do espaço disponível. ## Registro em log A intercalação de logs (entradas de logs de solicitações diferentes sendo intercaladas em logs) é normal em sistemas multissimultâneos. As funções que usam instâncias gerenciadas do Lambda sempre usam o formato de log de JSON estruturado introduzido com [controles de registro em log avançados](monitoring-logs.md#monitoring-cloudwatchlogs-advanced). Esse formato inclui o `requestId`, permitindo que as entradas de log sejam correlacionadas a uma única solicitação. Quando você usa o módulo `logging` da biblioteca padrão do Python no Lambda, o `requestId` é incluído automaticamente em cada entrada de log. Para obter mais informações, consulte [Uso de controles avançados de registro em log do Lambda com Python](https://docs.aws.amazon.com/lambda/latest/dg/python-logging.html#python-logging-advanced). ## Contexto da solicitação Use `context.aws_request_id` para acessar o ID da solicitação atual. Com os runtimes de Python, é possível usar a variável de ambiente `_X_AMZN_TRACE_ID` para acessar o ID de rastreamento do X-Ray com instâncias gerenciadas do Lambda. O ID de rastreamento do X-Ray é propagado automaticamente ao usar o AWS SDK. Use `context.get_remaining_time_in_millis()` para detectar tempos limite. Consulte [Tratamento de erros e recuperação](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling) para obter mais informações. ## Inicialização e desligamento A inicialização da função ocorre uma vez por processo. É possível visualizar ver entradas de log repetidas se sua função emitir logs durante a inicialização. Para as funções do Lambda com extensões, o ambiente de execução emite um sinal SIGTERM durante o desligamento. Esse sinal é usado pelas extensões para acionar tarefas de limpeza, como descarregar buffers. É possível se inscrever em eventos SIGTERM para acionar tarefas de limpeza de funções, como fechar conexões de banco de dados. Para saber mais sobre o ciclo de vida do ambiente de execução, consulte [Noções básicas sobre o ciclo de vida do ambiente de execução do Lambda](lambda-runtime-environment.md). ## Versões de dependências As instâncias gerenciadas do Lambda exigem as versões mínimas de pacotes a seguir: + Powertools para AWS Lambda (Python): versão 3,23.0 ou posterior ## Powertools para AWS Lambda (Python) O Powertools para AWS Lambda (Python) é compatível com as instâncias gerenciadas do Lambda e fornece utilitários para registro em log, rastreamento, métricas e muito mais. Para obter mais informações, consulte [Powertools para AWS Lambda (Python)](https://github.com/aws-powertools/powertools-lambda-python). ## Próximas etapas + Analise o [runtime de Java para instâncias gerenciadas do Lambda](lambda-managed-instances-java-runtime.md) + Analise o [runtime de Node.js para instâncias gerenciadas do Lambda](lambda-managed-instances-nodejs-runtime.md) + Analise o [runtime de .NET para instâncias gerenciadas do Lambda](lambda-managed-instances-dotnet-runtime.md) + Saiba mais sobre a [escalabilidade de instâncias gerenciadas do Lambda](lambda-managed-instances-scaling.md)