Utilização de Recursos / Memória
autovacuum_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada por cada processo de trabalho de vácuo automático. |
Tipo de dados | integer |
Default value | -1 |
Valores permitidos | -1-2097151 |
Tipo de parâmetro | dynamic |
Documentação | autovacuum_work_mem |
dynamic_shared_memory_type
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Seleciona a implementação de memória compartilhada dinâmica usada. |
Tipo de dados | enumeração |
Default value | posix |
Valores permitidos | posix |
Tipo de parâmetro | somente leitura |
Documentação | dynamic_shared_memory_type |
hash_mem_multiplier
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Vários dos work_mem usar para tabelas de hash. |
Tipo de dados | numérico |
Default value | 2 |
Valores permitidos | 1-1000 |
Tipo de parâmetro | dynamic |
Documentação | hash_mem_multiplier |
huge_pages
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Habilita/desabilita o uso de páginas de memória enormes. Essa configuração não é aplicável a servidores com menos de 4 vCores. |
Tipo de dados | enumeração |
Default value | try |
Valores permitidos | on,off,try |
Tipo de parâmetro | estático |
Documentação | huge_pages |
Description
Páginas enormes são um recurso que permite que a memória seja gerenciada em blocos maiores. Normalmente, você pode gerenciar blocos de até 2 MB, em oposição às páginas padrão de 4 KB.
O uso de páginas enormes pode oferecer vantagens de desempenho que efetivamente descarregam a CPU:
- Eles reduzem a sobrecarga associada a tarefas de gerenciamento de memória, como menos falhas de buffer de lookaside de tradução (TLB).
- Eles reduzem o tempo necessário para o gerenciamento de memória.
Especificamente, no PostgreSQL, você pode usar páginas enormes apenas para a área de memória compartilhada. Uma parte significativa da área de memória compartilhada é alocada para buffers compartilhados.
Outra vantagem é que páginas enormes impedem a troca da área de memória compartilhada para o disco, o que estabiliza ainda mais o desempenho.
Recomendações
- Para servidores com recursos de memória significativos, evite desativar páginas enormes. Desativar páginas enormes pode comprometer o desempenho.
- Se você começar com um servidor menor que não suporta páginas enormes, mas prevê escalar para um servidor que o faça, mantenha a
huge_pages
configuração paraTRY
uma transição perfeita e desempenho ideal.
Notas específicas do Azure
Para servidores com quatro ou mais vCores, páginas enormes são automaticamente alocadas a partir do sistema operacional subjacente. O recurso não está disponível para servidores com menos de quatro vCores. O número de páginas enormes é ajustado automaticamente se quaisquer configurações de memória compartilhada forem alteradas, incluindo alterações no shared_buffers
.
huge_page_size
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | O tamanho da página enorme que deve ser solicitado. |
Tipo de dados | integer |
Default value | 0 |
Valores permitidos | 0 |
Tipo de parâmetro | somente leitura |
Documentação | huge_page_size |
logical_decoding_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada para decodificação lógica. |
Tipo de dados | integer |
Default value | 65536 |
Valores permitidos | 65536 |
Tipo de parâmetro | somente leitura |
Documentação | logical_decoding_work_mem |
maintenance_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada para operações de manutenção, como VACUUM, Create Index. |
Tipo de dados | integer |
Default value | Depende dos recursos (vCores, RAM ou espaço em disco) alocados para o servidor. |
Valores permitidos | 1024-2097151 |
Tipo de parâmetro | dynamic |
Documentação | maintenance_work_mem |
Description
maintenance_work_mem
é um parâmetro de configuração no PostgreSQL. Ele governa a quantidade de memória alocada para operações de manutenção, como VACUUM
, CREATE INDEX
e ALTER TABLE
. Ao contrário work_mem
do , que afeta a alocação de memória para operações de consulta, maintenance_work_mem
é reservado para tarefas que mantêm e otimizam a estrutura do banco de dados.
Pontos principais
- Tampa de memória de vácuo: Se você quiser acelerar a limpeza de tuplas mortas aumentando
maintenance_work_mem
, esteja ciente de queVACUUM
tem uma limitação embutida para coletar identificadores de tupla morta. Ele pode usar apenas até 1 GB de memória para este processo. - Separação de memória para autovácuo: Você pode usar a
autovacuum_work_mem
configuração para controlar a memória que as operações de vácuo automático usam independentemente. Essa configuração atua como um subconjunto demaintenance_work_mem
. Você pode decidir quanta memória o autovacuum usa sem afetar a alocação de memória para outras tarefas de manutenção e operações de definição de dados.
Notas específicas do Azure
O valor padrão para o maintenance_work_mem
parâmetro server é calculado quando você provisiona a instância do Banco de Dados do Azure para servidor flexível PostgreSQL, com base no nome do produto selecionado para sua computação. Quaisquer alterações subsequentes da seleção de produtos para a computação que suporta o servidor flexível não terão qualquer efeito sobre o valor padrão para o maintenance_work_mem
parâmetro de servidor dessa instância.
Toda vez que você alterar o produto atribuído a uma instância, você também deve ajustar o valor para o maintenance_work_mem
parâmetro de acordo com os valores na fórmula a seguir.
A fórmula usada para calcular o valor de maintenance_work_mem
é (long)(82.5 * ln(memoryGiB) + 40) * 1024
.
Com base na fórmula anterior, a tabela a seguir lista os valores para os quais esse parâmetro de servidor seria definido dependendo da quantidade de memória provisionada:
Tamanho da memória | maintenance_work_mem |
---|---|
2 GiB | 99328 KiB |
4 GiB | 157696 KiB |
8 GiB | 216064 KiB |
16 GiB | 274432 KiB |
32 GiB | 332800 KiB |
48 GiB | 367616 KiB |
64 GiB | 392192 KiB |
80 GiB | 410624 KiB |
128 GiB | 450560 KiB |
160 GiB | 468992 KiB |
192 GiB | 484352 KiB |
256 GiB | 508928 KiB |
384 GiB | 542720 KiB |
432 GiB | 552960 KiB |
672 GiB | 590848 KiB |
max_prepared_transactions
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número máximo de transações preparadas simultaneamente. Ao executar um servidor de réplica, você deve definir esse parâmetro para o mesmo valor ou maior do que no servidor primário. |
Tipo de dados | integer |
Default value | 0 |
Valores permitidos | 0-262143 |
Tipo de parâmetro | estático |
Documentação | max_prepared_transactions |
max_stack_depth
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a profundidade máxima da pilha, em kilobytes. |
Tipo de dados | integer |
Default value | 2048 |
Valores permitidos | 2048 |
Tipo de parâmetro | somente leitura |
Documentação | max_stack_depth |
min_dynamic_shared_memory
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Quantidade de memória compartilhada dinâmica reservada na inicialização. |
Tipo de dados | integer |
Default value | 0 |
Valores permitidos | 0 |
Tipo de parâmetro | somente leitura |
Documentação | min_dynamic_shared_memory |
shared_buffers
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número de buffers de memória compartilhada usados pelo servidor. A unidade é de 8kb. Os valores permitidos estão dentro do intervalo de 10% - 75% da memória disponível. |
Tipo de dados | integer |
Default value | Depende dos recursos (vCores, RAM ou espaço em disco) alocados para o servidor. |
Valores permitidos | 16-1073741823 |
Tipo de parâmetro | estático |
Documentação | shared_buffers |
Description
O shared_buffers
parâmetro configuration determina a quantidade de memória do sistema alocada para o banco de dados PostgreSQL para buffer de dados. Ele serve como um pool de memória centralizado acessível a todos os processos de banco de dados.
Quando os dados são necessários, o processo do banco de dados primeiro verifica o buffer compartilhado. Se os dados necessários estiverem presentes, eles serão recuperados rapidamente e ignorarão uma leitura de disco mais demorada. Os buffers compartilhados servem como intermediários entre os processos do banco de dados e o disco e reduzem efetivamente o número de operações de E/S necessárias.
Notas específicas do Azure
O valor padrão para o shared_buffers
parâmetro server é calculado quando você provisiona a instância do Banco de Dados do Azure para servidor flexível PostgreSQL, com base no nome do produto selecionado para sua computação. Quaisquer alterações subsequentes da seleção de produtos para a computação que suporta o servidor flexível não têm qualquer efeito sobre o valor padrão para o shared_buffers
parâmetro de servidor dessa instância.
Sempre que alterar o produto atribuído a uma instância, você também deve ajustar o valor do shared_buffers
parâmetro de acordo com os valores nas fórmulas a seguir.
Para máquinas virtuais com até 2 GiB de memória, a fórmula usada para calcular o valor de shared_buffers
é memoryGib * 16384
.
Para máquinas virtuais com mais de 2 GiB, a fórmula usada para calcular o valor de shared_buffers
é memoryGib * 32768
.
Com base na fórmula anterior, a tabela a seguir lista os valores para os quais esse parâmetro de servidor seria definido dependendo da quantidade de memória provisionada:
Tamanho da memória | shared_buffers |
---|---|
2 GiB | 32768 |
4 GiB | 131072 |
8 GiB | 262144 |
16 GiB | 524288 |
32 GiB | 1048576 |
48 GiB | 1572864 |
64 GiB | 2097152 |
80 GiB | 2621440 |
128 GiB | 4194304 |
160 GiB | 5242880 |
192 GiB | 6291456 |
256 GiB | 8388608 |
384 GiB | 12582912 |
432 GiB | 14155776 |
672 GiB | 22020096 |
shared_memory_type
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Seleciona a implementação de memória compartilhada usada para a região principal de memória compartilhada. |
Tipo de dados | enumeração |
Default value | mmap |
Valores permitidos | mmap |
Tipo de parâmetro | somente leitura |
Documentação | shared_memory_type |
temp_buffers
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número máximo de buffers temporários usados por cada sessão de banco de dados. |
Tipo de dados | integer |
Default value | 1024 |
Valores permitidos | 100-1073741823 |
Tipo de parâmetro | dynamic |
Documentação | temp_buffers |
vacuum_buffer_usage_limit
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o tamanho do pool de buffer para VACUUM, ANALYZE e autovacuum. |
Tipo de dados | integer |
Default value | 2048 |
Valores permitidos | 0-16777216 |
Tipo de parâmetro | dynamic |
Documentação | vacuum_buffer_usage_limit |
work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a quantidade de memória a ser usada por operações de classificação internas e tabelas de hash antes de gravar em arquivos de disco temporários. |
Tipo de dados | integer |
Default value | 4096 |
Valores permitidos | 4096-2097151 |
Tipo de parâmetro | dynamic |
Documentação | work_mem |
Description
O work_mem
parâmetro no PostgreSQL controla a quantidade de memória alocada para determinadas operações internas dentro da área de memória privada de cada sessão de banco de dados. Exemplos dessas operações são classificação e hashing.
Ao contrário dos buffers compartilhados, que estão na área de memória compartilhada, work_mem
é alocado em um espaço de memória privada por sessão ou por consulta. Ao definir um tamanho adequado work_mem
, você pode melhorar significativamente a eficiência dessas operações e reduzir a necessidade de gravar dados temporários no disco.
Pontos principais
- Memória de conexão privada:
work_mem
faz parte da memória privada usada por cada sessão de banco de dados. Essa memória é distinta da área de memória compartilhada queshared_buffers
usa. - Uso específico da consulta: nem todas as sessões ou consultas usam
work_mem
o . É improvável que consultas simples comoSELECT 1
as exijamwork_mem
. No entanto, consultas complexas que envolvem operações como classificação ou hash podem consumir uma ou várias partes dowork_mem
. - Operações paralelas: Para consultas que abrangem vários back-ends paralelos, cada back-end pode potencialmente usar uma ou várias partes do
work_mem
.
Monitorização e ajustamento work_mem
É essencial monitorar continuamente o desempenho do seu sistema e ajustar work_mem
conforme necessário, principalmente se os tempos de execução da consulta relacionados às operações de classificação ou hash forem lentos. Eis algumas formas de monitorizar o desempenho utilizando as ferramentas disponíveis no portal do Azure:
- Visão de desempenho da consulta: marque a guia Principais consultas por arquivos temporários para identificar consultas que estão gerando arquivos temporários. Esta situação sugere uma potencial necessidade de aumentar.
work_mem
- Guias de solução de problemas: use a guia Arquivos temporários altos nos guias de solução de problemas para identificar consultas problemáticas.
Ajuste granular
Enquanto você gerencia o work_mem
parâmetro, geralmente é mais eficiente adotar uma abordagem de ajuste granular em vez de definir um valor global. Essa abordagem garante que você aloque memória criteriosamente com base nas necessidades específicas de processos e usuários. Ele também minimiza o risco de encontrar problemas de falta de memória. Veja como você pode fazer isso:
Nível de usuário: se um usuário específico estiver envolvido principalmente em tarefas de agregação ou relatório, que consomem muita memória, considere personalizar o
work_mem
valor para esse usuário. Use oALTER ROLE
comando para melhorar o desempenho das operações do usuário.Nível de função/procedimento: Se funções ou procedimentos específicos estão gerando arquivos temporários substanciais, aumentar o
work_mem
valor no nível de função ou procedimento específico pode ser benéfico. Use oALTER FUNCTION
comando ouALTER PROCEDURE
para alocar especificamente mais memória para essas operações.Nível do banco de dados: altere
work_mem
no nível do banco de dados se apenas bancos de dados específicos estiverem gerando um grande número de arquivos temporários.Nível global: Se uma análise do seu sistema revelar que a maioria das consultas está gerando pequenos arquivos temporários, enquanto apenas alguns estão criando arquivos grandes, pode ser prudente aumentar globalmente o
work_mem
valor. Essa ação facilita o processamento da maioria das consultas na memória, para que você possa evitar operações baseadas em disco e melhorar a eficiência. No entanto, seja sempre cauteloso e monitore a utilização da memória em seu servidor para garantir que ele possa lidar com o valor aumentadowork_mem
.
Determinação do valor mínimo de work_mem para operações de classificação
Para encontrar o valor mínimo work_mem
para uma consulta específica, especialmente uma que gera arquivos de disco temporários durante o processo de classificação, comece considerando o tamanho do arquivo temporário gerado durante a execução da consulta. Por exemplo, se uma consulta estiver gerando um arquivo temporário de 20 MB:
- Conecte-se ao seu banco de dados usando psql ou seu cliente PostgreSQL preferido.
- Defina um valor inicial
work_mem
ligeiramente superior a 20 MB para ter em conta cabeçalhos adicionais durante o processamento na memória. Use um comando como:SET work_mem TO '25MB'
. - Execute
EXPLAIN ANALYZE
a consulta problemática na mesma sessão. - Analise a saída para
"Sort Method: quicksort Memory: xkB"
. Se indicar"external merge Disk: xkB"
, aumente owork_mem
valor incrementalmente e teste novamente até"quicksort Memory"
aparecer. A aparência dos sinais de"quicksort Memory"
que a consulta agora está operando na memória. - Depois de determinar o valor por meio desse método, você pode aplicá-lo globalmente ou em níveis mais granulares (conforme descrito anteriormente) para atender às suas necessidades operacionais.
autovacuum_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada por cada processo de trabalho de vácuo automático. |
Tipo de dados | integer |
Default value | -1 |
Valores permitidos | -1-2097151 |
Tipo de parâmetro | dynamic |
Documentação | autovacuum_work_mem |
dynamic_shared_memory_type
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Seleciona a implementação de memória compartilhada dinâmica usada. |
Tipo de dados | enumeração |
Default value | posix |
Valores permitidos | posix |
Tipo de parâmetro | somente leitura |
Documentação | dynamic_shared_memory_type |
hash_mem_multiplier
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Vários dos work_mem usar para tabelas de hash. |
Tipo de dados | numérico |
Default value | 2 |
Valores permitidos | 1-1000 |
Tipo de parâmetro | dynamic |
Documentação | hash_mem_multiplier |
huge_pages
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Habilita/desabilita o uso de páginas de memória enormes. Essa configuração não é aplicável a servidores com menos de 4 vCores. |
Tipo de dados | enumeração |
Default value | try |
Valores permitidos | on,off,try |
Tipo de parâmetro | estático |
Documentação | huge_pages |
Description
Páginas enormes são um recurso que permite que a memória seja gerenciada em blocos maiores. Normalmente, você pode gerenciar blocos de até 2 MB, em oposição às páginas padrão de 4 KB.
O uso de páginas enormes pode oferecer vantagens de desempenho que efetivamente descarregam a CPU:
- Eles reduzem a sobrecarga associada a tarefas de gerenciamento de memória, como menos falhas de buffer de lookaside de tradução (TLB).
- Eles reduzem o tempo necessário para o gerenciamento de memória.
Especificamente, no PostgreSQL, você pode usar páginas enormes apenas para a área de memória compartilhada. Uma parte significativa da área de memória compartilhada é alocada para buffers compartilhados.
Outra vantagem é que páginas enormes impedem a troca da área de memória compartilhada para o disco, o que estabiliza ainda mais o desempenho.
Recomendações
- Para servidores com recursos de memória significativos, evite desativar páginas enormes. Desativar páginas enormes pode comprometer o desempenho.
- Se você começar com um servidor menor que não suporta páginas enormes, mas prevê escalar para um servidor que o faça, mantenha a
huge_pages
configuração paraTRY
uma transição perfeita e desempenho ideal.
Notas específicas do Azure
Para servidores com quatro ou mais vCores, páginas enormes são automaticamente alocadas a partir do sistema operacional subjacente. O recurso não está disponível para servidores com menos de quatro vCores. O número de páginas enormes é ajustado automaticamente se quaisquer configurações de memória compartilhada forem alteradas, incluindo alterações no shared_buffers
.
huge_page_size
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | O tamanho da página enorme que deve ser solicitado. |
Tipo de dados | integer |
Default value | 0 |
Valores permitidos | 0 |
Tipo de parâmetro | somente leitura |
Documentação | huge_page_size |
logical_decoding_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada para decodificação lógica. |
Tipo de dados | integer |
Default value | 65536 |
Valores permitidos | 64-2147483647 |
Tipo de parâmetro | dynamic |
Documentação | logical_decoding_work_mem |
maintenance_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada para operações de manutenção, como VACUUM, Create Index. |
Tipo de dados | integer |
Default value | Depende dos recursos (vCores, RAM ou espaço em disco) alocados para o servidor. |
Valores permitidos | 1024-2097151 |
Tipo de parâmetro | dynamic |
Documentação | maintenance_work_mem |
Description
maintenance_work_mem
é um parâmetro de configuração no PostgreSQL. Ele governa a quantidade de memória alocada para operações de manutenção, como VACUUM
, CREATE INDEX
e ALTER TABLE
. Ao contrário work_mem
do , que afeta a alocação de memória para operações de consulta, maintenance_work_mem
é reservado para tarefas que mantêm e otimizam a estrutura do banco de dados.
Pontos principais
- Tampa de memória de vácuo: Se você quiser acelerar a limpeza de tuplas mortas aumentando
maintenance_work_mem
, esteja ciente de queVACUUM
tem uma limitação embutida para coletar identificadores de tupla morta. Ele pode usar apenas até 1 GB de memória para este processo. - Separação de memória para autovácuo: Você pode usar a
autovacuum_work_mem
configuração para controlar a memória que as operações de vácuo automático usam independentemente. Essa configuração atua como um subconjunto demaintenance_work_mem
. Você pode decidir quanta memória o autovacuum usa sem afetar a alocação de memória para outras tarefas de manutenção e operações de definição de dados.
Notas específicas do Azure
O valor padrão para o maintenance_work_mem
parâmetro server é calculado quando você provisiona a instância do Banco de Dados do Azure para servidor flexível PostgreSQL, com base no nome do produto selecionado para sua computação. Quaisquer alterações subsequentes da seleção de produtos para a computação que suporta o servidor flexível não terão qualquer efeito sobre o valor padrão para o maintenance_work_mem
parâmetro de servidor dessa instância.
Toda vez que você alterar o produto atribuído a uma instância, você também deve ajustar o valor para o maintenance_work_mem
parâmetro de acordo com os valores na fórmula a seguir.
A fórmula usada para calcular o valor de maintenance_work_mem
é (long)(82.5 * ln(memoryGiB) + 40) * 1024
.
Com base na fórmula anterior, a tabela a seguir lista os valores para os quais esse parâmetro de servidor seria definido dependendo da quantidade de memória provisionada:
Tamanho da memória | maintenance_work_mem |
---|---|
2 GiB | 99328 KiB |
4 GiB | 157696 KiB |
8 GiB | 216064 KiB |
16 GiB | 274432 KiB |
32 GiB | 332800 KiB |
48 GiB | 367616 KiB |
64 GiB | 392192 KiB |
80 GiB | 410624 KiB |
128 GiB | 450560 KiB |
160 GiB | 468992 KiB |
192 GiB | 484352 KiB |
256 GiB | 508928 KiB |
384 GiB | 542720 KiB |
432 GiB | 552960 KiB |
672 GiB | 590848 KiB |
max_prepared_transactions
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número máximo de transações preparadas simultaneamente. Ao executar um servidor de réplica, você deve definir esse parâmetro para o mesmo valor ou maior do que no servidor primário. |
Tipo de dados | integer |
Default value | 0 |
Valores permitidos | 0-262143 |
Tipo de parâmetro | estático |
Documentação | max_prepared_transactions |
max_stack_depth
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a profundidade máxima da pilha, em kilobytes. |
Tipo de dados | integer |
Default value | 2048 |
Valores permitidos | 2048 |
Tipo de parâmetro | somente leitura |
Documentação | max_stack_depth |
min_dynamic_shared_memory
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Quantidade de memória compartilhada dinâmica reservada na inicialização. |
Tipo de dados | integer |
Default value | 0 |
Valores permitidos | 0 |
Tipo de parâmetro | somente leitura |
Documentação | min_dynamic_shared_memory |
shared_buffers
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número de buffers de memória compartilhada usados pelo servidor. A unidade é de 8kb. Os valores permitidos estão dentro do intervalo de 10% - 75% da memória disponível. |
Tipo de dados | integer |
Default value | Depende dos recursos (vCores, RAM ou espaço em disco) alocados para o servidor. |
Valores permitidos | 16-1073741823 |
Tipo de parâmetro | estático |
Documentação | shared_buffers |
Description
O shared_buffers
parâmetro configuration determina a quantidade de memória do sistema alocada para o banco de dados PostgreSQL para buffer de dados. Ele serve como um pool de memória centralizado acessível a todos os processos de banco de dados.
Quando os dados são necessários, o processo do banco de dados primeiro verifica o buffer compartilhado. Se os dados necessários estiverem presentes, eles serão recuperados rapidamente e ignorarão uma leitura de disco mais demorada. Os buffers compartilhados servem como intermediários entre os processos do banco de dados e o disco e reduzem efetivamente o número de operações de E/S necessárias.
Notas específicas do Azure
O valor padrão para o shared_buffers
parâmetro server é calculado quando você provisiona a instância do Banco de Dados do Azure para servidor flexível PostgreSQL, com base no nome do produto selecionado para sua computação. Quaisquer alterações subsequentes da seleção de produtos para a computação que suporta o servidor flexível não têm qualquer efeito sobre o valor padrão para o shared_buffers
parâmetro de servidor dessa instância.
Sempre que alterar o produto atribuído a uma instância, você também deve ajustar o valor do shared_buffers
parâmetro de acordo com os valores nas fórmulas a seguir.
Para máquinas virtuais com até 2 GiB de memória, a fórmula usada para calcular o valor de shared_buffers
é memoryGib * 16384
.
Para máquinas virtuais com mais de 2 GiB, a fórmula usada para calcular o valor de shared_buffers
é memoryGib * 32768
.
Com base na fórmula anterior, a tabela a seguir lista os valores para os quais esse parâmetro de servidor seria definido dependendo da quantidade de memória provisionada:
Tamanho da memória | shared_buffers |
---|---|
2 GiB | 32768 |
4 GiB | 131072 |
8 GiB | 262144 |
16 GiB | 524288 |
32 GiB | 1048576 |
48 GiB | 1572864 |
64 GiB | 2097152 |
80 GiB | 2621440 |
128 GiB | 4194304 |
160 GiB | 5242880 |
192 GiB | 6291456 |
256 GiB | 8388608 |
384 GiB | 12582912 |
432 GiB | 14155776 |
672 GiB | 22020096 |
shared_memory_type
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Seleciona a implementação de memória compartilhada usada para a região principal de memória compartilhada. |
Tipo de dados | enumeração |
Default value | mmap |
Valores permitidos | mmap |
Tipo de parâmetro | somente leitura |
Documentação | shared_memory_type |
temp_buffers
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número máximo de buffers temporários usados por cada sessão de banco de dados. |
Tipo de dados | integer |
Default value | 1024 |
Valores permitidos | 100-1073741823 |
Tipo de parâmetro | dynamic |
Documentação | temp_buffers |
vacuum_buffer_usage_limit
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o tamanho do pool de buffer para VACUUM, ANALYZE e autovacuum. |
Tipo de dados | integer |
Default value | 256 |
Valores permitidos | 0-16777216 |
Tipo de parâmetro | dynamic |
Documentação | vacuum_buffer_usage_limit |
work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a quantidade de memória a ser usada por operações de classificação internas e tabelas de hash antes de gravar em arquivos de disco temporários. |
Tipo de dados | integer |
Default value | 4096 |
Valores permitidos | 4096-2097151 |
Tipo de parâmetro | dynamic |
Documentação | work_mem |
Description
O work_mem
parâmetro no PostgreSQL controla a quantidade de memória alocada para determinadas operações internas dentro da área de memória privada de cada sessão de banco de dados. Exemplos dessas operações são classificação e hashing.
Ao contrário dos buffers compartilhados, que estão na área de memória compartilhada, work_mem
é alocado em um espaço de memória privada por sessão ou por consulta. Ao definir um tamanho adequado work_mem
, você pode melhorar significativamente a eficiência dessas operações e reduzir a necessidade de gravar dados temporários no disco.
Pontos principais
- Memória de conexão privada:
work_mem
faz parte da memória privada usada por cada sessão de banco de dados. Essa memória é distinta da área de memória compartilhada queshared_buffers
usa. - Uso específico da consulta: nem todas as sessões ou consultas usam
work_mem
o . É improvável que consultas simples comoSELECT 1
as exijamwork_mem
. No entanto, consultas complexas que envolvem operações como classificação ou hash podem consumir uma ou várias partes dowork_mem
. - Operações paralelas: Para consultas que abrangem vários back-ends paralelos, cada back-end pode potencialmente usar uma ou várias partes do
work_mem
.
Monitorização e ajustamento work_mem
É essencial monitorar continuamente o desempenho do seu sistema e ajustar work_mem
conforme necessário, principalmente se os tempos de execução da consulta relacionados às operações de classificação ou hash forem lentos. Eis algumas formas de monitorizar o desempenho utilizando as ferramentas disponíveis no portal do Azure:
- Visão de desempenho da consulta: marque a guia Principais consultas por arquivos temporários para identificar consultas que estão gerando arquivos temporários. Esta situação sugere uma potencial necessidade de aumentar.
work_mem
- Guias de solução de problemas: use a guia Arquivos temporários altos nos guias de solução de problemas para identificar consultas problemáticas.
Ajuste granular
Enquanto você gerencia o work_mem
parâmetro, geralmente é mais eficiente adotar uma abordagem de ajuste granular em vez de definir um valor global. Essa abordagem garante que você aloque memória criteriosamente com base nas necessidades específicas de processos e usuários. Ele também minimiza o risco de encontrar problemas de falta de memória. Veja como você pode fazer isso:
Nível de usuário: se um usuário específico estiver envolvido principalmente em tarefas de agregação ou relatório, que consomem muita memória, considere personalizar o
work_mem
valor para esse usuário. Use oALTER ROLE
comando para melhorar o desempenho das operações do usuário.Nível de função/procedimento: Se funções ou procedimentos específicos estão gerando arquivos temporários substanciais, aumentar o
work_mem
valor no nível de função ou procedimento específico pode ser benéfico. Use oALTER FUNCTION
comando ouALTER PROCEDURE
para alocar especificamente mais memória para essas operações.Nível do banco de dados: altere
work_mem
no nível do banco de dados se apenas bancos de dados específicos estiverem gerando um grande número de arquivos temporários.Nível global: Se uma análise do seu sistema revelar que a maioria das consultas está gerando pequenos arquivos temporários, enquanto apenas alguns estão criando arquivos grandes, pode ser prudente aumentar globalmente o
work_mem
valor. Essa ação facilita o processamento da maioria das consultas na memória, para que você possa evitar operações baseadas em disco e melhorar a eficiência. No entanto, seja sempre cauteloso e monitore a utilização da memória em seu servidor para garantir que ele possa lidar com o valor aumentadowork_mem
.
Determinação do valor mínimo de work_mem para operações de classificação
Para encontrar o valor mínimo work_mem
para uma consulta específica, especialmente uma que gera arquivos de disco temporários durante o processo de classificação, comece considerando o tamanho do arquivo temporário gerado durante a execução da consulta. Por exemplo, se uma consulta estiver gerando um arquivo temporário de 20 MB:
- Conecte-se ao seu banco de dados usando psql ou seu cliente PostgreSQL preferido.
- Defina um valor inicial
work_mem
ligeiramente superior a 20 MB para ter em conta cabeçalhos adicionais durante o processamento na memória. Use um comando como:SET work_mem TO '25MB'
. - Execute
EXPLAIN ANALYZE
a consulta problemática na mesma sessão. - Analise a saída para
"Sort Method: quicksort Memory: xkB"
. Se indicar"external merge Disk: xkB"
, aumente owork_mem
valor incrementalmente e teste novamente até"quicksort Memory"
aparecer. A aparência dos sinais de"quicksort Memory"
que a consulta agora está operando na memória. - Depois de determinar o valor por meio desse método, você pode aplicá-lo globalmente ou em níveis mais granulares (conforme descrito anteriormente) para atender às suas necessidades operacionais.
autovacuum_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada por cada processo de trabalho de vácuo automático. |
Tipo de dados | integer |
Default value | -1 |
Valores permitidos | -1-2097151 |
Tipo de parâmetro | dynamic |
Documentação | autovacuum_work_mem |
dynamic_shared_memory_type
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Seleciona a implementação de memória compartilhada dinâmica usada. |
Tipo de dados | enumeração |
Default value | posix |
Valores permitidos | posix |
Tipo de parâmetro | somente leitura |
Documentação | dynamic_shared_memory_type |
hash_mem_multiplier
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Vários dos work_mem usar para tabelas de hash. |
Tipo de dados | numérico |
Default value | 2 |
Valores permitidos | 1-1000 |
Tipo de parâmetro | dynamic |
Documentação | hash_mem_multiplier |
huge_pages
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Habilita/desabilita o uso de páginas de memória enormes. Essa configuração não é aplicável a servidores com menos de 4 vCores. |
Tipo de dados | enumeração |
Default value | try |
Valores permitidos | on,off,try |
Tipo de parâmetro | estático |
Documentação | huge_pages |
Description
Páginas enormes são um recurso que permite que a memória seja gerenciada em blocos maiores. Normalmente, você pode gerenciar blocos de até 2 MB, em oposição às páginas padrão de 4 KB.
O uso de páginas enormes pode oferecer vantagens de desempenho que efetivamente descarregam a CPU:
- Eles reduzem a sobrecarga associada a tarefas de gerenciamento de memória, como menos falhas de buffer de lookaside de tradução (TLB).
- Eles reduzem o tempo necessário para o gerenciamento de memória.
Especificamente, no PostgreSQL, você pode usar páginas enormes apenas para a área de memória compartilhada. Uma parte significativa da área de memória compartilhada é alocada para buffers compartilhados.
Outra vantagem é que páginas enormes impedem a troca da área de memória compartilhada para o disco, o que estabiliza ainda mais o desempenho.
Recomendações
- Para servidores com recursos de memória significativos, evite desativar páginas enormes. Desativar páginas enormes pode comprometer o desempenho.
- Se você começar com um servidor menor que não suporta páginas enormes, mas prevê escalar para um servidor que o faça, mantenha a
huge_pages
configuração paraTRY
uma transição perfeita e desempenho ideal.
Notas específicas do Azure
Para servidores com quatro ou mais vCores, páginas enormes são automaticamente alocadas a partir do sistema operacional subjacente. O recurso não está disponível para servidores com menos de quatro vCores. O número de páginas enormes é ajustado automaticamente se quaisquer configurações de memória compartilhada forem alteradas, incluindo alterações no shared_buffers
.
huge_page_size
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | O tamanho da página enorme que deve ser solicitado. |
Tipo de dados | integer |
Default value | 0 |
Valores permitidos | 0 |
Tipo de parâmetro | somente leitura |
Documentação | huge_page_size |
logical_decoding_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada para decodificação lógica. |
Tipo de dados | integer |
Default value | 65536 |
Valores permitidos | 64-2147483647 |
Tipo de parâmetro | dynamic |
Documentação | logical_decoding_work_mem |
maintenance_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada para operações de manutenção, como VACUUM, Create Index. |
Tipo de dados | integer |
Default value | Depende dos recursos (vCores, RAM ou espaço em disco) alocados para o servidor. |
Valores permitidos | 1024-2097151 |
Tipo de parâmetro | dynamic |
Documentação | maintenance_work_mem |
Description
maintenance_work_mem
é um parâmetro de configuração no PostgreSQL. Ele governa a quantidade de memória alocada para operações de manutenção, como VACUUM
, CREATE INDEX
e ALTER TABLE
. Ao contrário work_mem
do , que afeta a alocação de memória para operações de consulta, maintenance_work_mem
é reservado para tarefas que mantêm e otimizam a estrutura do banco de dados.
Pontos principais
- Tampa de memória de vácuo: Se você quiser acelerar a limpeza de tuplas mortas aumentando
maintenance_work_mem
, esteja ciente de queVACUUM
tem uma limitação embutida para coletar identificadores de tupla morta. Ele pode usar apenas até 1 GB de memória para este processo. - Separação de memória para autovácuo: Você pode usar a
autovacuum_work_mem
configuração para controlar a memória que as operações de vácuo automático usam independentemente. Essa configuração atua como um subconjunto demaintenance_work_mem
. Você pode decidir quanta memória o autovacuum usa sem afetar a alocação de memória para outras tarefas de manutenção e operações de definição de dados.
Notas específicas do Azure
O valor padrão para o maintenance_work_mem
parâmetro server é calculado quando você provisiona a instância do Banco de Dados do Azure para servidor flexível PostgreSQL, com base no nome do produto selecionado para sua computação. Quaisquer alterações subsequentes da seleção de produtos para a computação que suporta o servidor flexível não terão qualquer efeito sobre o valor padrão para o maintenance_work_mem
parâmetro de servidor dessa instância.
Toda vez que você alterar o produto atribuído a uma instância, você também deve ajustar o valor para o maintenance_work_mem
parâmetro de acordo com os valores na fórmula a seguir.
A fórmula usada para calcular o valor de maintenance_work_mem
é (long)(82.5 * ln(memoryGiB) + 40) * 1024
.
Com base na fórmula anterior, a tabela a seguir lista os valores para os quais esse parâmetro de servidor seria definido dependendo da quantidade de memória provisionada:
Tamanho da memória | maintenance_work_mem |
---|---|
2 GiB | 99328 KiB |
4 GiB | 157696 KiB |
8 GiB | 216064 KiB |
16 GiB | 274432 KiB |
32 GiB | 332800 KiB |
48 GiB | 367616 KiB |
64 GiB | 392192 KiB |
80 GiB | 410624 KiB |
128 GiB | 450560 KiB |
160 GiB | 468992 KiB |
192 GiB | 484352 KiB |
256 GiB | 508928 KiB |
384 GiB | 542720 KiB |
432 GiB | 552960 KiB |
672 GiB | 590848 KiB |
max_prepared_transactions
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número máximo de transações preparadas simultaneamente. Ao executar um servidor de réplica, você deve definir esse parâmetro para o mesmo valor ou maior do que no servidor primário. |
Tipo de dados | integer |
Default value | 0 |
Valores permitidos | 0-262143 |
Tipo de parâmetro | estático |
Documentação | max_prepared_transactions |
max_stack_depth
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a profundidade máxima da pilha, em kilobytes. |
Tipo de dados | integer |
Default value | 2048 |
Valores permitidos | 2048 |
Tipo de parâmetro | somente leitura |
Documentação | max_stack_depth |
min_dynamic_shared_memory
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Quantidade de memória compartilhada dinâmica reservada na inicialização. |
Tipo de dados | integer |
Default value | 0 |
Valores permitidos | 0 |
Tipo de parâmetro | somente leitura |
Documentação | min_dynamic_shared_memory |
shared_buffers
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número de buffers de memória compartilhada usados pelo servidor. A unidade é de 8kb. Os valores permitidos estão dentro do intervalo de 10% - 75% da memória disponível. |
Tipo de dados | integer |
Default value | Depende dos recursos (vCores, RAM ou espaço em disco) alocados para o servidor. |
Valores permitidos | 16-1073741823 |
Tipo de parâmetro | estático |
Documentação | shared_buffers |
Description
O shared_buffers
parâmetro configuration determina a quantidade de memória do sistema alocada para o banco de dados PostgreSQL para buffer de dados. Ele serve como um pool de memória centralizado acessível a todos os processos de banco de dados.
Quando os dados são necessários, o processo do banco de dados primeiro verifica o buffer compartilhado. Se os dados necessários estiverem presentes, eles serão recuperados rapidamente e ignorarão uma leitura de disco mais demorada. Os buffers compartilhados servem como intermediários entre os processos do banco de dados e o disco e reduzem efetivamente o número de operações de E/S necessárias.
Notas específicas do Azure
O valor padrão para o shared_buffers
parâmetro server é calculado quando você provisiona a instância do Banco de Dados do Azure para servidor flexível PostgreSQL, com base no nome do produto selecionado para sua computação. Quaisquer alterações subsequentes da seleção de produtos para a computação que suporta o servidor flexível não têm qualquer efeito sobre o valor padrão para o shared_buffers
parâmetro de servidor dessa instância.
Sempre que alterar o produto atribuído a uma instância, você também deve ajustar o valor do shared_buffers
parâmetro de acordo com os valores nas fórmulas a seguir.
Para máquinas virtuais com até 2 GiB de memória, a fórmula usada para calcular o valor de shared_buffers
é memoryGib * 16384
.
Para máquinas virtuais com mais de 2 GiB, a fórmula usada para calcular o valor de shared_buffers
é memoryGib * 32768
.
Com base na fórmula anterior, a tabela a seguir lista os valores para os quais esse parâmetro de servidor seria definido dependendo da quantidade de memória provisionada:
Tamanho da memória | shared_buffers |
---|---|
2 GiB | 32768 |
4 GiB | 131072 |
8 GiB | 262144 |
16 GiB | 524288 |
32 GiB | 1048576 |
48 GiB | 1572864 |
64 GiB | 2097152 |
80 GiB | 2621440 |
128 GiB | 4194304 |
160 GiB | 5242880 |
192 GiB | 6291456 |
256 GiB | 8388608 |
384 GiB | 12582912 |
432 GiB | 14155776 |
672 GiB | 22020096 |
shared_memory_type
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Seleciona a implementação de memória compartilhada usada para a região principal de memória compartilhada. |
Tipo de dados | enumeração |
Default value | mmap |
Valores permitidos | mmap |
Tipo de parâmetro | somente leitura |
Documentação | shared_memory_type |
temp_buffers
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número máximo de buffers temporários usados por cada sessão de banco de dados. |
Tipo de dados | integer |
Default value | 1024 |
Valores permitidos | 100-1073741823 |
Tipo de parâmetro | dynamic |
Documentação | temp_buffers |
work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a quantidade de memória a ser usada por operações de classificação internas e tabelas de hash antes de gravar em arquivos de disco temporários. |
Tipo de dados | integer |
Default value | 4096 |
Valores permitidos | 4096-2097151 |
Tipo de parâmetro | dynamic |
Documentação | work_mem |
Description
O work_mem
parâmetro no PostgreSQL controla a quantidade de memória alocada para determinadas operações internas dentro da área de memória privada de cada sessão de banco de dados. Exemplos dessas operações são classificação e hashing.
Ao contrário dos buffers compartilhados, que estão na área de memória compartilhada, work_mem
é alocado em um espaço de memória privada por sessão ou por consulta. Ao definir um tamanho adequado work_mem
, você pode melhorar significativamente a eficiência dessas operações e reduzir a necessidade de gravar dados temporários no disco.
Pontos principais
- Memória de conexão privada:
work_mem
faz parte da memória privada usada por cada sessão de banco de dados. Essa memória é distinta da área de memória compartilhada queshared_buffers
usa. - Uso específico da consulta: nem todas as sessões ou consultas usam
work_mem
o . É improvável que consultas simples comoSELECT 1
as exijamwork_mem
. No entanto, consultas complexas que envolvem operações como classificação ou hash podem consumir uma ou várias partes dowork_mem
. - Operações paralelas: Para consultas que abrangem vários back-ends paralelos, cada back-end pode potencialmente usar uma ou várias partes do
work_mem
.
Monitorização e ajustamento work_mem
É essencial monitorar continuamente o desempenho do seu sistema e ajustar work_mem
conforme necessário, principalmente se os tempos de execução da consulta relacionados às operações de classificação ou hash forem lentos. Eis algumas formas de monitorizar o desempenho utilizando as ferramentas disponíveis no portal do Azure:
- Visão de desempenho da consulta: marque a guia Principais consultas por arquivos temporários para identificar consultas que estão gerando arquivos temporários. Esta situação sugere uma potencial necessidade de aumentar.
work_mem
- Guias de solução de problemas: use a guia Arquivos temporários altos nos guias de solução de problemas para identificar consultas problemáticas.
Ajuste granular
Enquanto você gerencia o work_mem
parâmetro, geralmente é mais eficiente adotar uma abordagem de ajuste granular em vez de definir um valor global. Essa abordagem garante que você aloque memória criteriosamente com base nas necessidades específicas de processos e usuários. Ele também minimiza o risco de encontrar problemas de falta de memória. Veja como você pode fazer isso:
Nível de usuário: se um usuário específico estiver envolvido principalmente em tarefas de agregação ou relatório, que consomem muita memória, considere personalizar o
work_mem
valor para esse usuário. Use oALTER ROLE
comando para melhorar o desempenho das operações do usuário.Nível de função/procedimento: Se funções ou procedimentos específicos estão gerando arquivos temporários substanciais, aumentar o
work_mem
valor no nível de função ou procedimento específico pode ser benéfico. Use oALTER FUNCTION
comando ouALTER PROCEDURE
para alocar especificamente mais memória para essas operações.Nível do banco de dados: altere
work_mem
no nível do banco de dados se apenas bancos de dados específicos estiverem gerando um grande número de arquivos temporários.Nível global: Se uma análise do seu sistema revelar que a maioria das consultas está gerando pequenos arquivos temporários, enquanto apenas alguns estão criando arquivos grandes, pode ser prudente aumentar globalmente o
work_mem
valor. Essa ação facilita o processamento da maioria das consultas na memória, para que você possa evitar operações baseadas em disco e melhorar a eficiência. No entanto, seja sempre cauteloso e monitore a utilização da memória em seu servidor para garantir que ele possa lidar com o valor aumentadowork_mem
.
Determinação do valor mínimo de work_mem para operações de classificação
Para encontrar o valor mínimo work_mem
para uma consulta específica, especialmente uma que gera arquivos de disco temporários durante o processo de classificação, comece considerando o tamanho do arquivo temporário gerado durante a execução da consulta. Por exemplo, se uma consulta estiver gerando um arquivo temporário de 20 MB:
- Conecte-se ao seu banco de dados usando psql ou seu cliente PostgreSQL preferido.
- Defina um valor inicial
work_mem
ligeiramente superior a 20 MB para ter em conta cabeçalhos adicionais durante o processamento na memória. Use um comando como:SET work_mem TO '25MB'
. - Execute
EXPLAIN ANALYZE
a consulta problemática na mesma sessão. - Analise a saída para
"Sort Method: quicksort Memory: xkB"
. Se indicar"external merge Disk: xkB"
, aumente owork_mem
valor incrementalmente e teste novamente até"quicksort Memory"
aparecer. A aparência dos sinais de"quicksort Memory"
que a consulta agora está operando na memória. - Depois de determinar o valor por meio desse método, você pode aplicá-lo globalmente ou em níveis mais granulares (conforme descrito anteriormente) para atender às suas necessidades operacionais.
autovacuum_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada por cada processo de trabalho de vácuo automático. |
Tipo de dados | integer |
Default value | -1 |
Valores permitidos | -1-2097151 |
Tipo de parâmetro | dynamic |
Documentação | autovacuum_work_mem |
dynamic_shared_memory_type
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Seleciona a implementação de memória compartilhada dinâmica usada. |
Tipo de dados | enumeração |
Default value | posix |
Valores permitidos | posix |
Tipo de parâmetro | somente leitura |
Documentação | dynamic_shared_memory_type |
hash_mem_multiplier
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Vários dos work_mem usar para tabelas de hash. |
Tipo de dados | numérico |
Default value | 1 |
Valores permitidos | 1-1000 |
Tipo de parâmetro | dynamic |
Documentação | hash_mem_multiplier |
huge_pages
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Habilita/desabilita o uso de páginas de memória enormes. Essa configuração não é aplicável a servidores com menos de 4 vCores. |
Tipo de dados | enumeração |
Default value | try |
Valores permitidos | on,off,try |
Tipo de parâmetro | estático |
Documentação | huge_pages |
Description
Páginas enormes são um recurso que permite que a memória seja gerenciada em blocos maiores. Normalmente, você pode gerenciar blocos de até 2 MB, em oposição às páginas padrão de 4 KB.
O uso de páginas enormes pode oferecer vantagens de desempenho que efetivamente descarregam a CPU:
- Eles reduzem a sobrecarga associada a tarefas de gerenciamento de memória, como menos falhas de buffer de lookaside de tradução (TLB).
- Eles reduzem o tempo necessário para o gerenciamento de memória.
Especificamente, no PostgreSQL, você pode usar páginas enormes apenas para a área de memória compartilhada. Uma parte significativa da área de memória compartilhada é alocada para buffers compartilhados.
Outra vantagem é que páginas enormes impedem a troca da área de memória compartilhada para o disco, o que estabiliza ainda mais o desempenho.
Recomendações
- Para servidores com recursos de memória significativos, evite desativar páginas enormes. Desativar páginas enormes pode comprometer o desempenho.
- Se você começar com um servidor menor que não suporta páginas enormes, mas prevê escalar para um servidor que o faça, mantenha a
huge_pages
configuração paraTRY
uma transição perfeita e desempenho ideal.
Notas específicas do Azure
Para servidores com quatro ou mais vCores, páginas enormes são automaticamente alocadas a partir do sistema operacional subjacente. O recurso não está disponível para servidores com menos de quatro vCores. O número de páginas enormes é ajustado automaticamente se quaisquer configurações de memória compartilhada forem alteradas, incluindo alterações no shared_buffers
.
huge_page_size
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | O tamanho da página enorme que deve ser solicitado. |
Tipo de dados | integer |
Default value | 0 |
Valores permitidos | 0 |
Tipo de parâmetro | somente leitura |
Documentação | huge_page_size |
logical_decoding_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada para decodificação lógica. |
Tipo de dados | integer |
Default value | 65536 |
Valores permitidos | 64-2147483647 |
Tipo de parâmetro | dynamic |
Documentação | logical_decoding_work_mem |
maintenance_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada para operações de manutenção, como VACUUM, Create Index. |
Tipo de dados | integer |
Default value | Depende dos recursos (vCores, RAM ou espaço em disco) alocados para o servidor. |
Valores permitidos | 1024-2097151 |
Tipo de parâmetro | dynamic |
Documentação | maintenance_work_mem |
Description
maintenance_work_mem
é um parâmetro de configuração no PostgreSQL. Ele governa a quantidade de memória alocada para operações de manutenção, como VACUUM
, CREATE INDEX
e ALTER TABLE
. Ao contrário work_mem
do , que afeta a alocação de memória para operações de consulta, maintenance_work_mem
é reservado para tarefas que mantêm e otimizam a estrutura do banco de dados.
Pontos principais
- Tampa de memória de vácuo: Se você quiser acelerar a limpeza de tuplas mortas aumentando
maintenance_work_mem
, esteja ciente de queVACUUM
tem uma limitação embutida para coletar identificadores de tupla morta. Ele pode usar apenas até 1 GB de memória para este processo. - Separação de memória para autovácuo: Você pode usar a
autovacuum_work_mem
configuração para controlar a memória que as operações de vácuo automático usam independentemente. Essa configuração atua como um subconjunto demaintenance_work_mem
. Você pode decidir quanta memória o autovacuum usa sem afetar a alocação de memória para outras tarefas de manutenção e operações de definição de dados.
Notas específicas do Azure
O valor padrão para o maintenance_work_mem
parâmetro server é calculado quando você provisiona a instância do Banco de Dados do Azure para servidor flexível PostgreSQL, com base no nome do produto selecionado para sua computação. Quaisquer alterações subsequentes da seleção de produtos para a computação que suporta o servidor flexível não terão qualquer efeito sobre o valor padrão para o maintenance_work_mem
parâmetro de servidor dessa instância.
Toda vez que você alterar o produto atribuído a uma instância, você também deve ajustar o valor para o maintenance_work_mem
parâmetro de acordo com os valores na fórmula a seguir.
A fórmula usada para calcular o valor de maintenance_work_mem
é (long)(82.5 * ln(memoryGiB) + 40) * 1024
.
Com base na fórmula anterior, a tabela a seguir lista os valores para os quais esse parâmetro de servidor seria definido dependendo da quantidade de memória provisionada:
Tamanho da memória | maintenance_work_mem |
---|---|
2 GiB | 99328 KiB |
4 GiB | 157696 KiB |
8 GiB | 216064 KiB |
16 GiB | 274432 KiB |
32 GiB | 332800 KiB |
48 GiB | 367616 KiB |
64 GiB | 392192 KiB |
80 GiB | 410624 KiB |
128 GiB | 450560 KiB |
160 GiB | 468992 KiB |
192 GiB | 484352 KiB |
256 GiB | 508928 KiB |
384 GiB | 542720 KiB |
432 GiB | 552960 KiB |
672 GiB | 590848 KiB |
max_prepared_transactions
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número máximo de transações preparadas simultaneamente. Ao executar um servidor de réplica, você deve definir esse parâmetro para o mesmo valor ou maior do que no servidor primário. |
Tipo de dados | integer |
Default value | 0 |
Valores permitidos | 0-262143 |
Tipo de parâmetro | estático |
Documentação | max_prepared_transactions |
max_stack_depth
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a profundidade máxima da pilha, em kilobytes. |
Tipo de dados | integer |
Default value | 2048 |
Valores permitidos | 2048 |
Tipo de parâmetro | somente leitura |
Documentação | max_stack_depth |
min_dynamic_shared_memory
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Quantidade de memória compartilhada dinâmica reservada na inicialização. |
Tipo de dados | integer |
Default value | 0 |
Valores permitidos | 0 |
Tipo de parâmetro | somente leitura |
Documentação | min_dynamic_shared_memory |
shared_buffers
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número de buffers de memória compartilhada usados pelo servidor. A unidade é de 8kb. Os valores permitidos estão dentro do intervalo de 10% - 75% da memória disponível. |
Tipo de dados | integer |
Default value | Depende dos recursos (vCores, RAM ou espaço em disco) alocados para o servidor. |
Valores permitidos | 16-1073741823 |
Tipo de parâmetro | estático |
Documentação | shared_buffers |
Description
O shared_buffers
parâmetro configuration determina a quantidade de memória do sistema alocada para o banco de dados PostgreSQL para buffer de dados. Ele serve como um pool de memória centralizado acessível a todos os processos de banco de dados.
Quando os dados são necessários, o processo do banco de dados primeiro verifica o buffer compartilhado. Se os dados necessários estiverem presentes, eles serão recuperados rapidamente e ignorarão uma leitura de disco mais demorada. Os buffers compartilhados servem como intermediários entre os processos do banco de dados e o disco e reduzem efetivamente o número de operações de E/S necessárias.
Notas específicas do Azure
O valor padrão para o shared_buffers
parâmetro server é calculado quando você provisiona a instância do Banco de Dados do Azure para servidor flexível PostgreSQL, com base no nome do produto selecionado para sua computação. Quaisquer alterações subsequentes da seleção de produtos para a computação que suporta o servidor flexível não têm qualquer efeito sobre o valor padrão para o shared_buffers
parâmetro de servidor dessa instância.
Sempre que alterar o produto atribuído a uma instância, você também deve ajustar o valor do shared_buffers
parâmetro de acordo com os valores nas fórmulas a seguir.
Para máquinas virtuais com até 2 GiB de memória, a fórmula usada para calcular o valor de shared_buffers
é memoryGib * 16384
.
Para máquinas virtuais com mais de 2 GiB, a fórmula usada para calcular o valor de shared_buffers
é memoryGib * 32768
.
Com base na fórmula anterior, a tabela a seguir lista os valores para os quais esse parâmetro de servidor seria definido dependendo da quantidade de memória provisionada:
Tamanho da memória | shared_buffers |
---|---|
2 GiB | 32768 |
4 GiB | 131072 |
8 GiB | 262144 |
16 GiB | 524288 |
32 GiB | 1048576 |
48 GiB | 1572864 |
64 GiB | 2097152 |
80 GiB | 2621440 |
128 GiB | 4194304 |
160 GiB | 5242880 |
192 GiB | 6291456 |
256 GiB | 8388608 |
384 GiB | 12582912 |
432 GiB | 14155776 |
672 GiB | 22020096 |
shared_memory_type
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Seleciona a implementação de memória compartilhada usada para a região principal de memória compartilhada. |
Tipo de dados | enumeração |
Default value | mmap |
Valores permitidos | mmap |
Tipo de parâmetro | somente leitura |
Documentação | shared_memory_type |
temp_buffers
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número máximo de buffers temporários usados por cada sessão de banco de dados. |
Tipo de dados | integer |
Default value | 1024 |
Valores permitidos | 100-1073741823 |
Tipo de parâmetro | dynamic |
Documentação | temp_buffers |
work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a quantidade de memória a ser usada por operações de classificação internas e tabelas de hash antes de gravar em arquivos de disco temporários. |
Tipo de dados | integer |
Default value | 4096 |
Valores permitidos | 4096-2097151 |
Tipo de parâmetro | dynamic |
Documentação | work_mem |
Description
O work_mem
parâmetro no PostgreSQL controla a quantidade de memória alocada para determinadas operações internas dentro da área de memória privada de cada sessão de banco de dados. Exemplos dessas operações são classificação e hashing.
Ao contrário dos buffers compartilhados, que estão na área de memória compartilhada, work_mem
é alocado em um espaço de memória privada por sessão ou por consulta. Ao definir um tamanho adequado work_mem
, você pode melhorar significativamente a eficiência dessas operações e reduzir a necessidade de gravar dados temporários no disco.
Pontos principais
- Memória de conexão privada:
work_mem
faz parte da memória privada usada por cada sessão de banco de dados. Essa memória é distinta da área de memória compartilhada queshared_buffers
usa. - Uso específico da consulta: nem todas as sessões ou consultas usam
work_mem
o . É improvável que consultas simples comoSELECT 1
as exijamwork_mem
. No entanto, consultas complexas que envolvem operações como classificação ou hash podem consumir uma ou várias partes dowork_mem
. - Operações paralelas: Para consultas que abrangem vários back-ends paralelos, cada back-end pode potencialmente usar uma ou várias partes do
work_mem
.
Monitorização e ajustamento work_mem
É essencial monitorar continuamente o desempenho do seu sistema e ajustar work_mem
conforme necessário, principalmente se os tempos de execução da consulta relacionados às operações de classificação ou hash forem lentos. Eis algumas formas de monitorizar o desempenho utilizando as ferramentas disponíveis no portal do Azure:
- Visão de desempenho da consulta: marque a guia Principais consultas por arquivos temporários para identificar consultas que estão gerando arquivos temporários. Esta situação sugere uma potencial necessidade de aumentar.
work_mem
- Guias de solução de problemas: use a guia Arquivos temporários altos nos guias de solução de problemas para identificar consultas problemáticas.
Ajuste granular
Enquanto você gerencia o work_mem
parâmetro, geralmente é mais eficiente adotar uma abordagem de ajuste granular em vez de definir um valor global. Essa abordagem garante que você aloque memória criteriosamente com base nas necessidades específicas de processos e usuários. Ele também minimiza o risco de encontrar problemas de falta de memória. Veja como você pode fazer isso:
Nível de usuário: se um usuário específico estiver envolvido principalmente em tarefas de agregação ou relatório, que consomem muita memória, considere personalizar o
work_mem
valor para esse usuário. Use oALTER ROLE
comando para melhorar o desempenho das operações do usuário.Nível de função/procedimento: Se funções ou procedimentos específicos estão gerando arquivos temporários substanciais, aumentar o
work_mem
valor no nível de função ou procedimento específico pode ser benéfico. Use oALTER FUNCTION
comando ouALTER PROCEDURE
para alocar especificamente mais memória para essas operações.Nível do banco de dados: altere
work_mem
no nível do banco de dados se apenas bancos de dados específicos estiverem gerando um grande número de arquivos temporários.Nível global: Se uma análise do seu sistema revelar que a maioria das consultas está gerando pequenos arquivos temporários, enquanto apenas alguns estão criando arquivos grandes, pode ser prudente aumentar globalmente o
work_mem
valor. Essa ação facilita o processamento da maioria das consultas na memória, para que você possa evitar operações baseadas em disco e melhorar a eficiência. No entanto, seja sempre cauteloso e monitore a utilização da memória em seu servidor para garantir que ele possa lidar com o valor aumentadowork_mem
.
Determinação do valor mínimo de work_mem para operações de classificação
Para encontrar o valor mínimo work_mem
para uma consulta específica, especialmente uma que gera arquivos de disco temporários durante o processo de classificação, comece considerando o tamanho do arquivo temporário gerado durante a execução da consulta. Por exemplo, se uma consulta estiver gerando um arquivo temporário de 20 MB:
- Conecte-se ao seu banco de dados usando psql ou seu cliente PostgreSQL preferido.
- Defina um valor inicial
work_mem
ligeiramente superior a 20 MB para ter em conta cabeçalhos adicionais durante o processamento na memória. Use um comando como:SET work_mem TO '25MB'
. - Execute
EXPLAIN ANALYZE
a consulta problemática na mesma sessão. - Analise a saída para
"Sort Method: quicksort Memory: xkB"
. Se indicar"external merge Disk: xkB"
, aumente owork_mem
valor incrementalmente e teste novamente até"quicksort Memory"
aparecer. A aparência dos sinais de"quicksort Memory"
que a consulta agora está operando na memória. - Depois de determinar o valor por meio desse método, você pode aplicá-lo globalmente ou em níveis mais granulares (conforme descrito anteriormente) para atender às suas necessidades operacionais.
autovacuum_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada por cada processo de trabalho de vácuo automático. |
Tipo de dados | integer |
Default value | -1 |
Valores permitidos | -1-2097151 |
Tipo de parâmetro | dynamic |
Documentação | autovacuum_work_mem |
dynamic_shared_memory_type
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Seleciona a implementação de memória compartilhada dinâmica usada. |
Tipo de dados | enumeração |
Default value | posix |
Valores permitidos | posix |
Tipo de parâmetro | somente leitura |
Documentação | dynamic_shared_memory_type |
hash_mem_multiplier
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Vários dos work_mem usar para tabelas de hash. |
Tipo de dados | numérico |
Default value | 1 |
Valores permitidos | 1-1000 |
Tipo de parâmetro | dynamic |
Documentação | hash_mem_multiplier |
huge_pages
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Habilita/desabilita o uso de páginas de memória enormes. Essa configuração não é aplicável a servidores com menos de 4 vCores. |
Tipo de dados | enumeração |
Default value | try |
Valores permitidos | on,off,try |
Tipo de parâmetro | estático |
Documentação | huge_pages |
Description
Páginas enormes são um recurso que permite que a memória seja gerenciada em blocos maiores. Normalmente, você pode gerenciar blocos de até 2 MB, em oposição às páginas padrão de 4 KB.
O uso de páginas enormes pode oferecer vantagens de desempenho que efetivamente descarregam a CPU:
- Eles reduzem a sobrecarga associada a tarefas de gerenciamento de memória, como menos falhas de buffer de lookaside de tradução (TLB).
- Eles reduzem o tempo necessário para o gerenciamento de memória.
Especificamente, no PostgreSQL, você pode usar páginas enormes apenas para a área de memória compartilhada. Uma parte significativa da área de memória compartilhada é alocada para buffers compartilhados.
Outra vantagem é que páginas enormes impedem a troca da área de memória compartilhada para o disco, o que estabiliza ainda mais o desempenho.
Recomendações
- Para servidores com recursos de memória significativos, evite desativar páginas enormes. Desativar páginas enormes pode comprometer o desempenho.
- Se você começar com um servidor menor que não suporta páginas enormes, mas prevê escalar para um servidor que o faça, mantenha a
huge_pages
configuração paraTRY
uma transição perfeita e desempenho ideal.
Notas específicas do Azure
Para servidores com quatro ou mais vCores, páginas enormes são automaticamente alocadas a partir do sistema operacional subjacente. O recurso não está disponível para servidores com menos de quatro vCores. O número de páginas enormes é ajustado automaticamente se quaisquer configurações de memória compartilhada forem alteradas, incluindo alterações no shared_buffers
.
logical_decoding_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada para decodificação lógica. |
Tipo de dados | integer |
Default value | 65536 |
Valores permitidos | 64-2147483647 |
Tipo de parâmetro | dynamic |
Documentação | logical_decoding_work_mem |
maintenance_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada para operações de manutenção, como VACUUM, Create Index. |
Tipo de dados | integer |
Default value | Depende dos recursos (vCores, RAM ou espaço em disco) alocados para o servidor. |
Valores permitidos | 1024-2097151 |
Tipo de parâmetro | dynamic |
Documentação | maintenance_work_mem |
Description
maintenance_work_mem
é um parâmetro de configuração no PostgreSQL. Ele governa a quantidade de memória alocada para operações de manutenção, como VACUUM
, CREATE INDEX
e ALTER TABLE
. Ao contrário work_mem
do , que afeta a alocação de memória para operações de consulta, maintenance_work_mem
é reservado para tarefas que mantêm e otimizam a estrutura do banco de dados.
Pontos principais
- Tampa de memória de vácuo: Se você quiser acelerar a limpeza de tuplas mortas aumentando
maintenance_work_mem
, esteja ciente de queVACUUM
tem uma limitação embutida para coletar identificadores de tupla morta. Ele pode usar apenas até 1 GB de memória para este processo. - Separação de memória para autovácuo: Você pode usar a
autovacuum_work_mem
configuração para controlar a memória que as operações de vácuo automático usam independentemente. Essa configuração atua como um subconjunto demaintenance_work_mem
. Você pode decidir quanta memória o autovacuum usa sem afetar a alocação de memória para outras tarefas de manutenção e operações de definição de dados.
Notas específicas do Azure
O valor padrão para o maintenance_work_mem
parâmetro server é calculado quando você provisiona a instância do Banco de Dados do Azure para servidor flexível PostgreSQL, com base no nome do produto selecionado para sua computação. Quaisquer alterações subsequentes da seleção de produtos para a computação que suporta o servidor flexível não terão qualquer efeito sobre o valor padrão para o maintenance_work_mem
parâmetro de servidor dessa instância.
Toda vez que você alterar o produto atribuído a uma instância, você também deve ajustar o valor para o maintenance_work_mem
parâmetro de acordo com os valores na fórmula a seguir.
A fórmula usada para calcular o valor de maintenance_work_mem
é (long)(82.5 * ln(memoryGiB) + 40) * 1024
.
Com base na fórmula anterior, a tabela a seguir lista os valores para os quais esse parâmetro de servidor seria definido dependendo da quantidade de memória provisionada:
Tamanho da memória | maintenance_work_mem |
---|---|
2 GiB | 99328 KiB |
4 GiB | 157696 KiB |
8 GiB | 216064 KiB |
16 GiB | 274432 KiB |
32 GiB | 332800 KiB |
48 GiB | 367616 KiB |
64 GiB | 392192 KiB |
80 GiB | 410624 KiB |
128 GiB | 450560 KiB |
160 GiB | 468992 KiB |
192 GiB | 484352 KiB |
256 GiB | 508928 KiB |
384 GiB | 542720 KiB |
432 GiB | 552960 KiB |
672 GiB | 590848 KiB |
max_prepared_transactions
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número máximo de transações preparadas simultaneamente. Ao executar um servidor de réplica, você deve definir esse parâmetro para o mesmo valor ou maior do que no servidor primário. |
Tipo de dados | integer |
Default value | 0 |
Valores permitidos | 0-262143 |
Tipo de parâmetro | estático |
Documentação | max_prepared_transactions |
max_stack_depth
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a profundidade máxima da pilha, em kilobytes. |
Tipo de dados | integer |
Default value | 2048 |
Valores permitidos | 2048 |
Tipo de parâmetro | somente leitura |
Documentação | max_stack_depth |
shared_buffers
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número de buffers de memória compartilhada usados pelo servidor. A unidade é de 8kb. Os valores permitidos estão dentro do intervalo de 10% - 75% da memória disponível. |
Tipo de dados | integer |
Default value | Depende dos recursos (vCores, RAM ou espaço em disco) alocados para o servidor. |
Valores permitidos | 16-1073741823 |
Tipo de parâmetro | estático |
Documentação | shared_buffers |
Description
O shared_buffers
parâmetro configuration determina a quantidade de memória do sistema alocada para o banco de dados PostgreSQL para buffer de dados. Ele serve como um pool de memória centralizado acessível a todos os processos de banco de dados.
Quando os dados são necessários, o processo do banco de dados primeiro verifica o buffer compartilhado. Se os dados necessários estiverem presentes, eles serão recuperados rapidamente e ignorarão uma leitura de disco mais demorada. Os buffers compartilhados servem como intermediários entre os processos do banco de dados e o disco e reduzem efetivamente o número de operações de E/S necessárias.
Notas específicas do Azure
O valor padrão para o shared_buffers
parâmetro server é calculado quando você provisiona a instância do Banco de Dados do Azure para servidor flexível PostgreSQL, com base no nome do produto selecionado para sua computação. Quaisquer alterações subsequentes da seleção de produtos para a computação que suporta o servidor flexível não têm qualquer efeito sobre o valor padrão para o shared_buffers
parâmetro de servidor dessa instância.
Sempre que alterar o produto atribuído a uma instância, você também deve ajustar o valor do shared_buffers
parâmetro de acordo com os valores nas fórmulas a seguir.
Para máquinas virtuais com até 2 GiB de memória, a fórmula usada para calcular o valor de shared_buffers
é memoryGib * 16384
.
Para máquinas virtuais com mais de 2 GiB, a fórmula usada para calcular o valor de shared_buffers
é memoryGib * 32768
.
Com base na fórmula anterior, a tabela a seguir lista os valores para os quais esse parâmetro de servidor seria definido dependendo da quantidade de memória provisionada:
Tamanho da memória | shared_buffers |
---|---|
2 GiB | 32768 |
4 GiB | 131072 |
8 GiB | 262144 |
16 GiB | 524288 |
32 GiB | 1048576 |
48 GiB | 1572864 |
64 GiB | 2097152 |
80 GiB | 2621440 |
128 GiB | 4194304 |
160 GiB | 5242880 |
192 GiB | 6291456 |
256 GiB | 8388608 |
384 GiB | 12582912 |
432 GiB | 14155776 |
672 GiB | 22020096 |
shared_memory_type
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Seleciona a implementação de memória compartilhada usada para a região principal de memória compartilhada. |
Tipo de dados | enumeração |
Default value | mmap |
Valores permitidos | mmap |
Tipo de parâmetro | somente leitura |
Documentação | shared_memory_type |
temp_buffers
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número máximo de buffers temporários usados por cada sessão de banco de dados. |
Tipo de dados | integer |
Default value | 1024 |
Valores permitidos | 100-1073741823 |
Tipo de parâmetro | dynamic |
Documentação | temp_buffers |
work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a quantidade de memória a ser usada por operações de classificação internas e tabelas de hash antes de gravar em arquivos de disco temporários. |
Tipo de dados | integer |
Default value | 4096 |
Valores permitidos | 4096-2097151 |
Tipo de parâmetro | dynamic |
Documentação | work_mem |
Description
O work_mem
parâmetro no PostgreSQL controla a quantidade de memória alocada para determinadas operações internas dentro da área de memória privada de cada sessão de banco de dados. Exemplos dessas operações são classificação e hashing.
Ao contrário dos buffers compartilhados, que estão na área de memória compartilhada, work_mem
é alocado em um espaço de memória privada por sessão ou por consulta. Ao definir um tamanho adequado work_mem
, você pode melhorar significativamente a eficiência dessas operações e reduzir a necessidade de gravar dados temporários no disco.
Pontos principais
- Memória de conexão privada:
work_mem
faz parte da memória privada usada por cada sessão de banco de dados. Essa memória é distinta da área de memória compartilhada queshared_buffers
usa. - Uso específico da consulta: nem todas as sessões ou consultas usam
work_mem
o . É improvável que consultas simples comoSELECT 1
as exijamwork_mem
. No entanto, consultas complexas que envolvem operações como classificação ou hash podem consumir uma ou várias partes dowork_mem
. - Operações paralelas: Para consultas que abrangem vários back-ends paralelos, cada back-end pode potencialmente usar uma ou várias partes do
work_mem
.
Monitorização e ajustamento work_mem
É essencial monitorar continuamente o desempenho do seu sistema e ajustar work_mem
conforme necessário, principalmente se os tempos de execução da consulta relacionados às operações de classificação ou hash forem lentos. Eis algumas formas de monitorizar o desempenho utilizando as ferramentas disponíveis no portal do Azure:
- Visão de desempenho da consulta: marque a guia Principais consultas por arquivos temporários para identificar consultas que estão gerando arquivos temporários. Esta situação sugere uma potencial necessidade de aumentar.
work_mem
- Guias de solução de problemas: use a guia Arquivos temporários altos nos guias de solução de problemas para identificar consultas problemáticas.
Ajuste granular
Enquanto você gerencia o work_mem
parâmetro, geralmente é mais eficiente adotar uma abordagem de ajuste granular em vez de definir um valor global. Essa abordagem garante que você aloque memória criteriosamente com base nas necessidades específicas de processos e usuários. Ele também minimiza o risco de encontrar problemas de falta de memória. Veja como você pode fazer isso:
Nível de usuário: se um usuário específico estiver envolvido principalmente em tarefas de agregação ou relatório, que consomem muita memória, considere personalizar o
work_mem
valor para esse usuário. Use oALTER ROLE
comando para melhorar o desempenho das operações do usuário.Nível de função/procedimento: Se funções ou procedimentos específicos estão gerando arquivos temporários substanciais, aumentar o
work_mem
valor no nível de função ou procedimento específico pode ser benéfico. Use oALTER FUNCTION
comando ouALTER PROCEDURE
para alocar especificamente mais memória para essas operações.Nível do banco de dados: altere
work_mem
no nível do banco de dados se apenas bancos de dados específicos estiverem gerando um grande número de arquivos temporários.Nível global: Se uma análise do seu sistema revelar que a maioria das consultas está gerando pequenos arquivos temporários, enquanto apenas alguns estão criando arquivos grandes, pode ser prudente aumentar globalmente o
work_mem
valor. Essa ação facilita o processamento da maioria das consultas na memória, para que você possa evitar operações baseadas em disco e melhorar a eficiência. No entanto, seja sempre cauteloso e monitore a utilização da memória em seu servidor para garantir que ele possa lidar com o valor aumentadowork_mem
.
Determinação do valor mínimo de work_mem para operações de classificação
Para encontrar o valor mínimo work_mem
para uma consulta específica, especialmente uma que gera arquivos de disco temporários durante o processo de classificação, comece considerando o tamanho do arquivo temporário gerado durante a execução da consulta. Por exemplo, se uma consulta estiver gerando um arquivo temporário de 20 MB:
- Conecte-se ao seu banco de dados usando psql ou seu cliente PostgreSQL preferido.
- Defina um valor inicial
work_mem
ligeiramente superior a 20 MB para ter em conta cabeçalhos adicionais durante o processamento na memória. Use um comando como:SET work_mem TO '25MB'
. - Execute
EXPLAIN ANALYZE
a consulta problemática na mesma sessão. - Analise a saída para
"Sort Method: quicksort Memory: xkB"
. Se indicar"external merge Disk: xkB"
, aumente owork_mem
valor incrementalmente e teste novamente até"quicksort Memory"
aparecer. A aparência dos sinais de"quicksort Memory"
que a consulta agora está operando na memória. - Depois de determinar o valor por meio desse método, você pode aplicá-lo globalmente ou em níveis mais granulares (conforme descrito anteriormente) para atender às suas necessidades operacionais.
autovacuum_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada por cada processo de trabalho de vácuo automático. |
Tipo de dados | integer |
Default value | -1 |
Valores permitidos | -1-2097151 |
Tipo de parâmetro | dynamic |
Documentação | autovacuum_work_mem |
dynamic_shared_memory_type
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Seleciona a implementação de memória compartilhada dinâmica usada. |
Tipo de dados | enumeração |
Default value | posix |
Valores permitidos | posix |
Tipo de parâmetro | somente leitura |
Documentação | dynamic_shared_memory_type |
hash_mem_multiplier
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Vários dos work_mem usar para tabelas de hash. |
Tipo de dados | numérico |
Default value | 1 |
Valores permitidos | 1-1000 |
Tipo de parâmetro | dynamic |
Documentação | hash_mem_multiplier |
huge_pages
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Habilita/desabilita o uso de páginas de memória enormes. Essa configuração não é aplicável a servidores com menos de 4 vCores. |
Tipo de dados | enumeração |
Default value | try |
Valores permitidos | on,off,try |
Tipo de parâmetro | estático |
Documentação | huge_pages |
Description
Páginas enormes são um recurso que permite que a memória seja gerenciada em blocos maiores. Normalmente, você pode gerenciar blocos de até 2 MB, em oposição às páginas padrão de 4 KB.
O uso de páginas enormes pode oferecer vantagens de desempenho que efetivamente descarregam a CPU:
- Eles reduzem a sobrecarga associada a tarefas de gerenciamento de memória, como menos falhas de buffer de lookaside de tradução (TLB).
- Eles reduzem o tempo necessário para o gerenciamento de memória.
Especificamente, no PostgreSQL, você pode usar páginas enormes apenas para a área de memória compartilhada. Uma parte significativa da área de memória compartilhada é alocada para buffers compartilhados.
Outra vantagem é que páginas enormes impedem a troca da área de memória compartilhada para o disco, o que estabiliza ainda mais o desempenho.
Recomendações
- Para servidores com recursos de memória significativos, evite desativar páginas enormes. Desativar páginas enormes pode comprometer o desempenho.
- Se você começar com um servidor menor que não suporta páginas enormes, mas prevê escalar para um servidor que o faça, mantenha a
huge_pages
configuração paraTRY
uma transição perfeita e desempenho ideal.
Notas específicas do Azure
Para servidores com quatro ou mais vCores, páginas enormes são automaticamente alocadas a partir do sistema operacional subjacente. O recurso não está disponível para servidores com menos de quatro vCores. O número de páginas enormes é ajustado automaticamente se quaisquer configurações de memória compartilhada forem alteradas, incluindo alterações no shared_buffers
.
maintenance_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada para operações de manutenção, como VACUUM, Create Index. |
Tipo de dados | integer |
Default value | Depende dos recursos (vCores, RAM ou espaço em disco) alocados para o servidor. |
Valores permitidos | 1024-2097151 |
Tipo de parâmetro | dynamic |
Documentação | maintenance_work_mem |
Description
maintenance_work_mem
é um parâmetro de configuração no PostgreSQL. Ele governa a quantidade de memória alocada para operações de manutenção, como VACUUM
, CREATE INDEX
e ALTER TABLE
. Ao contrário work_mem
do , que afeta a alocação de memória para operações de consulta, maintenance_work_mem
é reservado para tarefas que mantêm e otimizam a estrutura do banco de dados.
Pontos principais
- Tampa de memória de vácuo: Se você quiser acelerar a limpeza de tuplas mortas aumentando
maintenance_work_mem
, esteja ciente de queVACUUM
tem uma limitação embutida para coletar identificadores de tupla morta. Ele pode usar apenas até 1 GB de memória para este processo. - Separação de memória para autovácuo: Você pode usar a
autovacuum_work_mem
configuração para controlar a memória que as operações de vácuo automático usam independentemente. Essa configuração atua como um subconjunto demaintenance_work_mem
. Você pode decidir quanta memória o autovacuum usa sem afetar a alocação de memória para outras tarefas de manutenção e operações de definição de dados.
Notas específicas do Azure
O valor padrão para o maintenance_work_mem
parâmetro server é calculado quando você provisiona a instância do Banco de Dados do Azure para servidor flexível PostgreSQL, com base no nome do produto selecionado para sua computação. Quaisquer alterações subsequentes da seleção de produtos para a computação que suporta o servidor flexível não terão qualquer efeito sobre o valor padrão para o maintenance_work_mem
parâmetro de servidor dessa instância.
Toda vez que você alterar o produto atribuído a uma instância, você também deve ajustar o valor para o maintenance_work_mem
parâmetro de acordo com os valores na fórmula a seguir.
A fórmula usada para calcular o valor de maintenance_work_mem
é (long)(82.5 * ln(memoryGiB) + 40) * 1024
.
Com base na fórmula anterior, a tabela a seguir lista os valores para os quais esse parâmetro de servidor seria definido dependendo da quantidade de memória provisionada:
Tamanho da memória | maintenance_work_mem |
---|---|
2 GiB | 99328 KiB |
4 GiB | 157696 KiB |
8 GiB | 216064 KiB |
16 GiB | 274432 KiB |
32 GiB | 332800 KiB |
48 GiB | 367616 KiB |
64 GiB | 392192 KiB |
80 GiB | 410624 KiB |
128 GiB | 450560 KiB |
160 GiB | 468992 KiB |
192 GiB | 484352 KiB |
256 GiB | 508928 KiB |
384 GiB | 542720 KiB |
432 GiB | 552960 KiB |
672 GiB | 590848 KiB |
max_prepared_transactions
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número máximo de transações preparadas simultaneamente. Ao executar um servidor de réplica, você deve definir esse parâmetro para o mesmo valor ou maior do que no servidor primário. |
Tipo de dados | integer |
Default value | 0 |
Valores permitidos | 0-262143 |
Tipo de parâmetro | estático |
Documentação | max_prepared_transactions |
max_stack_depth
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a profundidade máxima da pilha, em kilobytes. |
Tipo de dados | integer |
Default value | 2048 |
Valores permitidos | 2048 |
Tipo de parâmetro | somente leitura |
Documentação | max_stack_depth |
shared_buffers
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número de buffers de memória compartilhada usados pelo servidor. A unidade é de 8kb. Os valores permitidos estão dentro do intervalo de 10% - 75% da memória disponível. |
Tipo de dados | integer |
Default value | Depende dos recursos (vCores, RAM ou espaço em disco) alocados para o servidor. |
Valores permitidos | 16-1073741823 |
Tipo de parâmetro | estático |
Documentação | shared_buffers |
Description
O shared_buffers
parâmetro configuration determina a quantidade de memória do sistema alocada para o banco de dados PostgreSQL para buffer de dados. Ele serve como um pool de memória centralizado acessível a todos os processos de banco de dados.
Quando os dados são necessários, o processo do banco de dados primeiro verifica o buffer compartilhado. Se os dados necessários estiverem presentes, eles serão recuperados rapidamente e ignorarão uma leitura de disco mais demorada. Os buffers compartilhados servem como intermediários entre os processos do banco de dados e o disco e reduzem efetivamente o número de operações de E/S necessárias.
Notas específicas do Azure
O valor padrão para o shared_buffers
parâmetro server é calculado quando você provisiona a instância do Banco de Dados do Azure para servidor flexível PostgreSQL, com base no nome do produto selecionado para sua computação. Quaisquer alterações subsequentes da seleção de produtos para a computação que suporta o servidor flexível não têm qualquer efeito sobre o valor padrão para o shared_buffers
parâmetro de servidor dessa instância.
Sempre que alterar o produto atribuído a uma instância, você também deve ajustar o valor do shared_buffers
parâmetro de acordo com os valores nas fórmulas a seguir.
Para máquinas virtuais com até 2 GiB de memória, a fórmula usada para calcular o valor de shared_buffers
é memoryGib * 16384
.
Para máquinas virtuais com mais de 2 GiB, a fórmula usada para calcular o valor de shared_buffers
é memoryGib * 32768
.
Com base na fórmula anterior, a tabela a seguir lista os valores para os quais esse parâmetro de servidor seria definido dependendo da quantidade de memória provisionada:
Tamanho da memória | shared_buffers |
---|---|
2 GiB | 32768 |
4 GiB | 131072 |
8 GiB | 262144 |
16 GiB | 524288 |
32 GiB | 1048576 |
48 GiB | 1572864 |
64 GiB | 2097152 |
80 GiB | 2621440 |
128 GiB | 4194304 |
160 GiB | 5242880 |
192 GiB | 6291456 |
256 GiB | 8388608 |
384 GiB | 12582912 |
432 GiB | 14155776 |
672 GiB | 22020096 |
shared_memory_type
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Seleciona a implementação de memória compartilhada usada para a região principal de memória compartilhada. |
Tipo de dados | enumeração |
Default value | mmap |
Valores permitidos | mmap |
Tipo de parâmetro | somente leitura |
Documentação | shared_memory_type |
temp_buffers
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número máximo de buffers temporários usados por cada sessão de banco de dados. |
Tipo de dados | integer |
Default value | 1024 |
Valores permitidos | 100-1073741823 |
Tipo de parâmetro | dynamic |
Documentação | temp_buffers |
work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a quantidade de memória a ser usada por operações de classificação internas e tabelas de hash antes de gravar em arquivos de disco temporários. |
Tipo de dados | integer |
Default value | 4096 |
Valores permitidos | 4096-2097151 |
Tipo de parâmetro | dynamic |
Documentação | work_mem |
Description
O work_mem
parâmetro no PostgreSQL controla a quantidade de memória alocada para determinadas operações internas dentro da área de memória privada de cada sessão de banco de dados. Exemplos dessas operações são classificação e hashing.
Ao contrário dos buffers compartilhados, que estão na área de memória compartilhada, work_mem
é alocado em um espaço de memória privada por sessão ou por consulta. Ao definir um tamanho adequado work_mem
, você pode melhorar significativamente a eficiência dessas operações e reduzir a necessidade de gravar dados temporários no disco.
Pontos principais
- Memória de conexão privada:
work_mem
faz parte da memória privada usada por cada sessão de banco de dados. Essa memória é distinta da área de memória compartilhada queshared_buffers
usa. - Uso específico da consulta: nem todas as sessões ou consultas usam
work_mem
o . É improvável que consultas simples comoSELECT 1
as exijamwork_mem
. No entanto, consultas complexas que envolvem operações como classificação ou hash podem consumir uma ou várias partes dowork_mem
. - Operações paralelas: Para consultas que abrangem vários back-ends paralelos, cada back-end pode potencialmente usar uma ou várias partes do
work_mem
.
Monitorização e ajustamento work_mem
É essencial monitorar continuamente o desempenho do seu sistema e ajustar work_mem
conforme necessário, principalmente se os tempos de execução da consulta relacionados às operações de classificação ou hash forem lentos. Eis algumas formas de monitorizar o desempenho utilizando as ferramentas disponíveis no portal do Azure:
- Visão de desempenho da consulta: marque a guia Principais consultas por arquivos temporários para identificar consultas que estão gerando arquivos temporários. Esta situação sugere uma potencial necessidade de aumentar.
work_mem
- Guias de solução de problemas: use a guia Arquivos temporários altos nos guias de solução de problemas para identificar consultas problemáticas.
Ajuste granular
Enquanto você gerencia o work_mem
parâmetro, geralmente é mais eficiente adotar uma abordagem de ajuste granular em vez de definir um valor global. Essa abordagem garante que você aloque memória criteriosamente com base nas necessidades específicas de processos e usuários. Ele também minimiza o risco de encontrar problemas de falta de memória. Veja como você pode fazer isso:
Nível de usuário: se um usuário específico estiver envolvido principalmente em tarefas de agregação ou relatório, que consomem muita memória, considere personalizar o
work_mem
valor para esse usuário. Use oALTER ROLE
comando para melhorar o desempenho das operações do usuário.Nível de função/procedimento: Se funções ou procedimentos específicos estão gerando arquivos temporários substanciais, aumentar o
work_mem
valor no nível de função ou procedimento específico pode ser benéfico. Use oALTER FUNCTION
comando ouALTER PROCEDURE
para alocar especificamente mais memória para essas operações.Nível do banco de dados: altere
work_mem
no nível do banco de dados se apenas bancos de dados específicos estiverem gerando um grande número de arquivos temporários.Nível global: Se uma análise do seu sistema revelar que a maioria das consultas está gerando pequenos arquivos temporários, enquanto apenas alguns estão criando arquivos grandes, pode ser prudente aumentar globalmente o
work_mem
valor. Essa ação facilita o processamento da maioria das consultas na memória, para que você possa evitar operações baseadas em disco e melhorar a eficiência. No entanto, seja sempre cauteloso e monitore a utilização da memória em seu servidor para garantir que ele possa lidar com o valor aumentadowork_mem
.
Determinação do valor mínimo de work_mem para operações de classificação
Para encontrar o valor mínimo work_mem
para uma consulta específica, especialmente uma que gera arquivos de disco temporários durante o processo de classificação, comece considerando o tamanho do arquivo temporário gerado durante a execução da consulta. Por exemplo, se uma consulta estiver gerando um arquivo temporário de 20 MB:
- Conecte-se ao seu banco de dados usando psql ou seu cliente PostgreSQL preferido.
- Defina um valor inicial
work_mem
ligeiramente superior a 20 MB para ter em conta cabeçalhos adicionais durante o processamento na memória. Use um comando como:SET work_mem TO '25MB'
. - Execute
EXPLAIN ANALYZE
a consulta problemática na mesma sessão. - Analise a saída para
"Sort Method: quicksort Memory: xkB"
. Se indicar"external merge Disk: xkB"
, aumente owork_mem
valor incrementalmente e teste novamente até"quicksort Memory"
aparecer. A aparência dos sinais de"quicksort Memory"
que a consulta agora está operando na memória. - Depois de determinar o valor por meio desse método, você pode aplicá-lo globalmente ou em níveis mais granulares (conforme descrito anteriormente) para atender às suas necessidades operacionais.
autovacuum_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada por cada processo de trabalho de vácuo automático. |
Tipo de dados | integer |
Default value | -1 |
Valores permitidos | -1-2097151 |
Tipo de parâmetro | dynamic |
Documentação | autovacuum_work_mem |
dynamic_shared_memory_type
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Seleciona a implementação de memória compartilhada dinâmica usada. |
Tipo de dados | enumeração |
Default value | posix |
Valores permitidos | posix |
Tipo de parâmetro | somente leitura |
Documentação | dynamic_shared_memory_type |
huge_pages
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Habilita/desabilita o uso de páginas de memória enormes. Essa configuração não é aplicável a servidores com menos de 4 vCores. |
Tipo de dados | enumeração |
Default value | try |
Valores permitidos | on,off,try |
Tipo de parâmetro | estático |
Documentação | huge_pages |
Description
Páginas enormes são um recurso que permite que a memória seja gerenciada em blocos maiores. Normalmente, você pode gerenciar blocos de até 2 MB, em oposição às páginas padrão de 4 KB.
O uso de páginas enormes pode oferecer vantagens de desempenho que efetivamente descarregam a CPU:
- Eles reduzem a sobrecarga associada a tarefas de gerenciamento de memória, como menos falhas de buffer de lookaside de tradução (TLB).
- Eles reduzem o tempo necessário para o gerenciamento de memória.
Especificamente, no PostgreSQL, você pode usar páginas enormes apenas para a área de memória compartilhada. Uma parte significativa da área de memória compartilhada é alocada para buffers compartilhados.
Outra vantagem é que páginas enormes impedem a troca da área de memória compartilhada para o disco, o que estabiliza ainda mais o desempenho.
Recomendações
- Para servidores com recursos de memória significativos, evite desativar páginas enormes. Desativar páginas enormes pode comprometer o desempenho.
- Se você começar com um servidor menor que não suporta páginas enormes, mas prevê escalar para um servidor que o faça, mantenha a
huge_pages
configuração paraTRY
uma transição perfeita e desempenho ideal.
Notas específicas do Azure
Para servidores com quatro ou mais vCores, páginas enormes são automaticamente alocadas a partir do sistema operacional subjacente. O recurso não está disponível para servidores com menos de quatro vCores. O número de páginas enormes é ajustado automaticamente se quaisquer configurações de memória compartilhada forem alteradas, incluindo alterações no shared_buffers
.
maintenance_work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a memória máxima a ser usada para operações de manutenção, como VACUUM, Create Index. |
Tipo de dados | integer |
Default value | Depende dos recursos (vCores, RAM ou espaço em disco) alocados para o servidor. |
Valores permitidos | 1024-2097151 |
Tipo de parâmetro | dynamic |
Documentação | maintenance_work_mem |
Description
maintenance_work_mem
é um parâmetro de configuração no PostgreSQL. Ele governa a quantidade de memória alocada para operações de manutenção, como VACUUM
, CREATE INDEX
e ALTER TABLE
. Ao contrário work_mem
do , que afeta a alocação de memória para operações de consulta, maintenance_work_mem
é reservado para tarefas que mantêm e otimizam a estrutura do banco de dados.
Pontos principais
- Tampa de memória de vácuo: Se você quiser acelerar a limpeza de tuplas mortas aumentando
maintenance_work_mem
, esteja ciente de queVACUUM
tem uma limitação embutida para coletar identificadores de tupla morta. Ele pode usar apenas até 1 GB de memória para este processo. - Separação de memória para autovácuo: Você pode usar a
autovacuum_work_mem
configuração para controlar a memória que as operações de vácuo automático usam independentemente. Essa configuração atua como um subconjunto demaintenance_work_mem
. Você pode decidir quanta memória o autovacuum usa sem afetar a alocação de memória para outras tarefas de manutenção e operações de definição de dados.
Notas específicas do Azure
O valor padrão para o maintenance_work_mem
parâmetro server é calculado quando você provisiona a instância do Banco de Dados do Azure para servidor flexível PostgreSQL, com base no nome do produto selecionado para sua computação. Quaisquer alterações subsequentes da seleção de produtos para a computação que suporta o servidor flexível não terão qualquer efeito sobre o valor padrão para o maintenance_work_mem
parâmetro de servidor dessa instância.
Toda vez que você alterar o produto atribuído a uma instância, você também deve ajustar o valor para o maintenance_work_mem
parâmetro de acordo com os valores na fórmula a seguir.
A fórmula usada para calcular o valor de maintenance_work_mem
é (long)(82.5 * ln(memoryGiB) + 40) * 1024
.
Com base na fórmula anterior, a tabela a seguir lista os valores para os quais esse parâmetro de servidor seria definido dependendo da quantidade de memória provisionada:
Tamanho da memória | maintenance_work_mem |
---|---|
2 GiB | 99328 KiB |
4 GiB | 157696 KiB |
8 GiB | 216064 KiB |
16 GiB | 274432 KiB |
32 GiB | 332800 KiB |
48 GiB | 367616 KiB |
64 GiB | 392192 KiB |
80 GiB | 410624 KiB |
128 GiB | 450560 KiB |
160 GiB | 468992 KiB |
192 GiB | 484352 KiB |
256 GiB | 508928 KiB |
384 GiB | 542720 KiB |
432 GiB | 552960 KiB |
672 GiB | 590848 KiB |
max_prepared_transactions
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número máximo de transações preparadas simultaneamente. Ao executar um servidor de réplica, você deve definir esse parâmetro para o mesmo valor ou maior do que no servidor primário. |
Tipo de dados | integer |
Default value | 0 |
Valores permitidos | 0-262143 |
Tipo de parâmetro | estático |
Documentação | max_prepared_transactions |
max_stack_depth
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a profundidade máxima da pilha, em kilobytes. |
Tipo de dados | integer |
Default value | 2048 |
Valores permitidos | 2048 |
Tipo de parâmetro | somente leitura |
Documentação | max_stack_depth |
shared_buffers
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número de buffers de memória compartilhada usados pelo servidor. A unidade é de 8kb. Os valores permitidos estão dentro do intervalo de 10% - 75% da memória disponível. |
Tipo de dados | integer |
Default value | Depende dos recursos (vCores, RAM ou espaço em disco) alocados para o servidor. |
Valores permitidos | 16-1073741823 |
Tipo de parâmetro | estático |
Documentação | shared_buffers |
Description
O shared_buffers
parâmetro configuration determina a quantidade de memória do sistema alocada para o banco de dados PostgreSQL para buffer de dados. Ele serve como um pool de memória centralizado acessível a todos os processos de banco de dados.
Quando os dados são necessários, o processo do banco de dados primeiro verifica o buffer compartilhado. Se os dados necessários estiverem presentes, eles serão recuperados rapidamente e ignorarão uma leitura de disco mais demorada. Os buffers compartilhados servem como intermediários entre os processos do banco de dados e o disco e reduzem efetivamente o número de operações de E/S necessárias.
Notas específicas do Azure
O valor padrão para o shared_buffers
parâmetro server é calculado quando você provisiona a instância do Banco de Dados do Azure para servidor flexível PostgreSQL, com base no nome do produto selecionado para sua computação. Quaisquer alterações subsequentes da seleção de produtos para a computação que suporta o servidor flexível não têm qualquer efeito sobre o valor padrão para o shared_buffers
parâmetro de servidor dessa instância.
Sempre que alterar o produto atribuído a uma instância, você também deve ajustar o valor do shared_buffers
parâmetro de acordo com os valores nas fórmulas a seguir.
Para máquinas virtuais com até 2 GiB de memória, a fórmula usada para calcular o valor de shared_buffers
é memoryGib * 16384
.
Para máquinas virtuais com mais de 2 GiB, a fórmula usada para calcular o valor de shared_buffers
é memoryGib * 32768
.
Com base na fórmula anterior, a tabela a seguir lista os valores para os quais esse parâmetro de servidor seria definido dependendo da quantidade de memória provisionada:
Tamanho da memória | shared_buffers |
---|---|
2 GiB | 32768 |
4 GiB | 131072 |
8 GiB | 262144 |
16 GiB | 524288 |
32 GiB | 1048576 |
48 GiB | 1572864 |
64 GiB | 2097152 |
80 GiB | 2621440 |
128 GiB | 4194304 |
160 GiB | 5242880 |
192 GiB | 6291456 |
256 GiB | 8388608 |
384 GiB | 12582912 |
432 GiB | 14155776 |
672 GiB | 22020096 |
temp_buffers
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define o número máximo de buffers temporários usados por cada sessão de banco de dados. |
Tipo de dados | integer |
Default value | 1024 |
Valores permitidos | 100-1073741823 |
Tipo de parâmetro | dynamic |
Documentação | temp_buffers |
work_mem
Atributo | Value |
---|---|
Categoria | Utilização de Recursos / Memória |
Description | Define a quantidade de memória a ser usada por operações de classificação internas e tabelas de hash antes de gravar em arquivos de disco temporários. |
Tipo de dados | integer |
Default value | 4096 |
Valores permitidos | 4096-2097151 |
Tipo de parâmetro | dynamic |
Documentação | work_mem |
Description
O work_mem
parâmetro no PostgreSQL controla a quantidade de memória alocada para determinadas operações internas dentro da área de memória privada de cada sessão de banco de dados. Exemplos dessas operações são classificação e hashing.
Ao contrário dos buffers compartilhados, que estão na área de memória compartilhada, work_mem
é alocado em um espaço de memória privada por sessão ou por consulta. Ao definir um tamanho adequado work_mem
, você pode melhorar significativamente a eficiência dessas operações e reduzir a necessidade de gravar dados temporários no disco.
Pontos principais
- Memória de conexão privada:
work_mem
faz parte da memória privada usada por cada sessão de banco de dados. Essa memória é distinta da área de memória compartilhada queshared_buffers
usa. - Uso específico da consulta: nem todas as sessões ou consultas usam
work_mem
o . É improvável que consultas simples comoSELECT 1
as exijamwork_mem
. No entanto, consultas complexas que envolvem operações como classificação ou hash podem consumir uma ou várias partes dowork_mem
. - Operações paralelas: Para consultas que abrangem vários back-ends paralelos, cada back-end pode potencialmente usar uma ou várias partes do
work_mem
.
Monitorização e ajustamento work_mem
É essencial monitorar continuamente o desempenho do seu sistema e ajustar work_mem
conforme necessário, principalmente se os tempos de execução da consulta relacionados às operações de classificação ou hash forem lentos. Eis algumas formas de monitorizar o desempenho utilizando as ferramentas disponíveis no portal do Azure:
- Visão de desempenho da consulta: marque a guia Principais consultas por arquivos temporários para identificar consultas que estão gerando arquivos temporários. Esta situação sugere uma potencial necessidade de aumentar.
work_mem
- Guias de solução de problemas: use a guia Arquivos temporários altos nos guias de solução de problemas para identificar consultas problemáticas.
Ajuste granular
Enquanto você gerencia o work_mem
parâmetro, geralmente é mais eficiente adotar uma abordagem de ajuste granular em vez de definir um valor global. Essa abordagem garante que você aloque memória criteriosamente com base nas necessidades específicas de processos e usuários. Ele também minimiza o risco de encontrar problemas de falta de memória. Veja como você pode fazer isso:
Nível de usuário: se um usuário específico estiver envolvido principalmente em tarefas de agregação ou relatório, que consomem muita memória, considere personalizar o
work_mem
valor para esse usuário. Use oALTER ROLE
comando para melhorar o desempenho das operações do usuário.Nível de função/procedimento: Se funções ou procedimentos específicos estão gerando arquivos temporários substanciais, aumentar o
work_mem
valor no nível de função ou procedimento específico pode ser benéfico. Use oALTER FUNCTION
comando ouALTER PROCEDURE
para alocar especificamente mais memória para essas operações.Nível do banco de dados: altere
work_mem
no nível do banco de dados se apenas bancos de dados específicos estiverem gerando um grande número de arquivos temporários.Nível global: Se uma análise do seu sistema revelar que a maioria das consultas está gerando pequenos arquivos temporários, enquanto apenas alguns estão criando arquivos grandes, pode ser prudente aumentar globalmente o
work_mem
valor. Essa ação facilita o processamento da maioria das consultas na memória, para que você possa evitar operações baseadas em disco e melhorar a eficiência. No entanto, seja sempre cauteloso e monitore a utilização da memória em seu servidor para garantir que ele possa lidar com o valor aumentadowork_mem
.
Determinação do valor mínimo de work_mem para operações de classificação
Para encontrar o valor mínimo work_mem
para uma consulta específica, especialmente uma que gera arquivos de disco temporários durante o processo de classificação, comece considerando o tamanho do arquivo temporário gerado durante a execução da consulta. Por exemplo, se uma consulta estiver gerando um arquivo temporário de 20 MB:
- Conecte-se ao seu banco de dados usando psql ou seu cliente PostgreSQL preferido.
- Defina um valor inicial
work_mem
ligeiramente superior a 20 MB para ter em conta cabeçalhos adicionais durante o processamento na memória. Use um comando como:SET work_mem TO '25MB'
. - Execute
EXPLAIN ANALYZE
a consulta problemática na mesma sessão. - Analise a saída para
"Sort Method: quicksort Memory: xkB"
. Se indicar"external merge Disk: xkB"
, aumente owork_mem
valor incrementalmente e teste novamente até"quicksort Memory"
aparecer. A aparência dos sinais de"quicksort Memory"
que a consulta agora está operando na memória. - Depois de determinar o valor por meio desse método, você pode aplicá-lo globalmente ou em níveis mais granulares (conforme descrito anteriormente) para atender às suas necessidades operacionais.