Início / user-175768

Peter's questions

Martin Hope
Peter
Asked: 2024-05-15 16:00:03 +0800 CST
  • 5

O Oracle possui índices globais, o Postgres não. Até agora tudo bem.

A Oracle então tem índices locais prefixados e não prefixados e a Oracle faz essa diferença, mesmo na V19: Oracle Docs

Eu realmente não entendo por que a Oracle faz essa diferença e só posso explicar isso com 'programação preguiçosa' para mim mesmo, mas essa não é a questão aqui.

Minha pergunta é: é útil no postgres prefixar um índice por outros motivos além destes óbvios:

  • Ter a chave de particionamento como prefixo no índice é útil para você, assim como a classificação no índice é útil para você
  • Ter a chave de particionamento como prefixo no índice é útil para você, pois a chave de particionamento pode ter muitos valores diferentes
postgresql
Martin Hope
Peter
Asked: 2024-04-18 15:46:46 +0800 CST
  • 6

(PG14.1) Abaixo está a saída de pg_log_backend_memory_contextsum PID para o qual pg_proctab()diz que rssé 216MB. Adicionei alguns pontos para facilitar a leitura de números grandes e anonimizei algumas coisas.

Não consigo entender:

  • Como o TopMemoryContext tem apenas 5 MB, mas o total geral é de 100 MB?
  • CacheMemoryContext tem 69 MB, mas 44 MB são gratuitos e 25 MB são usados. O que há nesses 25 MB? Não é exatamente isso que pg_log_backend_memory_contexts deveria me dizer (mas não diz)? Todas as entradas de ‘nível 2’ não chegam nem perto de 25 MB.
  • Esses 44 MB gratuitos serão devolvidos ao sistema enquanto a sessão estiver ativa?
  • Quando eu encerrar a sessão, ela liberará 216 MB de RAM (número pc_proctab) ou 100 MB (número pg_log_backend_memory_contexts) ou outro número?
