# 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. # Teste do Amazon Aurora PostgreSQL usando consultas de injeção de falhas Você pode testar a tolerância a falhas do cluster de banco de dados Aurora PostgreSQL usando consultas de injeção de falha. Consultas de injeção de falhas são emitidas como comandos SQL para uma instância do Amazon Aurora. As consultas de injeção de falhas permitem que você trave a instância para que consiga testar o failover e a recuperação. Você também pode simular uma falha da réplica do Aurora, uma falha do disco e um congestionamento do disco. As consultas de injeção de falhas são compatíveis com todas as versões disponíveis do Aurora PostgreSQL, conforme mostrado a seguir. + Aurora PostgreSQL versões 12, 13, 14 e posteriores + Aurora PostgreSQL versão 11.7 e posteriores + Aurora PostgreSQL versão 10.11 e posteriores **Topics** + [Teste de pane da instância](#AuroraPostgreSQL.Managing.FaultInjectionQueries.Crash) + [Teste de falha em uma réplica do Aurora](#AuroraPostgreSQL.Managing.FaultInjectionQueries.ReplicaFailure) + [Teste de uma falha de disco](#AuroraPostgreSQL.Managing.FaultInjectionQueries.DiskFailure) + [Teste de congestionamento de disco](#AuroraPostgreSQL.Managing.FaultInjectionQueries.DiskCongestion) Quando uma consulta de injeção de falha especifica uma falha, ela força uma falha da instância de bancos de dados Aurora PostgreSQL. As outras consultas de injeção de falha resultam em simulações de eventos de falha, mas não desencadeiam o evento. Ao enviar uma consulta de injeção de falha, especifique também um período para a simulação do evento de falha. Você pode enviar uma consulta de injeção de falha a uma das instâncias da réplica do Aurora conectando-se ao endpoint da réplica do Aurora. Para obter mais informações, consulte [Conexões de endpoints do Amazon Aurora](Aurora.Overview.Endpoints.md). ## Teste de pane da instância Você pode forçar uma pane em uma instância do Aurora PostgreSQL usando a função de consulta de injeção de falha `aurora_inject_crash()`. No que tange a essa consulta de injeção de falha, não ocorre um failover. Se desejar testar um failover, é possível escolher a ação de instância **Failover** para o cluster de banco de dados no console do RDS ou usar o comando [failover-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html) da AWS CLI ou a operação de API [FailoverDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html) do RDS. **Sintaxe** ``` 1. SELECT aurora_inject_crash ('instance' | 'dispatcher' | 'node'); ```Opções Esta consulta de injeção de falha considera um dos seguintes tipos de pane. O tipo de falha não diferencia maiúsculas de minúsculas: *'instance'* uma pane é simulada no banco de dados compatível com PostgreSQL para a instância do Amazon Aurora. *'dispatcher'* uma falha no dispatcher é simulada na instância primária do cluster de banco de dados de Aurora. O *dispatcher* grava atualizações no volume do cluster para um cluster de banco de dados do Amazon Aurora. *'node'* uma pane é simulada no banco de dados compatível com PostgreSQL e no dispatcher para a instância do Amazon Aurora. ## Teste de falha em uma réplica do Aurora Você pode simular a falha de uma réplica do Aurora usando a função de consulta de injeção de falha `aurora_inject_replica_failure()`. Uma falha de réplica do Aurora bloqueia a replicação para a réplica do Aurora ou todas as réplicas do Aurora no cluster de banco de dados pela porcentagem especificada para o intervalo de tempo especificado. Quando o intervalo de tempo acabar, as réplicas afetadas do Aurora são automaticamente sincronizadas com a instância primária. **Sintaxe** ``` 1. SELECT aurora_inject_replica_failure( 2. percentage_of_failure, 3. time_interval, 4. 'replica_name' 5. ); ```Opções Esta consulta de injeção de falha considera os seguintes parâmetros: *percentage\$1of\$1failure* A porcentagem de replicação para bloquear durante o evento de falha. Esse valor pode ser um duplo entre 0 e 100. Se você especificar 0, nenhuma replicação será bloqueada. Se você especificar 100, toda replicação será bloqueada. *time\$1interval* O tempo necessário para simular a falha da réplica do Aurora. O intervalo é em segundos. Por exemplo, se o valor é 20, a simulação é executada por 20 segundos. Especifique o intervalo de tempo do evento de falha da réplica do Aurora; com cautela. Se você especificar um intervalo muito longo e sua instância registrar uma grande quantidade de dados durante o evento de falha, seu cluster de banco de dados Aurora poderá presumir que sua réplica do Aurora entrou em pane e substituí-la. *replica\$1name* A réplica do Aurora na qual a simulação de falha será injetada. Especifique o nome de uma réplica do Aurora para simular uma falha de uma única réplica do Aurora. Especifique uma string vazia para simular falhas para todas as réplicas do Aurora no cluster de banco de dados. Para identificar nomes de réplica, consulte a coluna `server_id` na função `aurora_replica_status()`. Por exemplo: ``` postgres=> SELECT server_id FROM aurora_replica_status(); ``` ## Teste de uma falha de disco Você pode simular a falha de um disco para um cluster de bancos de dados Aurora PostgreSQL usando a função de consulta de injeção de falha `aurora_inject_disk_failure()`. Durante uma simulação de falha de disco, o cluster de bancos de dados Aurora PostgreSQL marca aleatoriamente segmentos do disco como falhos. As solicitações feitas a esses segmentos são bloqueadas durante a simulação. **Sintaxe** ``` 1. SELECT aurora_inject_disk_failure( 2. percentage_of_failure, 3. index, 4. is_disk, 5. time_interval 6. ); ```Opções Esta consulta de injeção de falha considera os seguintes parâmetros: *percentage\$1of\$1failure* a porcentagem do disco para marcar como falha durante o evento de falha. Esse valor pode ser um duplo entre 0 e 100. Se você especificar 0, nenhum dos discos será marcado como falhos. Se você especificar 100, o disco todo será marcado como falho. *índice* Um bloco de dados lógico específico para simular o evento de falha. Se você exceder o intervalo de blocos lógicos ou nós de armazenamento de dados disponíveis, receberá um erro informando o valor máximo do índice pode ser especificado. Para evitar esse erro, consulte [Exibir o status do volume para um cluster de bancos de dados Aurora PostgreSQL](AuroraPostgreSQL.Managing.VolumeStatus.md). *is\$1disk* Indica se a falha de injeção é para um bloco lógico ou para um nó de armazenamento. Especificar como true significa que as falhas de injeção são para um bloco lógico. Especificar como false significa que as falhas de injeção são para um nó de armazenamento. *time\$1interval* A quantidade de tempo para simular a falha do disco. O intervalo é em segundos. Por exemplo, se o valor é 20, a simulação é executada por 20 segundos. ## Teste de congestionamento de disco Você pode simular o congestionamento de um disco para um cluster de bancos de dados Aurora PostgreSQL usando a função de consulta de injeção de falha `aurora_inject_disk_congestion()`. Durante uma simulação de congestionamento de disco, o cluster de bancos de dados Aurora PostgreSQL marca aleatoriamente segmentos do disco como congestionados. As solicitações feitas a esses segmentos serão atrasadas entre o tempo de atraso mínimo e máximo especificado enquanto durar a simulação. **Sintaxe** ``` 1. SELECT aurora_inject_disk_congestion( 2. percentage_of_failure, 3. index, 4. is_disk, 5. time_interval, 6. minimum, 7. maximum 8. ); ```Opções Esta consulta de injeção de falha considera os seguintes parâmetros: *percentage\$1of\$1failure* A porcentagem do disco para marcar como congestionada durante o evento de falha. Este é um valor duplo entre 0 e 100. Se você especificar 0, nenhum dos discos será marcado como congestionados. Se você especificar 100, o disco todo será marcado como congestionado. *índice* Um bloco lógico específico de dados ou nó de armazenamento usado para simular o evento de falha. Se você exceder o intervalo de blocos lógicos ou nós de armazenamento de dados disponíveis, receberá um erro informando o valor máximo do índice que você pode especificar. Para evitar esse erro, consulte [Exibir o status do volume para um cluster de bancos de dados Aurora PostgreSQL](AuroraPostgreSQL.Managing.VolumeStatus.md). *is\$1disk* Indica se a falha de injeção é para um bloco lógico ou para um nó de armazenamento. Especificar como true significa que as falhas de injeção são para um bloco lógico. Especificar como false significa que as falhas de injeção são para um nó de armazenamento. *time\$1interval* A quantidade de tempo para simular o congestionamento de disco. O intervalo é em segundos. Por exemplo, se o valor é 20, a simulação é executada por 20 segundos. *mínimo, máximo* A quantidade mínima e máxima de atraso de congestionamento em milissegundos. Os valores válidos variam de 0,0 a 100,0 milissegundos. Os segmentos de disco marcados como congestionados serão atrasados durante um período aleatório de tempo dentro do intervalo mínimo e máximo enquanto durar a simulação. O valor máximo deve ser maior que o valor mínimo. # Exibir o status do volume para um cluster de bancos de dados Aurora PostgreSQL No Amazon Aurora, um volume de cluster de banco de dados consiste em um acervo de blocos lógicos. Cada um deles representa 10 gigabytes de armazenamento alocado. Esses blocos são chamados de *grupos de proteção*. Os dados em cada grupo de proteção são replicados entre seis dispositivos de armazenamento físico, chamados de *nós de armazenamento*. Esses nós de armazenamento são alocados em três zonas de disponibilidade (AZs) na região onde reside o cluster de banco de dados. Por sua vez, cada nó de armazenamento contém um ou mais blocos lógicos de dados para o volume do cluster de banco de dados. Para obter mais informações sobre os grupos de proteção e os nós de armazenamento, consulte [ Introducing the Aurora storage engine (Apresentação do mecanismo de armazenamento do Aurora)](https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/) no blog de banco de dados da AWS. Para saber mais sobre volumes de cluster do Aurora em geral, consulte [Armazenamento do Amazon Aurora](Aurora.Overview.StorageReliability.md). Use a função `aurora_show_volume_status()` para retornar as seguintes variáveis de status do servidor: + `Disks` — o número total de blocos lógicos de dados para o volume do cluster de banco de dados. + `Nodes` **—** o número total de nós de armazenamento para o volume do cluster de banco de dados. É possível usar a função `aurora_show_volume_status()` para ajudar a evitar um erro ao usar a função de injeção de falha `aurora_inject_disk_failure()`. A função de injeção de falha `aurora_inject_disk_failure()` simula a falha de um nó de armazenamento completo ou um único bloco lógico de dados dentro de um nó de armazenamento Na função, especifique o valor do índice de um bloco lógico de dados ou de um nó de armazenamento específico. No entanto, a instrução retornará um erro se você especificar um valor de índice maior do que o número de blocos lógicos de dados ou de nós de armazenamento usados pelo volume do cluster de banco de dados. Para obter mais informações sobre as consultas de injeção de falha, veja [Teste do Amazon Aurora PostgreSQL usando consultas de injeção de falhas](AuroraPostgreSQL.Managing.FaultInjectionQueries.md). **nota** A função `aurora_show_volume_status()` está disponível para a versão 10.11 do Aurora PostgreSQL. Para obter mais informações sobre as versões do Aurora PostgreSQL, consulte [Versões Amazon Aurora PostgreSQL e versões do mecanismo](AuroraPostgreSQL.Updates.20180305.md). **Sintaxe** ``` 1. SELECT * FROM aurora_show_volume_status(); ``` **Exemplo** ``` customer_database=> SELECT * FROM aurora_show_volume_status(); disks | nodes -------+------- 96 | 45 ``` # Como especificar o disco de RAM para o stats\$1temp\$1directory Você pode usar o parâmetro `rds.pg_stat_ramdisk_size` do Aurora PostgreSQL para especificar a memória do sistema alocada a um disco de RAM para armazenar o `stats_temp_directory` do PostgreSQL. O parâmetro de disco de RAM só está disponível no Aurora PostgreSQL 14 e versões anteriores. Mediante certas workloads, definir este parâmetro pode melhorar a performance e diminuir os requisitos de E/S. Para obter mais informações sobre `stats_temp_directory`, consulte [Run-time Statistics](https://www.postgresql.org/docs/current/static/runtime-config-statistics.html#GUC-STATS-TEMP-DIRECTORY) na documentação do PostgreSQL. A partir da versão 15 do PostgreSQL, a comunidade do PostgreSQL passou a usar memória compartilhada dinâmica. Portanto, não há necessidade de configurar `stats_temp_directory`. Para habilitar um disco de RAM para `stats_temp_directory`, configure o parâmetro `rds.pg_stat_ramdisk_size` como um valor diferente de zero no grupo de parâmetros do cluster de banco de dados usado pelo seu cluster de banco de dados. Esse parâmetro denota MB, portanto, você deve usar um valor inteiro. Expressões, fórmulas e funções não são válidas para o parâmetro `rds.pg_stat_ramdisk_size`. Reinicie o cluster de banco de dados para que a alteração entre em vigor. Para obter informações sobre como configurar parâmetros, consulte [Grupos de parâmetros para Amazon Aurora](USER_WorkingWithParamGroups.md). Para obter mais informações sobre como reiniciar o cluster de banco de dados, consulte [Reinicializar um cluster de banco de dados do Amazon Aurora ou instância de banco de dados do Amazon Aurora](USER_RebootCluster.md). Por exemplo, o seguinte comando da AWS CLI define o parâmetro do disco RAM como 256 MB. ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name db-cl-pg-ramdisk-testing \ --parameters "ParameterName=rds.pg_stat_ramdisk_size, ParameterValue=256, ApplyMethod=pending-reboot" ``` Após reiniciar o cluster de banco de dados, execute o comando a seguir para ver o status de `stats_temp_directory`: ``` postgres=> SHOW stats_temp_directory; ``` O comando deve retornar o seguinte: ``` stats_temp_directory --------------------------- /rdsdbramdisk/pg_stat_tmp (1 row) ``` # Gerenciar arquivos temporários com o PostgreSQL No PostgreSQL, uma consulta complexa pode executar algumas operações de classificação ou de hash simultaneamente, com cada uma utilizando a memória da instância para armazenar resultados até o valor especificado no parâmetro [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Quando a memória da instância não é suficiente, arquivos temporários são criados para armazenar os resultados. Eles são gravados em disco para concluir a execução da consulta. Posteriormente, esses arquivos são removidos automaticamente após a conclusão da consulta. No Aurora PostgreSQL. Esses arquivos compartilham armazenamento com outros arquivos de log.. Você pode monitorar o espaço de armazenamento local de seu cluster de banco de dados do Aurora PostgreSQL observando a métrica do Amazon CloudWatch para `FreeLocalStorage`. Para ter mais informações, consulte [ Solucionar problemas de armazenamento local](https://aws.amazon.com/premiumsupport/knowledge-center/postgresql-aurora-storage-issue/). Recomendamos o uso de clusters do Aurora com otimização de memória para workloads com várias consultas simultâneas que aumentam o uso de arquivos temporários. Esses clusters usam o armazenamento ao nível do bloco de unidade de estado sólido (SSD) local baseado em memória expressa não volátil (NVMe) para guardar os arquivos temporários. Para obter mais informações, consulte [Melhorar a performance das consultas do Aurora PostgreSQL com o Aurora Optimized Reads](AuroraPostgreSQL.optimized.reads.md). Você pode usar os parâmetros e as funções a seguir para gerenciar os arquivos temporários em sua instância. + **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)** – esse parâmetro cancela qualquer consulta que exceda o tamanho de temp\$1files em KB. Esse limite impede que qualquer consulta seja executada indefinidamente e consuma espaço em disco com arquivos temporários. Você pode estimar o valor utilizando os resultados do parâmetro `log_temp_files`. Como prática recomendada, examine o comportamento da workload e defina o limite de acordo com a estimativa. O exemplo a seguir mostra como uma consulta é cancelada quando ela excede o limite. ``` postgres=>select * from pgbench_accounts, pg_class, big_table; ``` ``` ERROR: temporary file size exceeds temp_file_limit (64kB) ``` + **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)** – esse parâmetro envia mensagens ao postgresql.log quando os arquivos temporários de uma sessão são removidos. Esse parâmetro produz logs após a conclusão bem-sucedida de uma consulta. Portanto, isso pode não ajudar na solução de problemas de consultas ativas e de longa duração. O exemplo a seguir mostra que, quando a consulta é concluída com êxito, as entradas são registradas no arquivo postgresql.log enquanto os arquivos temporários são limpos. ``` 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10; 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10; ``` + **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)** – essa função que está disponível no RDS para PostgreSQL 13 e versões posteriores oferece visibilidade sobre o uso atual de arquivos temporários. A consulta concluída não aparece nos resultados da função. No exemplo a seguir, você pode visualizar os resultados dessa função. ``` postgres=>select * from pg_ls_tmpdir(); ``` ``` name | size | modification -----------------+------------+------------------------ pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00 pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00 pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00 pgsql_tmp8351.1 | 703168512 | 2023-02-06 22:54:56+00 pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00 pgsql_tmp8328.1 | 835031040 | 2023-02-06 22:54:56+00 pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00 (7 rows) ``` ``` postgres=>select query from pg_stat_activity where pid = 8355; query ---------------------------------------------------------------------------------------- select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid (1 row) ``` O nome do arquivo inclui o ID de processamento (PID) da sessão que gerou o arquivo temporário. Uma consulta mais avançada, como no exemplo a seguir, executa uma soma dos arquivos temporários para cada PID. ``` postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid; ``` ``` pid | count | sum ------+------------------- 8355 | 2 | 2144501760 8351 | 2 | 2090770432 8327 | 1 | 1072250880 8328 | 2 | 2144501760 (4 rows) ``` + **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`** – se você ativar o parâmetro pg\$1stat\$1statements, poderá visualizar o uso médio de arquivos temporários por chamada. Você pode identificar o query\$1id da consulta e usá-lo para examinar o uso do arquivo temporário, conforme mostrado no exemplo a seguir. ``` postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%'; ``` ``` queryid ---------------------- -7170349228837045701 (1 row) ``` ``` postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701; ``` ``` queryid | substr | calls | temp_blks_read_per_call | temp_blks_written_per_call ----------------------+---------------------------+-------+-------------------------+---------------------------- -7170349228837045701 | select a.aid from pgbench | 50 | 239226 | 388678 (1 row) ``` + **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`**: no painel do Performance Insights, você pode visualizar o uso temporário de arquivos ativando as métricas **temp\$1bytes** e **temp\$1files**. Depois, você pode ver a média dessas duas métricas e como elas correspondem à workload da consulta. A exibição no Performance Insights não mostra especificamente as consultas que estão gerando os arquivos temporários. No entanto, ao combinar o Performance Insights com a consulta mostrada para `pg_ls_tmpdir`, você pode solucionar problemas, analisar e determinar as alterações em sua workload de consulta. Para ter mais informações sobre como analisar as métricas e as consultas com o Insights de Performance, consulte [Análise de métricas usando o painel do Performance Insights](USER_PerfInsights.UsingDashboard.md). Para ver um exemplo de como visualizar o uso de arquivos temporários com o Insights de Performance, consulte [Visualizar o uso de arquivos temporários com o Insights de Performance](PostgreSQL.ManagingTempFiles.Example.md). # Visualizar o uso de arquivos temporários com o Insights de Performance É possível usar o Insights de Performance para visualizar o uso de arquivos temporários ativando as métricas **temp\$1bytes** e **temp\$1files**. A visualização no Insights de Performance não mostra as consultas específicas que geram arquivos temporários, no entanto, ao combinar o Insights de Performance com a consulta mostrada para `pg_ls_tmpdir`, é possível solucionar problemas, analisar e determinar as alterações na workload de consulta. 1. No painel do Performance Insights, selecione **Gerenciar métricas**. 1. Escolha **Métricas de banco de dados** e selecione as métricas **temp\$1bytes** e **temp\$1files** como mostrado na imagem a seguir. ![\[Métricas serão exibidos no grafo.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/rpg_mantempfiles_metrics.png) 1. Na guia **Top SQL**, selecione o ícone **Preferências**. 1. Na janela **Preferências**, ative as estatísticas a seguir para serem exibidas na guia **Top SQL** e selecione **Continuar**. + Gravações temporárias/segundo + Leituras de temperatura/segundo + Gravação/chamada em bloco temporário + Leitura/chamada em bloco temporário 1. O arquivo temporário é dividido quando combinado com a consulta mostrada para `pg_ls_tmpdir`, conforme exibido no exemplo a seguir. ![\[Consulta que exibe o uso de arquivos temporários.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/rpg_mantempfiles_query.png) Os eventos `IO:BufFileRead` e `IO:BufFileWrite` ocorrem porque as principais consultas na workload geralmente criam arquivos temporários. Você pode usar o Insights de Performance para identificar as principais consultas que aguardam `IO:BufFileRead` e `IO:BufFileWrite` revisando “Média de sessões ativas (AAS)” nas seções “Carga do banco de dados” e “SQL principal”. ![\[IO:BufFileRead e IO:BufFileWrite no grafo.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/perfinsights_IOBufFile.png) Para obter mais informações sobre como usar o Insights de Performance para analisar as principais consultas e a carga por eventos de espera, consulte [Visão geral da guia Top SQL (SQL principal)](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL) Você deve identificar e ajustar as consultas que aumentam o uso de arquivos temporários e os eventos de espera correspondentes. Para ter mais informações sobre esses eventos de espera e a correção, consulte, [IO:BufFileRead e IO:BufFileWrite](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.iobuffile.html). **nota** O parâmetro [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) controla quando a operação de classificação fica sem memória e os resultados são gravados em arquivos temporários. Recomendamos que você não altere a configuração desse parâmetro acima do valor padrão, pois isso permitiria que cada sessão do banco de dados consumisse mais memória. Além disso, uma única sessão que executa junções e classificações complexas pode realizar operações paralelas nas quais cada operação consome memória. Como prática recomendada, quando você tem um relatório grande com várias junções e classificações, defina esse parâmetro no nível da sessão usando o comando `SET work_mem`. Depois, a alteração é aplicada somente à sessão atual e não altera o valor globalmente.