Início / user-13032

David S's questions

Martin Hope
David S
Asked: 2020-07-15 10:04:01 +0800 CST
  • 1

Eu tenho um problema em que parece que algumas tabelas grandes no meu banco de dados não estão sendo aspiradas pelo autovacuum deamon. Aqui está o que estou vendo:

SELECT schemaname, relname, n_live_tup, n_dead_tup, last_autovacuum
FROM pg_stat_all_tables
ORDER BY n_dead_tup DESC LIMIT 5;
+------------+-----------------------------+------------+------------+-------------------------------+
| schemaname |          relname            | n_live_tup | n_dead_tup |        last_autovacuum        |
+------------+-----------------------------+------------+------------+-------------------------------+
| md         | calculation_log_item        |   35989527 |    3559253 | 2020-07-13 03:41:37.49764-04  |
| audit      | transaction_statement       |     700356 |     557278 | NULL                          |
| audit      | record_history              |     701635 |     438849 | NULL                          |
| md         | program_requirement_state   |     193500 |      29204 | 2020-07-14 03:06:02.339032-04 |
| md         | calculation_log             |     157942 |      11792 | NULL                          |
+------------+-----------------------------+------------+------------+-------------------------------+
(5 rows)

Portanto, está claro que o daemon está em execução porque há valores na noite passada (nota: estou postando isso em 14/07/2020). Mas não consigo descobrir por que transaction_statement e record_history não são. Eles têm muitas tuplas mortas em comparação com as vivas.

Estou usando o PostgreSQL v11. Aqui estão as informações da versão completa:

select version();
+---------------------------------------------------------------------------------------------------------------------------------+
|                                                             version                                                             |
+---------------------------------------------------------------------------------------------------------------------------------+
| PostgreSQL 11.8 (Ubuntu 11.8-1.pgdg18.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0, 64-bit |
+---------------------------------------------------------------------------------------------------------------------------------+
(1 row)

O que poderia estar causando isso? Por favor, adicione um comentário se você acha que minha pergunta é vaga ou precisa de informações adicionais para responder (como configurações do postgresql.conf, etc).

postgresql autovacuum
Martin Hope
David S
Asked: 2014-01-16 21:46:15 +0800 CST
  • 1

Estou procurando ajuda para entender meu arquivo de log do PostgreSQL 9.3.

(Observação: talvez devam ser várias perguntas, todas envolvem o mesmo tópico geral - que é entender meu arquivo de log). No meu arquivo postgresql.conf, tenho as seguintes configurações relacionadas ao log:

log_min_duration_statement = 0
log_line_prefix = '%m session_id: %c; trans_id: %x '
log_statement = 'all'

Se eu tiver o seguinte no meu log:

2014-01-15 21:39:22.217 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  statement: BEGIN
2014-01-15 21:39:22.217 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  duration: 0.132 ms
2014-01-15 21:39:22.218 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  statement: SELECT t.oid, typarray
    FROM pg_type t JOIN pg_namespace ns
        ON typnamespace = ns.oid
    WHERE typname = 'hstore';

2014-01-15 21:39:22.219 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  duration: 1.651 ms
2014-01-15 21:39:22.220 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  statement: ROLLBACK
2014-01-15 21:39:22.220 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  duration: 0.043 ms
2014-01-15 21:39:22.220 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  statement: BEGIN
2014-01-15 21:39:22.220 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  duration: 0.028 ms
2014-01-15 21:39:22.220 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  statement: select version()
2014-01-15 21:39:22.221 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  duration: 0.204 ms
2014-01-15 21:39:22.222 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  statement: select current_schema()
2014-01-15 21:39:22.222 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  duration: 0.136 ms
2014-01-15 21:39:22.222 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  statement: show transaction isolation level
2014-01-15 21:39:22.222 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  duration: 0.065 ms
2014-01-15 21:39:22.223 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  statement: SELECT CAST('test plain returns' AS VARCHAR(60)) AS anon_1
2014-01-15 21:39:22.223 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  duration: 0.281 ms
2014-01-15 21:39:22.223 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  statement: SELECT CAST('test unicode returns' AS VARCHAR(60)) AS anon_1
2014-01-15 21:39:22.223 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  duration: 0.063 ms
2014-01-15 21:39:22.224 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  statement: SELECT 'x' AS some_label
2014-01-15 21:39:22.224 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  duration: 0.053 ms
2014-01-15 21:39:22.224 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  statement: ROLLBACK
2014-01-15 21:39:22.224 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  duration: 0.032 ms
2014-01-15 21:39:22.224 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  statement: BEGIN
2014-01-15 21:39:22.224 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  duration: 0.023 ms
2014-01-15 21:39:22.224 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  statement: show standard_conforming_strings
2014-01-15 21:39:22.224 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  duration: 0.035 ms
2014-01-15 21:39:22.225 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  statement: SELECT api_log_entry.id AS api_log_entry_id 
    FROM api_log_entry
2014-01-15 21:39:22.227 PST session_id: 52d7708a.eb7; trans_id: 0 LOG:  duration: 1.319 ms

Perguntas:

Neste log recortado, cada entrada de log (tudo com uma duração) representa uma chamada do aplicativo cliente (e é uma viagem de ida e volta)?

Dado meu log_line_prefix, por que trans_id está aparecendo como zero? Assusta -me dizer, mas pensei que veria um novo trans_id para cada "BEGIN" que foi registrado.

postgresql postgresql-9.3
Martin Hope
David S
Asked: 2013-06-06 16:36:38 +0800 CST
  • 2

Para muitas das minhas tabelas, adicionei gatilhos de auditoria (com base nesta página wiki ). Funciona muito bem e me ajudou várias vezes a descobrir quem mudou o quê no sistema. Temos um aplicativo Python/Django que fica no topo dos dados e esse código é rastreado no Git. No entanto, parece haver uma área do nosso sistema em que as alterações não são rastreadas muito bem. E essa é a função/triggers, etc no PostgreSQL. Eu gostaria que houvesse uma maneira de adicionar um recurso de auditoria semelhante ao esquema que tenho com os próprios dados.

Como o DBA rastreia essas mudanças? Observação: estou em uma posição em que há mais de uma pessoa com privilégios suficientes para "CRIAR OU SUBSTITUIR" uma função, então não posso necessariamente contar com uma pessoa para escrever um script e verificá-lo no Git e certamente posso não os force. Se possível, precisa ser automático.

Eu pensei em escrever um script python para "criar" um arquivo de script e escrevê-lo em um arquivo e, em seguida, confirmar programaticamente as alterações em um repositório git.

Outra opção seria adicionar algumas tabelas ao meu esquema de auditoria e apenas consultar todas as noites, procurar alterações e acertá-las em uma tabela. Certamente poderia funcionar, mas não tão bom quanto poder fazer um diff/blame via git.

Esta pode não ser a maior pergunta porque não tenho certeza do que estou procurando e pode não haver uma resposta "certa" exata, mas gostaria de saber o que as pessoas fazem. Eu fiz algumas "pesquisas" sobre o assunto, mas não estou encontrando muito (talvez eu esteja apenas usando os termos errados).

Por fim, atualmente estou usando o PostgreSQL 9.1.

postgresql postgresql-9.1