logging memory contexts of PID 15744
level: 0; TopMemoryContext: 4.264.856 total in 104 blocks; 2.074.448 free (8510 chunks); 2190408 used
level: 1; pgstat TabStatusArray lookup hash table: 65536 total in 4 blocks; 4672 free (11 chunks); 60864 used
level: 1; RdsSuperUserCache: 8192 total in 1 blocks; 552 free (0 chunks); 7640 used
level: 1; PL/pgSQL function: 8192 total in 1 blocks; 3792 free (1 chunks); 4400 used: get_date_to_char(timestamp without time zone,character varying)
level: 1; PL/pgSQL function: 16384 total in 2 blocks; 7032 free (5 chunks); 9352 used: get_number_to_char(numeric,character varying)
level: 1; PL/pgSQL function: 8192 total in 1 blocks; 3824 free (3 chunks); 4368 used: get_to_number(character varying,character varying)
level: 1; PL/pgSQL function: 8192 total in 1 blocks; 4504 free (1 chunks); 3688 used: <FUNCTION>
level: 1; PL/pgSQL function: 16384 total in 2 blocks; 6616 free (4 chunks); 9768 used: <FUNCTION2>
level: 1; Sequence values: 8192 total in 1 blocks; 1576 free (0 chunks); 6616 used
level: 1; Btree proof lookup cache: 8192 total in 1 blocks; 552 free (0 chunks); 7640 used
level: 1; PL/pgSQL function: 16384 total in 2 blocks; 5752 free (5 chunks); 10632 used: get_date_interval(character varying,numeric)
level: 1; PL/pgSQL function: 32768 total in 3 blocks; 16608 free (5 chunks); 16160 used: <FUNCTION3>
level: 1; Operator lookup cache: 24576 total in 2 blocks; 10752 free (3 chunks); 13824 used
level: 1; RI compare cache: 16384 total in 2 blocks; 6656 free (3 chunks); 9728 used
level: 1; RI query cache: 8192 total in 1 blocks; 1576 free (0 chunks); 6616 used
level: 1; RI constraint cache: 40648 total in 2 blocks; 2616 free (0 chunks); 38032 used
level: 1; PL/pgSQL function: 8192 total in 1 blocks; 4592 free (1 chunks); 3600 used: get_systimestamp()
level: 1; Type information cache: 24376 total in 2 blocks; 2616 free (0 chunks); 21760 used
level: 1; PLpgSQL cast cache: 8192 total in 1 blocks; 1576 free (0 chunks); 6616 used
level: 1; PLpgSQL cast expressions: 8192 total in 1 blocks; 1576 free (0 chunks); 6616 used
level: 1; PL/pgSQL function: 16384 total in 2 blocks; 5992 free (4 chunks); 10392 used: <FUNCTION4>
level: 1; Function stat entries: 16384 total in 2 blocks; 6640 free (2 chunks); 9744 used
level: 1; CFuncHash: 8192 total in 1 blocks; 552 free (0 chunks); 7640 used
level: 1; Rendezvous variable hash: 8192 total in 1 blocks; 552 free (0 chunks); 7640 used
level: 1; PLpgSQL function hash: 24528 total in 2 blocks; 2616 free (0 chunks); 21912 used
level: 1; Prepared Queries: 16384 total in 2 blocks; 6656 free (3 chunks); 9728 used
level: 1; TableSpace cache: 8192 total in 1 blocks; 2088 free (0 chunks); 6104 used
level: 1; RowDescriptionContext: 57400 total in 3 blocks; 24272 free (7 chunks); 33128 used
level: 1; MessageContext: 8192 total in 1 blocks; 6888 free (1 chunks); 1304 used
level: 1; Operator class cache: 8192 total in 1 blocks; 552 free (0 chunks); 7640 used
level: 1; smgr relation table: 2.097.152 total in 9 blocks; 269224 free (33 chunks); 1827928 used
level: 1; TransactionAbortContext: 32768 total in 1 blocks; 32504 free (0 chunks); 264 used
level: 1; Portal hash: 8192 total in 1 blocks; 552 free (0 chunks); 7640 used
level: 1; TopPortalContext: 8192 total in 1 blocks; 7928 free (2 chunks); 264 used
level: 1; Relcache by OID: 1.048.576 total in 8 blocks; 500672 free (16 chunks); 547904 used
level: 1; CacheMemoryContext: 69.478.096 total in 208 blocks; 44.098.912 free (106056 chunks); 25.379.184 used
level: 2; CachedPlanSource: 4096 total in 3 blocks; 1960 free (1 chunks); 2136 used: <INSERT>
level: 3; unnamed prepared statement: 16384 total in 2 blocks; 6824 free (1 chunks); 9560 used
level: 2; CachedPlan: 8.420.408 total in 15 blocks; 1409824 free (1 chunks); 7010584 used: <SELECT>
level: 2; index info: 2048 total in 2 blocks; 528 free (1 chunks); 1520 used: pg_toast_295195_index
level: 2; CachedPlan: 8192 total in 4 blocks; 2480 free (0 chunks); 5712 used: <DELETE>
level: 2; index info: 2048 total in 2 blocks; 824 free (0 chunks); 1224 used: pg_sequence_seqrelid_index
level: 2; CachedPlan: 2048 total in 2 blocks; 280 free (0 chunks); 1768 used: <OTHER UNIQUE SQL>
level: 2; CachedPlan: 2048 total in 2 blocks; 528 free (0 chunks); 1520 used: <OTHER UNIQUE SQL>
level: 2; CachedPlan: 2048 total in 2 blocks; 16 free (0 chunks); 2032 used: <OTHER UNIQUE SQL>
level: 2; CachedPlan: 2048 total in 2 blocks; 160 free (1 chunks); 1888 used: <OTHER UNIQUE SQL>
level: 2; CachedPlan: 2048 total in 2 blocks; 528 free (0 chunks); 1520 used: <OTHER UNIQUE SQL>
level: 2; index info: 3072 total in 2 blocks; 696 free (1 chunks); 2376 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 824 free (0 chunks); 1224 used: <OTHER UNIQUE INDEX NAME>
level: 2; CachedExpression: 1024 total in 1 blocks; 488 free (0 chunks); 536 used
level: 2; CachedPlan: 2048 total in 2 blocks; 208 free (1 chunks); 1840 used: TO_NUMBER(p_input, p_fmt)
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 856 free (1 chunks); 2216 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 920 free (0 chunks); 1128 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3544 total in 3 blocks; 960 free (1 chunks); 2584 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 4096 total in 3 blocks; 1912 free (3 chunks); 2184 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 840 free (0 chunks); 1208 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 824 free (0 chunks); 1224 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 504 free (0 chunks); 1544 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 856 free (1 chunks); 2216 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1016 free (1 chunks); 2056 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 4024 total in 3 blocks; 816 free (1 chunks); 3208 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 7032 total in 4 blocks; 1928 free (2 chunks); 5104 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 4744 total in 3 blocks; 240 free (0 chunks); 4504 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 7032 total in 4 blocks; 1928 free (2 chunks); 5104 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3304 total in 3 blocks; 784 free (1 chunks); 2520 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1080 free (1 chunks); 1992 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3304 total in 3 blocks; 784 free (1 chunks); 2520 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 824 free (0 chunks); 1224 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 448 free (1 chunks); 1600 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 8192 total in 4 blocks; 3824 free (2 chunks); 4368 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 544 free (2 chunks); 1504 used: <OTHER UNIQUE INDEX NAME>
level: 2; CachedPlan: 2048 total in 2 blocks; 528 free (0 chunks); 1520 used: v_interval::INTERVAL
level: 2; CachedPlan: 2048 total in 2 blocks; 528 free (0 chunks); 1520 used: (v_interval IS NOT NULL)
level: 2; CachedPlan: 2048 total in 2 blocks; 144 free (1 chunks); 1904 used: v_interval := p_interval_length || ' second'
level: 2; CachedPlan: 2048 total in 2 blocks; 224 free (1 chunks); 1824 used: (p_interval = 'SECOND')
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1096 free (2 chunks); 1976 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1160 free (1 chunks); 1912 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1096 free (2 chunks); 1976 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1160 free (1 chunks); 1912 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1096 free (2 chunks); 1976 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1160 free (1 chunks); 1912 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1096 free (2 chunks); 1976 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1160 free (1 chunks); 1912 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1016 free (1 chunks); 2056 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1080 free (1 chunks); 1992 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1016 free (1 chunks); 2056 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1080 free (1 chunks); 1992 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1016 free (1 chunks); 2056 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1080 free (1 chunks); 1992 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1016 free (1 chunks); 2056 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1080 free (1 chunks); 1992 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1016 free (1 chunks); 2056 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1080 free (1 chunks); 1992 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1016 free (1 chunks); 2056 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 1; 4141 more child contexts containing 12.748.648 total in 8713 blocks; 3.899.520 free (3559 chunks); 8.849.128 used
level: 1; WAL record construction: 49768 total in 2 blocks; 6360 free (0 chunks); 43408 used
level: 1; PrivateRefCount: 8192 total in 1 blocks; 1576 free (0 chunks); 6616 used
level: 1; MdSmgr: 524.288 total in 7 blocks; 412.640 free (8661 chunks); 111648 used
level: 1; LOCALLOCK hash: 1.048.576 total in 8 blocks; 215936 free (27 chunks); 832640 used
level: 1; Timezones: 104120 total in 2 blocks; 2616 free (0 chunks); 101504 used
level: 1; ErrorContext: 8192 total in 1 blocks; 7928 free (4 chunks); 264 used
Grand total: 100.635.144 bytes in 9342 blocks; 53.175.720 free (127010 chunks); 47459424 used
postgresql
Martin Hope
Peter
Asked: 2024-04-08 14:29:14 +0800 CST
  • 5

