Estamos executando um teste de carga em um aplicativo que atinge um banco de dados Postgres.
Durante o teste, repentinamente obtemos um aumento na taxa de erro. Depois de analisar o comportamento da plataforma e da aplicação, notamos que:
- CPU do Postgres RDS é 100%
- Quedas de memória liberáveis neste mesmo servidor
E nos logs do postgres, vemos:
21/08/2018 08:19:48 UTC::@:[XXXXX]:LOG: o processo do servidor (PID XXXX) foi encerrado pelo sinal 9: morto
Depois de investigar e ler a documentação, parece que uma possibilidade é o linux oomkiller rodando e encerrando o processo.
Mas como estamos no RDS, não podemos acessar os logs do sistema/var/log mensagens para confirmar.
Alguém também pode:
- confirme se o oom killer realmente roda no AWS RDS para Postgres
- nos dê uma maneira de verificar isso?
- nos dê uma maneira de calcular a memória máxima usada pelo Postgres com base no número de conexões?
Não encontrei a resposta aqui:
Responder1
Mesmo que o OOM killer não tenha agido (provavelmente agiu), sustentar 100% da CPU e muito pouca memória livre é ruim para o desempenho.
Use um tamanho de instância maior e veja se o problema desaparece. Teste um tamanho menor em um Postgres não RDS que você controla e veja se o assassino do OOM fica com raiva.
O número de conexões não é necessariamente o fator dominante no consumo de memória: a memória compartilhada é usada para outras coisas e nem toda consulta usa uma grande quantidade de memória. Veja também esta conversa:PostgreSql aloca memória para cada conexão.
Conselhos adicionais deMelhores práticas para Amazon RDS
Recomendações de RAM para instâncias de banco de dados
Uma prática recomendada de desempenho do Amazon RDS é alocar RAM suficiente para que seu conjunto de trabalho resida quase completamente na memória. Para saber se o seu conjunto de trabalho está quase todo na memória, verifique a métrica ReadIOPS (usando Amazon CloudWatch) enquanto a instância de banco de dados está sob carga. O valor de ReadIOPS deve ser pequeno e estável. Se aumentar a escala da classe de instância de banco de dados (para uma classe com mais RAM) resultar em uma queda drástica no ReadIOPS, seu conjunto de trabalho não estava quase completamente na memória. Continue a aumentar até que o ReadIOPS não caia mais drasticamente após uma operação de escalonamento ou até que o ReadIOPS seja reduzido a uma quantidade muito pequena.
Avaliando métricas de desempenho
Memória liberável – quanta RAM está disponível na instância de banco de dados, em megabytes. A linha vermelha nas métricas da guia Monitoramento está marcada em 75% para métricas de CPU, memória e armazenamento. Se o consumo de memória da instância ultrapassar essa linha com frequência, isso indica que você deve verificar sua carga de trabalho ou atualizar sua instância.
Responder2
Não tenho muita experiência com Postgres, mas na mesma situação descubro que uma instância RDS MySql tende a ser totalmente reinicializada. Mesmo que você não tenha acesso aos sistemas subjacentes, você poderá obter os logs do postgres por meio do console da web. Procure uma reinicialização, o daemon deve indicar que está fechando e iniciando.
De qualquer forma, se você estiver trabalhando em zona de perigo. não há muito que você possa fazer. Você deve mudar para uma instância com mais RAM/CPU disponível.