Postgres, de vez em quando apenas trava

Question

Estamos usando o Postgres como backend DB para nosso projeto Django. Tudo funciona bem, exceto de vez em quando Postgres jus trava. Carregue picos médios para 80 pontos, e existem muitos processos de posgtres. Até onde eu vejo problemático é a nossa mesa com os usuários online. Em cada solicitação há atualização, estamos atualizando a coluna "última vista". A cada minuto há cronjob excluindo usuários inativos por 1 minuto. E no exemplo de hoje, quando houve o Postgres, vi muitas atualizações e exclusões para e desta tabela. Eu acho que é algum tipo de condição de corrida?

Esta tabela com usuários on-line não é grande. Nas horas de ponta há ~ 800 registros. Aqui está o esquema.

   Column   |           Type           |                            Modifiers                            
------------+--------------------------+-----------------------------------------------------------------
 id         | integer                  | not null default nextval('spoleczniak_online_id_seq'::regclass)
 postac_id  | integer                  | not null
 data       | timestamp with time zone | not null
 zalogowany | timestamp with time zone | not null
Indexes:
    "spoleczniak_online_pkey" PRIMARY KEY, btree (id)
    "spoleczniak_online_postac_id_key" UNIQUE CONSTRAINT, btree (postac_id)
    "spoleczniak_online_data" btree (data)
Foreign-key constraints:
    "spoleczniak_online_postac_id_fkey" FOREIGN KEY (postac_id) REFERENCES postac_postacie(id) DEFERRABLE INITIALLY DEFERRED

Normalmente, o Postgres está gerando menos de 1,5 pontos médios de carga. Estamos executando em i7, 16 GB de RAM e hardware RAID-10 (3x2 discos) para OS / data + RAID-1 (2 discos) para WAL. Hardware RAID tem 512 MB de cache.

Eu tentei 9.0 e 9.1 beta (eu nem mesmo configurei logs do WAL para essa tabela em 9.1).

Estou realmente pensando em mudar para o MySQL, mas não conheço nenhuma ferramenta de conversão. : P

PS. Eu não sei se é mais Serverfault ou Stackoverflow ... mas como você pode ver eu decidi colocá-lo no Serverfault. : P

Editar:

Algumas informações dos registros:

Jul 31 20:37:16 postgres postgres[1420]: [3-1] LOG:  00000: process 1420 acquired ExclusiveLock on tuple (29,7) of relation 33107 of database 20005 after 2071.481 ms
Jul 31 20:37:16 postgres postgres[1420]: [3-2] LOCATION:  ProcSleep, proc.c:1076
Jul 31 20:37:16 postgres postgres[1420]: [3-3] STATEMENT:  UPDATE "spoleczniak_online" SET "postac_id" = 101651, "data" = '2011-07-31 20:39:18.000699', "zalogowany" = '2011-07-31 20:31:04.843741' WHERE "spoleczniak_online"."id" = 559650 
Jul 31 20:37:16 postgres postgres[1493]: [3-1] LOG:  00000: process 1493 acquired ExclusiveLock on tuple (29,7) of relation 33107 of database 20005 after 1393.154 ms
Jul 31 20:37:16 postgres postgres[1493]: [3-2] LOCATION:  ProcSleep, proc.c:1076
Jul 31 20:37:16 postgres postgres[1493]: [3-3] STATEMENT:  UPDATE "spoleczniak_online" SET "postac_id" = 101651, "data" = '2011-07-31 20:39:15.646537', "zalogowany" = '2011-07-31 20:31:04.843741' WHERE "spoleczniak_online"."id" = 559650 

Tudo bem, é um problema de bloqueio ... mas como posso evitar isso?

    

Answer 1

Isso parece ser um problema de bloqueio: algumas consultas grandes bloqueiam demais, portanto outras consultas em execução não podem ser concluídas até que o bloqueio seja liberado. Ative o log de consulta lenta, adicione mais monitoramento. Eu sugiro strongmente usar algum sistema de monitoramento (zabbix, zenoss, etc) para estar ciente do seu status de banco de dados postgresql.

Como um rápido 'monitoramento', dê uma olhada nas visualizações pg_stat_activity e pg_locks durante o hang. Aqui está uma boa consulta que estou começando com frequência:

SELECT
  datname, 
  NOW() - query_start AS duration, 
  procpid, 
  current_query 
FROM
  pg_stat_activity 
WHERE
    current_query <> '<IDLE>'
  AND
    NOW() - query_start > '1 second'
ORDER BY duration DESC;

Geralmente fornece informações suficientes, mas às vezes eu preciso correr mais para entender o que está acontecendo.

Atualize sua pergunta com a saída desta consulta (ou semelhante).

    

Answer 2

Eu recomendaria o livro PostgreSQL 9.0 High Performance capítulo 11, "Database atividade e estatísticas ". Outro ótimo lugar para resolver esse problema seria a lista de discussão postgresql-performance.