É possível melhorar o desempenho do banco de dados PostgreSQL de várias maneiras.
Os dois parâmetros a seguir controlam as operações automáticas de vacuum e, por padrão, esses parâmetros são comentados durante a instalação do servidor Sentinel Rapid Deployment, e você tem que remover o comentário e definir os valores.
vacuum_cost_delay: Determina por quanto tempo o processo vai ficar adormecido quando o limite de custo for excedido. Por exemplo, é possível definir esse valor como 100.
vacuum_cost_limit: Determina o custo acumulado que vai fazer com que o processo de vacuum adormeça. Por exemplo, é possível definir esse valor como 10000.
Se você definir o valor desses parâmetros diferente de zero, o impacto de E/S do comando vacuum e analyze será reduzido na atividade do banco de dados normal. Eles podem ter um impacto insignificante no desempenho durante a execução dos relatórios, já que o vacuum vai levar mais tempo do que antes.
Por padrão, o processo de autolimpeza está definido como verdadeiro e é executado periodicamente para recuperar o espaço em disco e atualizar as estatísticas do planejador. Quando o tamanho do banco de dados aumenta, a autolimpeza não consegue manter todos os objetos do banco de dados. Nesses casos, se o desempenho for lento, execute o script AnalyzePartitions.sh como uma tarefa cron. Essa tarefa cron deve ser definida pelo usuário proprietário dos processos do Sentinel Rapid Deployment.
Por exemplo:
30 11 * * * $ESEC_HOME/bin/AnalyzePartitions.sh
Onde:
30 é o tempo em minutos.
11 é o tempo em horas.
ESEC_HOME é o caminho absoluto do banco de dados.
Nesse exemplo, o script é executado diariamente às 11:30.
Evite programar o arquivamento para ocorrer durante a geração do relatório. Se você programar os dois processos juntos, a geração do relatório entrará em um estado de espera, por causa dos bugs do PostgreSQL, e iniciará o processamento dos dados após o término da tarefa de arquivamento. Essa mudança afeta o desempenho do banco de dados.