Como gerenciar melhor o uso elevado da CPU do PostgreSQL?

Question

Estou tentando corrigir um problema de uso elevado da CPU do PostgreSQL. Estamos usando o PostgreSQL 8.0.9 e quando nosso aplicativo web JEE (no JBoss) é usado em certas condições de aumento de carga, o top mostra um aumento lento nos processos do PostgreSQL. Quando o problema ocorre, há aproximadamente 12-15 processos do PostgreSQL, todos exibindo SELECT na parte direita da informação do processo e aproximadamente 6-7% do uso da CPU, e então o aplicativo fica muito lento. Versão do JBoss: JBoss (MX MicroKernel) 4.0.3
Sistema Operacional: CentOS Linux 5.5
Kernel e CPU: Linux 2.6.18-194.26.1.el5 em x86_64
Informações do processador: 2 x CPU Intel® Xeon (R) E5420 @ 2.50GHz, 8 núcleos

Atualmente, nosso pensamento é lançar mais hardware nele. Se fizermos isso, a melhor opção seria algo como a Opção A abaixo ou a Opção B?

Opção A: 4 processadores AMD Opteron ™ Série 6100, cada um com 12 núcleos Opção B: 4 x processadores Intel® Xeon® série 7500, cada um com 8 núcleos

É correto assumir que o CentOS Linux 5.5 com PostgreSQL 8.0.9 será escalonado proporcionalmente com a adição de muitos processadores e núcleos (Ex. 4 processadores com 12 núcleos cada)? Há algo mais que eu deveria considerar em termos de lançar mais hardware?

    

Answer 1

A pergunta é impossível de responder, não temos ideia do que está acontecendo. Você está falando de 12 a 15 conexões, o que é quase nada. Mas, ao executar consultas muito complexas ou usar um esquema de banco de dados inválido, a falta de índices, etc., o uso da cpu pode aumentar a qualquer momento.

A versão 8.0.9 é um problema sério, 8.0 é EOL a partir de outubro de 2010 e a correção mais recente é a versão 8.0.26 (4 anos de correções após 8.0.9). Você deve pelo menos atualizar para esta versão, para corrigir muitos bugs no 8.0.

Comece a registrar as consultas, use EXPLAIN para ver o plano de consulta, dê uma olhada no VACUUM e você pode precisar de um REINDEX também. Seu hardware parece bem por enquanto, você primeiro precisa encontrar a origem dos problemas.

Considere contratar um dba do PostgreSQL por alguns dias.

    

Answer 2

Se você está exibindo alto uso da CPU, pode ser devido a lentidão nas consultas. Sugiro ativar os recursos de registro de consulta lenta em postmaster.conf e verificar as consultas que demoram mais tempo do que deveriam.

Existe também a possibilidade de você estar limitado a E / S, pois os discos lentos podem facilmente fazer com que as consultas iniciem o backup. Sugiro instalar htop e verificar qual porcentagem do tempo de espera da CPU é atribuída ao iowait.

Além disso, eu recomendaria muito a atualização para a versão mais recente. Houve algumas melhorias massivas de desempenho desde 8.0, e a versão estável atual (9.0.x no momento da escrita) oferece mais informações quando EXPLAIN VERBOSE ANALYZE ing consulta.

De modo geral (e todas as outras condições sendo iguais), o PostgreSQL se adapta muito bem à medida que você adiciona núcleos (cada núcleo adiciona um ganho de desempenho de aproximadamente 96% (fora do ganho de desempenho teórico de 100% por núcleo adicional)).

Meu instinto inicial é que seus discos não conseguem acompanhar.

    

Answer 3

Acho que você vai se beneficiar do livro PostgreSQL 9.0 High Performance . Está disponível em PDF (download instantâneo), bem como em formato de árvore morta.

Acabamos de reconstruir nosso banco de dados usando os conselhos deste livro. Nossa nova caixa de banco de dados expulsa a antiga e não tivemos que gastar muito dinheiro fazendo isso. Existem capítulos que abordam especificamente cada uma das suas perguntas. Existem respostas, mas melhor ainda, existem também métodos (como você mede seu hardware para saber quão rápido ele é?)