Parece claro que definir synchronous_commit OFF em sessões - nas quais a desvantagem super rara (transações supostamente confirmadas sendo perdidas em caso de falha do servidor) - é bom, aumenta o desempenho dessas sessões, pois elas não precisam esperar pelo WAL para ser descarregado no disco.

No entanto, o que não consigo entender é como isso afeta todas as sessões que são confirmadas na mesma janela de tempo que possuem arquivos synchronous_commit ON.

Entendo que as sessões que produzem synchronous_commit OFFtanto WAL quanto aquelas que o possuem ON(ou até mais, pois realizam mais tarefas ao mesmo tempo, já que não precisam esperar pelo WALWrite). Então as sessões que possuem ONserão tão lentas como se todas as sessões tivessem ON?

Cenário 1: 10 sessões fazendo DML pesado ONe 10 sessões que o possuem OFF.

Cenário 2: 20 sessões fazendo DML pesado que possui ON.

O que eu acho que acontece: no cenário 1, as 10 sessões OFFproduzem ainda mais WAL do que no cenário 2, portanto as sessões ONaguardam ainda mais no WALWrite do que no cenário 1.

Estou entendendo certo que cada commit sempre espera que TODOS os dados WAL atuais ( xid<= own xid) sejam gravados, não apenas os dados 'ITS OWN' do WAL?

postgresql
Martin Hope
Peter
Asked: 2024-04-04 16:28:36 +0800 CST
  • 5

