PostgreSQL pg_stat_activity mostra COMMIT

Recentemente, substituímos nosso servidor de banco de dados por uma máquina atualizada com 4 CPUs quad core e 32 GB de RAM. Também reformulamos nossa caixa antiga para servir como escravo com replicação de streaming. Ambas as caixas estão executando o CentOS 6.3 e o PostgreSQL 9.2. O Postgres é a única coisa em execução em cada uma das caixas.

Essa configuração existe há cerca de um mês, quando, de repente, começamos a enfrentar alguns problemas, à medida que o tráfego aumentava. O que começamos a ver é uma carga de CPU extremamente alta às vezes (a parte superior mostra uma média de carga de 270) e, quando podemos olhar, pg_stat_activityveremos que a maioria de nossas conexões está no COMMITestado. Quando deixado sozinho, isso acabará e o sistema se tornará responsivo à medida que as conexões se tornarem IDLE. Tentamos desativar a replicação para verificar se esse poderia ser o problema, mas o problema ainda persiste.

Tentamos diagnosticar o que está acontecendo e estamos um pouco perdidos. A saída da execução perfmostra algo semelhante ao abaixo, e não tenho idéia do que 0x347ba9representa.

+  41.40%       48154  postmaster  0x347ba9         f 0x347ba9                                   ◆
+   9.55%       10956  postmaster  0x2dc820         f set_config_option                          ▒
+   8.64%        9946  postmaster  0x5a3d4          f writeListPage     
+   5.75%        6609  postmaster  0x5a2b0          f ginHeapTupleFastCollect                    ▒
+   2.68%        3084  postmaster  0x192483         f build_implied_join_equality                ▒
+   2.61%        2990  postmaster  0x187a55         f build_paths_for_OR                         ▒
+   1.86%        2131  postmaster  0x794aa          f get_collation_oid                          ▒
+   1.56%        1822  postmaster  0x5a67e          f ginHeapTupleFastInsert                     ▒
+   1.53%        1766  postmaster  0x1929bc         f distribute_qual_to_rels                    ▒
+   1.33%        1558  postmaster  0x249671         f cmp_numerics

Nenhuma das consultas realizadas pelo aplicativo é particularmente complexa, com planos de explicação levando no máximo 1 segundo (a maioria é muito mais rápida). Além disso, embora isso aconteça quando o tráfego começa a aumentar, não estamos falando de uma enorme carga de tráfego (a máquina antiga costumava lidar com isso com bastante facilidade).

Neste ponto, estou um pouco perplexo com o que tentar a seguir. Qualquer ajuda ou sugestão seria apreciada. Se houver alguma informação adicional que possa ajudar, basta perguntar e eu posso alterar a pergunta.

Configuração de disco:

Controlador RAID Perc 6i
5 unidades SAS de 146 GB e 15 GB
Configurado como 2x146GB RAID-1 para WAL e 3x146GB RAID-5 para Sistema e Dados

Atualizar:

Abaixo está a saída VMStat quando o sistema está funcionando normalmente e quando a CPU dispara. Quando há um problema, as interrupções parecem disparar.

Durante operação normal:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 18938590 303763 21947154    0    0    28    52 7466 12649  2  1 97  0  0   2013-01-14 16:03:25 EST
 0  0      0 18938396 303763 21947154    0    0     0    19 7107 12679  2  0 98  0  0   2013-01-14 16:03:35 EST
 1  0      0 18938904 303763 21947162    0    0     0    54 7042 12708  1  1 99  0  0   2013-01-14 16:03:45 EST
 1  0      0 18938520 303763 21947260    0    0    33    66 7120 12738  1  1 99  0  0   2013-01-14 16:03:55 EST

Quando o uso da CPU é alto:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
343 0      0 32680468 226279 11339612    0    0     0   214 26692 12225 80  20  0  0  0   2013-01-11 16:45:53 EST
374 1      0 32673764 226291 11340345    0    0     0    77 54893 11572 80  20  0  0  0   2013-01-11 16:46:03 EST
383 0      0 32616620 226304 11340956    0    0     0   102 55540 12922 82  18  0  0  0   2013-01-11 16:46:13 EST
315 0      0 32602038 226320 11341378    0    0     0    79 54539 12441 82  18  0  0  0   2013-01-11 16:46:23 EST

postgresql

— jcern
fonte

Que tipo de discos a nova caixa possui? Isso está acontecendo nos dois nós ou em apenas um deles?

— Trygve Laugstøl

@trygvis - Atualizei a pergunta com as especificações do disco. O problema está acontecendo no nó mestre. Eu não tentei promover o Escravo e direcionar o tráfego para ele, então não tenho certeza se é um problema lá também nas mesmas circunstâncias. Como escrava, a máquina não parece ter nenhum problema.

— jcern

Considere usar a perfferramenta para fazer alguns perfis em todo o sistema e alguns perfis no PostgreSQL. Veja onde o uso da CPU está ocorrendo. BTW, a formatação do seu segundo vmstaté irremediavelmente confusa, e as colunas do primeiro estão desalinhadas, por isso é difícil de ler. Teste para ver se adicionar um commit_delaymelhora as coisas. Verifique se o seu controlador RAID possui um cache de write-back com bateria e, se não, obtenha um. Há muito tempo gasto iowait? Este parece ser o uso da CPU em alguns relatórios, mas não é realmente.

— Craig Ringer

@CraigRinger, o controlador possui um cache de gravação com bateria e atualmente está ativado. A espera do iostat permaneceu nos dígitos um a dois dígitos baixos. Continuaremos a tentar criar mais perfis com o perf. Também corrigi a formatação do segundo VMStat, obrigado por apontar isso.

— Jcern

Depois de mais diagnósticos e algumas pesquisas no Google, encontramos este artigo que descreveu muitos dos mesmos sintomas que estávamos experimentando. A causa raiz do problema (e pelo que sabemos, também o nosso) estava relacionada à Transparent Huge Pagesimplementação.

Depois de desativar Transparent Huge Pagescom este comando:

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled

O problema parece ter sido resolvido. Estamos com uma carga de trabalho aumentada nas últimas duas semanas e o problema não ressurgiu. Os contextos e interrupções do sistema são consistentemente 1/10 do que eram e o tempo médio do sistema também diminuiu.

Não tenho certeza se é a solução para todos, mas eu a publico aqui como uma possível causa, caso possa ajudar alguém a resolver um problema semelhante.

— jcern
fonte