Não sou especialista em Postgresql, mas vou lhe dizer o que aprendi sobre hardware e Postgresql. Sua milhagem pode variar.

Em geral, para os bancos de dados com os quais tenho experiência, o que importa mais do que o número e a velocidade das CPUs é:

• RAM adequada. Bancos de dados bebem memória como um bêbado rotgut de bebidas.
• largura de banda de E / S. Bancos de dados amam E / S.

Você obtém largura de banda de E / S com o RAID. O RAID10 faz bem para a maior parte dos dados do Postgresql. Quanto mais unidades, melhor para o desempenho. Coloque o xlog em um dispositivo separado, se puder. Esse pode ser o RAID1. O uso de uma placa RAID de hardware com cache de bateria oferece o melhor desempenho.

    

Answer 4

When the problem occurs, there are approximately 12-15 PostgreSQL processes all showing SELECT on the far right of the process information and approximately 6-7% CPU usage each and then the app slows down a lot.

12x6 = 72%, portanto, mesmo no ponto mais baixo, as CPUs estão bastante ocupadas. Jogue em tudo o mais, e é bem claro por que você está correndo. (Isto é supondo que você está olhando para as CPUs como um agregado; quando você olha para o tempo de processo em top , você está pressionando a tecla 1 para ver todo o tempo de CPU individual ou apenas olhando para o número que apresenta quais são todas as CPUs combinadas?)

Currently, our thought is to throw more hardware at it. If we do this, would the best option be something like Option A below or Option B?

Option A: 4 x AMD Opteron™ 6100 Series Processors each with 12 Cores

Option B: 4 x Intel® Xeon® 7500 series Processors each with 8 Cores

Mais núcleos. O PostgreSQL usará um modelo de processo por núcleo, então quanto mais, melhor. Eu olharia talvez 2x AMD CPU em 12 cada para 24 núcleos no total e, em seguida, comprar os 2 CPUs restantes ao longo do tempo, permitindo-lhe orçar-los.

Is it correct to assume that CentOS Linux 5.5 with PostgreSQL 8.0.9 will scale proportionately with the addition of this many processors and cores (Ex. 4 processors each with 12 cores)?

Sim. Posso estar enganado, mas acredito que as compilações mais antigas do kernel usaram um número fixo em um arquivo de cabeçalho C para determinar o número máximo de CPUs a serem procuradas, que geralmente tinham um limite superior de 32 no momento da compilação. Se você tivesse uma máquina "grande", apenas aumentaria o número para algo maior e recompilaria. Não totalmente certo, mas eu acho que eles removeram essa constante na série 2.6, então você deve ficar bem.

Is there something else I should consider in terms of throwing more hardware at it?

Você pode querer ajustar um pouco mais o software antes de lançar o hardware nele (ou ajustá-lo e ainda obter o novo hardware).

Se for uma instrução SELECT, você pode registrá-la e usar o EXPLAIN para descobrir onde ela está gastando seu tempo? Use o PgAdmin para executar e ajustar a consulta manualmente até que você possa reduzir um pouco o tempo de execução. Se a instrução SELECT for programática, você ainda poderá ver o impacto do uso de um novo índice.

Quanta memória você alocou para o PostgreSQL? Quanto em uma base por processo? Quanta memória compartilhada é alocada? Tudo isso pode ter um impacto adverso na execução do banco de dados.

Existem outros processos ou serviços que podem ser desativados (para liberar memória) ou redefinidos (para reduzir o consumo de CPU)?

    

Answer 5

Recentemente, tive problemas semelhantes em um banco de dados pequeno (7 tabelas, 30 MB) com consultas com muitas associações. A máquina é uma VM com 2 GB de RAM e sempre parece usar menos de 160 MB dela. Funcionou muito rápido até adicionarmos cerca de 1 milhão de novos dados. Então o servidor (8.4.5) começou a atingir 100% da CPU por entre 5 segundos a 30 minutos com as mesmas consultas que eram abaixo de segundos.

Conseguimos corrigir o problema por meio da atualização do servidor. Testes com 8.4.9 e 8.4.12 não mostraram o mau comportamento (mas 8.4.8 fizeram).