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 | 2 |
Tipo de parâmetro | somente leitura |
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.
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. Ao servir como intermediário entre os processos do banco de dados e o disco, shared_buffers
reduz efetivamente o número de operações de E/S necessárias.
Notas específicas do Azure
A definição shared_buffers
dimensiona-se de forma linear (aproximadamente) à medida que os vCores aumentam num escalão.
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 | 2 |
Valores permitidos | 2 |
Tipo de parâmetro | somente leitura |
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.
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. Ao servir como intermediário entre os processos do banco de dados e o disco, shared_buffers
reduz efetivamente o número de operações de E/S necessárias.
Notas específicas do Azure
A definição shared_buffers
dimensiona-se de forma linear (aproximadamente) à medida que os vCores aumentam num escalão.
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 |
Tipo de parâmetro | somente leitura |
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.
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. Ao servir como intermediário entre os processos do banco de dados e o disco, shared_buffers
reduz efetivamente o número de operações de E/S necessárias.
Notas específicas do Azure
A definição shared_buffers
dimensiona-se de forma linear (aproximadamente) à medida que os vCores aumentam num escalão.
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 |
Tipo de parâmetro | somente leitura |
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 | 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.
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. Ao servir como intermediário entre os processos do banco de dados e o disco, shared_buffers
reduz efetivamente o número de operações de E/S necessárias.
Notas específicas do Azure
A definição shared_buffers
dimensiona-se de forma linear (aproximadamente) à medida que os vCores aumentam num escalão.
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 |
Tipo de parâmetro | somente leitura |
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.
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. Ao servir como intermediário entre os processos do banco de dados e o disco, shared_buffers
reduz efetivamente o número de operações de E/S necessárias.
Notas específicas do Azure
A definição shared_buffers
dimensiona-se de forma linear (aproximadamente) à medida que os vCores aumentam num escalão.
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.
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. Ao servir como intermediário entre os processos do banco de dados e o disco, shared_buffers
reduz efetivamente o número de operações de E/S necessárias.
Notas específicas do Azure
A definição shared_buffers
dimensiona-se de forma linear (aproximadamente) à medida que os vCores aumentam num escalão.
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.
Comentários
https://aka.ms/ContentUserFeedback.
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja:Submeter e ver comentários