Estamos vendo commits aguardando excessivamente WALWritedurante determinados momentos de alta carga. Não apenas certas sessões, mas todos os commits, até mesmo o vácuo. Ao tirar fotos pg_stat_all_tables, acho que pg_statio_all_tablesfica claro que durante esses momentos específicos, onde os WALWriteeventos são tão proeminentes, a culpa é de uma mesa em particular e sua mesa de brindes. WALWriteEle recebe inserções, atualizações e exclusões pesadas durante os momentos em que há muitas esperas. 'Pesado' tanto em termos de muitas sessões (cerca de 20) quanto em termos de quantidade de dados (grandes campos de texto que são torrados).

Olhando os instantâneos dos pg_stat_walmomentos em que as esperas acontecem, posso ver que:

  • wal_recordspor segundo subiu de uma média de 2.000 para 10.000-20.000
  • wal_fpipor segundo subiu de uma média de 150 para 500-1.000
  • wal_kbytespor segundo subiu de uma média de 600 para 3.000-5.000
  • wal_writee wal_syncpor segundo subiram de uma média de 50 para 200

Os números mencionados acima indicam pg_stat_walqual é o motivo dos eventos WALWrite?

  • É o número de commits por segundo?
  • É o tamanho dos commits (em megabytes)?
  • É o número de sessões que são confirmadas ao mesmo tempo?

Se esses números não retratam uma imagem clara, como posso descobrir? Gostaria de consertar o gargalo, mas preciso identificá-lo primeiro.

Atualização nas especificações

  • PG 14.1 no AWS RDS (db.r6i.4xlarge (16 vCPU, 128 GB de RAM) com 1 réplica (db.r6i.2xlarge).
  • O tipo de armazenamento é SSD de uso geral (gp3) com IOPS provisionados de 12.000 IOPS e taxa de transferência de armazenamento de 500 MiBps.
  • SEM volume de log dedicado para PostgreSQL
  • checkpoint_timeout900
  • max_wal_size 15360
  • min_wal_size 8192
  • synchronous_standby_namesNULO
  • wal_levelréplica
  • wal_buffers64 MB
  • shared_buffers32 GB
  • wal_compressionSOBRE
  • commit_delay0
  • synchronous_commitSOBRE
postgresql
Martin Hope
Peter
Asked: 2024-03-25 21:38:35 +0800 CST
  • 5

Quais tabelas, índices etc. obtiveram E/S nos últimos 5 minutos ou na última hora etc. e quanto em termos de linhas lidas/s, linhas escritas/s bytes-lidos/s bytes escritos/s?

É uma pergunta que gostaria de poder responder. De preferência, mesmo sabendo quanto foi atendido no buffer e quanto no disco.

Existe uma visão para ver isso? Alguma maneira de descobrir?

postgresql
Martin Hope
Peter
Asked: 2024-03-13 17:06:45 +0800 CST
  • 5

Nosso fuso horário do banco de dados é UTC. Às vezes, tenho usuários que se esquecem de alterar o fuso horário da sessão para UTC e, em seguida, obtêm um comportamento indesejado (por exemplo, ao usar now()).

Existe uma maneira de

  1. Forçar todas as sessões para o fuso horário UTC?
  2. Pelo menos forçá-los uma vez ao conectar?
  3. Consulte todas as sessões, quais configurações de fuso horário elas usam? pg_stat_activitynão parece conter essa informação.

Exemplo porque timestampnão resolve todos os meus problemas:

create table a (c timestamp);
reset timezone;
show timezone; -- UTC
insert into a select now();
select * from a; -- 2024-03-13 12:50:14.515
set timezone to 'UTC+9';
show timezone; -- UTC+9
truncate a;
insert into a select now();
select * from a; -- 2024-03-13 03:50:48.376
reset timezone;
show timezone; -- UTC
select * from a; -- 2024-03-13 03:51:22.854
postgresql
Martin Hope
Peter
Asked: 2024-03-11 17:39:03 +0800 CST
  • 5

Via pg_proctab(), posso ver que as conexões da nossa aplicação podem usar até 800 MB de RAM por conexão no postgres. Geralmente até 400 MB. (Atualização para esclarecer após um comentário: essas conexões são de pools de conexões, na maioria das vezes ficam inativas, com consultas entre elas. Os 400 MB são medidos quando a conexão está inativa.)

Gostaria de investigar em que consistem esses 400 MB. Por que 400 MB e não apenas 40 MB, por exemplo? Já olhei os objetos de conexão jdbc no lado da aplicação e não encontrei nada fora do comum.

Meu palpite (maluco) seria que o alto uso de RAM vem do fato de termos muitas partições em nossas tabelas.

O postgres fornece uma maneira de examinar a RAM dos processos de conexões? Estamos no AWS RDS, então o melhor caso seria uma forma em que eu não precisasse de acesso ao servidor.

postgresql