# Performance e escalabilidade do Amazon Aurora PostgreSQL
As seções a seguir descrevem o gerenciamento da performance e da escalabilidade de um cluster de bancos de dados Amazon Aurora PostgreSQL. Também inclui informações sobre outras tarefas de manutenção.
**Topics**
+ [Dimensionar instâncias de bancos de dados Aurora PostgreSQL](#AuroraPostgreSQL.Managing.Performance.InstanceScaling)
+ [Número máximo de conexões com uma instância de bancos de dados Aurora PostgreSQL](#AuroraPostgreSQL.Managing.MaxConnections)
+ [Limites de armazenamento temporário para o Aurora PostgreSQL](#AuroraPostgreSQL.Managing.TempStorage)
+ [Páginas grandes para o Aurora PostgreSQL](#AuroraPostgreSQL.Managing.HugePages)
+ [Teste do Amazon Aurora PostgreSQL usando consultas de injeção de falhas](AuroraPostgreSQL.Managing.FaultInjectionQueries.md)
+ [Exibir o status do volume para um cluster de bancos de dados Aurora PostgreSQL](AuroraPostgreSQL.Managing.VolumeStatus.md)
+ [Como especificar o disco de RAM para o stats\$1temp\$1directory](AuroraPostgreSQL.Managing.RamDisk.md)
+ [Gerenciar arquivos temporários com o PostgreSQL](PostgreSQL.ManagingTempFiles.md)
## Dimensionar instâncias de bancos de dados Aurora PostgreSQL
Você pode escalar instâncias de banco de dados Aurora PostgreSQL de duas maneiras: com escalabilidade de instância e escalabilidade de leitura. Para ter mais informações sobre a escalabilidade de leitura, consulte [Escalabilidade de leitura](Aurora.Managing.Performance.md#Aurora.Managing.Performance.ReadScaling).
Você pode escalar o cluster de bancos de dados Aurora Postgree modificando a classe da instância de banco de dados para cada instância de banco de dados do cluster. O Aurora PostgreSQL é compatível com várias classes de instância de banco de dados otimizada para o Aurora. Não use classes de instância db.t2 ou db.t3 para clusters do Aurora maiores com tamanho superior a 40 terabytes (TB).
**nota**
Recomendamos usar as classes de instância de banco de dados T somente para servidores de desenvolvimento e teste, ou outros servidores que não sejam de produção. Para obter mais detalhes sobre as classes de instâncias T, consulte [Tipos de classe de instância de banco de dados](Concepts.DBInstanceClass.Types.md).
A escalabilidade não é instantânea. Pode levar 15 minutos ou mais para concluir a alteração em uma classe de instância de banco de dados diferente. Se você usar essa abordagem para modificar a classe da instância de banco de dados, aplique a alteração durante a próxima janela de manutenção programada (em vez de fazer isso imediatamente) para evitar o impacto nos usuários.
Como alternativa à modificação da classe de instância de banco de dados diretamente, você pode minimizar o tempo de inatividade usando os recursos de alta disponibilidade do Amazon Aurora. Primeiro, adicione uma réplica do Aurora ao cluster. Ao criar a réplica, escolha o tamanho da classe de instância de banco de dados que deseja usar para o cluster. Quando a réplica do Aurora é sincronizada com o cluster, você faz o failover para a réplica recém-adicionada. Para saber mais, consulte [Réplicas do Aurora](Aurora.Replication.md#Aurora.Replication.Replicas) e [Failover rápido com o Amazon Aurora PostgreSQL](AuroraPostgreSQL.BestPractices.FastFailover.md).
Para obter especificações detalhadas das classes de instância de banco de dados compatíveis com o Aurora PostgreSQL, consulte [Mecanismos de banco de dados compatíveis para classes de instância de banco de dados](Concepts.DBInstanceClass.SupportAurora.md).
## Número máximo de conexões com uma instância de bancos de dados Aurora PostgreSQL
Um cluster de bancos de dados do Aurora aloca recursos baseados na classe da instância de banco de dados e na memória disponível. Cada conexão com o cluster de banco de dados consome quantidades incrementais desses recursos, como memória e CPU. A memória consumida por conexão varia de acordo com o tipo de consulta, contagem e se tabelas temporárias são usadas. Até mesmo uma conexão ociosa consome memória e CPU. Isso porque quando as consultas são realizadas em uma conexão, mais memória é alocada para cada consulta e ela não é liberada completamente, mesmo quando o processamento é interrompido. Assim, recomendamos que você verifique se suas aplicações não estão segurando conexões ociosas: cada uma desperdiça recursos e afeta negativamente a performance. Para ter mais informações, consulte [Recursos consumidos por conexões ociosas do PostgreSQL](https://aws.amazon.com/blogs/database/resources-consumed-by-idle-postgresql-connections/).
O número máximo de conexões permitido para uma instância de bancos de dados Aurora PostgreSQL é determinado pelo valor de parâmetro `max_connections` especificado no grupo de parâmetros para esta instância de banco de dados. O cenário ideal para o parâmetro `max_connections` é aquele que suporta todas as conexões do cliente que sua aplicação precisa, sem excesso de conexões não utilizadas, além de pelo menos mais 3 conexões para suportar automação da AWS. Antes de modificar a configuração do parâmetro `max_connections`, recomendamos considerar o seguinte:
+ Se o valor de `max_connections` é muito baixo, a instância de bancos de dados Aurora PostgreSQL pode não ter conexões suficientes disponíveis quando os clientes tentam se conectar. Se isso acontecer, ele tentará se conectar usando o `psql` para gerar mensagens de erro, como as seguintes:
```
psql: FATAL: remaining connection slots are reserved for non-replication superuser connections
```
+ Se o valor de `max_connections` excede o número de conexões que são realmente necessárias, as conexões não utilizadas podem causar queda de performance.
O valor padrão de `max_connections` é derivado da seguinte função `LEAST` do Aurora PostgreSQL:
`LEAST({DBInstanceClassMemory/9531392},5000)`.
Se quiser alterar o valor para `max_connections`, você precisará criar um grupo de parâmetros de cluster de banco de dados personalizado e alterar seu valor. Depois de aplicar o grupo de parâmetros de banco de dados personalizado ao cluster, reinicialize a instância principal para que o novo valor seja aplicado. Para obter mais informações, consulte [Amazon Aurora PostgreSQL parameters](AuroraPostgreSQL.Reference.ParameterGroups.md) e [Criar um grupo de parâmetros de cluster de banco de dadosno Amazon Aurora](USER_WorkingWithParamGroups.CreatingCluster.md).
**dica**
Se suas aplicações abrem e fecham conexões com frequência ou mantêm um grande número de conexões de longa duração abertas, recomendamos usar o Amazon RDS Proxy. O RDS Proxy é um proxy de banco de dados totalmente gerenciado e altamente disponível que usa grupos de conexões para compartilhar conexões de banco de dados de forma segura e eficiente. Para saber mais sobre o RDS Proxy, consulte [Amazon RDS Proxypara Aurora](rds-proxy.md).
Para obter detalhes sobre como as instâncias do Aurora Serverless v2 lidam com esse parâmetro, consulte [Conexões máximas do Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max-connections).
## Limites de armazenamento temporário para o Aurora PostgreSQL
O Aurora PostgreSQL armazena tabelas e índices no subsistema de armazenamento do Aurora. O Aurora PostgreSQL usa armazenamento temporário separado para arquivos temporários não persistentes. Isso inclui arquivos que são usados para fins como classificar grandes conjuntos de dados durante o processamento de consultas ou para operações de compilação de índice. Para obter mais informações, consulte o artigo [Como posso solucionar problemas de armazenamento local em instâncias do Aurora compatível com PostgreSQL?](https://repost.aws/knowledge-center/postgresql-aurora-storage-issue).
Esses volumes de armazenamento local são apoiados pelo Amazon Elastic Block Store e podem ser estendidos utilizando uma classe de instância de banco de dados maior. Para ter mais informações sobre armazenamento, consulte [Armazenamento do Amazon Aurora](Aurora.Overview.StorageReliability.md). Também é possível aumentar o armazenamento local para objetos temporários usando um tipo de instância habilitado para NVMe e objetos temporários habilitados para o Aurora Optimized Reads. Para obter mais informações, consulte [Melhorar a performance das consultas do Aurora PostgreSQL com o Aurora Optimized Reads](AuroraPostgreSQL.optimized.reads.md).
**nota**
Você pode ver eventos de `storage-optimization` ao dimensionar instâncias de banco de dados, por exemplo, de db.r5.2xlarge para db.r5.4xlarge.
A tabela a seguir mostra a quantidade máxima de armazenamento temporário disponível para cada classe de instância de bancos de dados Aurora PostgreSQL. Para ter mais informações sobre o suporte a classes de instância de banco de dados para o Aurora, consulte [Classes de instâncias de banco de dados do Amazon Aurora](Concepts.DBInstanceClass.md).
| DB instance class | Armazenamento temporário máximo disponível (GiB) |
| --- | --- |
| db.x2g.16xlarge | 1.829 |
| db.x2g.12xlarge | 1.606 |
| db.x2g.8xlarge | 1.071 |
| db.x2g.4xlarge | 535 |
| db.x2g.2xlarge | 268 |
| db.x2g.xlarge | 134 |
| db.x2g.large | 67 |
| db.r8g.48xlarge | 3.072 |
| db.r8g.24xlarge | 1.536 |
| db.r8g.16xlarge | 998 |
| db.r8g.12xlarge | 749 |
| db.r8g.8xlarge | 499 |
| db.r8g.4xlarge | 250 |
| db.r8g.2xlarge | 125 |
| db.r8g.xlarge | 63 |
| db.r8g.large | 31 |
| db.r7g.16xlarge | 1.008 |
| db.r7g.12xlarge | 756 |
| db.r7g.8xlarge | 504 |
| db.r7g.4xlarge | 252 |
| db.r7g.2xlarge | 126 |
| db.r7g.xlarge | 63 |
| db.r7g.large | 32 |
| db.r7i.48xlarge | 3.072 |
| db.r7i.24xlarge | 1.500 |
| db.r7i.16xlarge | 1.008 |
| db.r7i.12xlarge | 748 |
| db.r7i.8xlarge | 504 |
| db.r7i.4xlarge | 249 |
| db.r7i.2xlarge | 124 |
| db.r7i.xlarge | 62 |
| db.r7i.large | 31 |
| db.r6g.16xlarge | 1008 |
| db.r6g.12xlarge | 756 |
| db.r6g.8xlarge | 504 |
| db.r6g.4xlarge | 252 |
| db.r6g.2xlarge | 126 |
| db.r6g.xlarge | 63 |
| db.r6g.large | 32 |
| db.r6i.32xlarge | 1.829 |
| db.r6i.24xlarge | 1.500 |
| db.r6i.16xlarge | 1.008 |
| db.r6i.12xlarge | 748 |
| db.r6i.8xlarge | 504 |
| db.r6i.4xlarge | 249 |
| db.r6i.2xlarge | 124 |
| db.r6i.xlarge | 62 |
| db.r6i.large | 31 |
| db.r5.24xlarge | 1.500 |
| db.r5.16xlarge | 1.008 |
| db.r5.12xlarge | 748 |
| db.r5.8xlarge | 504 |
| db.r5.4xlarge | 249 |
| db.r5.2xlarge | 124 |
| db.r5.xlarge | 62 |
| db.r5.large | 31 |
| db.r4.16xlarge | 960 |
| db.r4.8xlarge | 480 |
| db.r4.4xlarge | 240 |
| db.r4.2xlarge | 120 |
| db.r4.xlarge | 60 |
| db.r4.large | 30 |
| db.t4g.large | 16,5 |
| db.t4g.medium | 8,13 |
| db.t3.large | 16 |
| db.t3.medium | 7,5 |
**nota**
Os tipos de instância habilitados para NVMe podem aumentar o espaço temporário disponível em até o tamanho total do NVMe. Para obter mais informações, consulte [Melhorar a performance das consultas do Aurora PostgreSQL com o Aurora Optimized Reads](AuroraPostgreSQL.optimized.reads.md).
É possível monitorar o armazenamento temporário disponível para uma instância de banco de dados com a métrica do CloudWatch `FreeLocalStorage`, descrita em [Métricas do Amazon CloudWatch para o Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). (Isso não se aplica ao Aurora Serverless v2.)
Para algumas workloads, é possível reduzir a quantidade de armazenamento temporário alocando mais memória para os processos que estão realizando a operação. Para aumentar a memória disponível para uma operação, aumentando os valores dos parâmetros do PostgreSQL [work\$1mem](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) ou [maintenance\$1work\$1mem](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM).
## Páginas grandes para o Aurora PostgreSQL
*Páginas grandes* são um recurso de gerenciamento de memória que reduz a sobrecarga quando uma instância de banco de dados está trabalhando com grandes blocos contíguos de memória, como os usados por buffers compartilhados. Esse recurso PostgreSQL é compatível com todas as versões do Aurora PostgreSQL atualmente disponíveis.
O parâmetro `Huge_pages` é ativado por padrão para todas as classes de instância de banco de dados que não sejam classes de instância de banco de dados t3.medium, db.t3.large, db.t4g.medium e db.t4g.large. Você não pode alterar o valor do parâmetro `huge_pages` nem desativar esse recurso nas classes de instância compatíveis do Aurora PostgreSQL.
Nas instâncias de banco de dados do Aurora PostgreSQL que não comportam o recurso de memória de páginas enormes, o uso da memória específica do processo pode aumentar sem alterações correspondentes na workload.
O sistema aloca segmentos de memória compartilhada, como o cache do buffer, durante a inicialização do servidor. Quando não há páginas enormes de memória, o sistema não cobra essas alocações do processo postmaster. Em vez disso, ele inclui a memória no processo que primeiro acessou cada página de 4 KB no segmento de memória compartilhada.
**nota**
As conexões ativas compartilham a memória alocada conforme necessário, independentemente de como o uso da memória compartilhada é rastreado entre os processos.