Basil Titus's questions

Estamos tendo esse comportamento estranho ExclusiveLockem um de nossos bancos de dados executando o PostgreSQL 13. Não consigo descobrir o que leva a esse bloqueio, pois as informações de bloqueio são de uma ferramenta de monitoramento.

Pelo que vejo nos documentos ExclusiveLockadquiridos apenas por atualização materialised view, no entanto, não temos nenhuma visualização materializada em nosso banco de dados. Um pouco de pesquisa que acabei neste blog https://blog.heroku.com/curious-case-table-locking-update-query e o caso que esse cara compartilha é semelhante ao meu, pois posso ver alguns RowExclusiveLockdurante esse período e algumas consultas atualizando a mesma linha simultaneamente. No entanto, não consegui encontrar nenhum documento oficial sobre o comportamento do PostgreSQL na escalada de bloqueio, assim como outros bancos de dados fazem.

O Postgres escala o bloqueio em casos raros? Quais casos podem levar a escalações?

Estamos realizando Citusbenchmarking e nos deparamos com uma situação onde o planejador faz o parallel execution planmas durante a execução não parallel workerssão lançados. O cluster possui 3 nós de trabalho, cada um com 2CPUs em execução no Centos. Qual pode ser a razão por trás disso?

->  Finalize Aggregate  (cost=76650.31..76650.32 rows=1 width=32) (actual time=174741.832..174741.999 rows=1 loops=1)
                 ->  Gather  (cost=76650.09..76650.30 rows=2 width=32) (actual time=174741.807..174741.974 rows=1 loops=1)
                       Workers Planned: 2
                       Workers Launched: 0
                       ->  Partial Aggregate  (cost=75650.09..75650.10 rows=1 width=32) (actual time=174740.490..174740.492 rows=1 loops=

A consulta que estamos usando para benchmarking é

select sum(amount) from tab_dist_1 where id>=49820 and id<=59743292;

Temos monitoramento de série temporal tanto pg_stat_databaseem pg_stat_statements. Recentemente, temos observado o uso de arquivos temporários em nosso banco de dados durante determinado período. Mas, para o mesmo período, não conseguimos encontrar consultas que no total correspondam ao uso total do pg_stat_database. Vimos em algum lugar operações de manutenção como vacuuminge analysepodem causar o uso de arquivos temporários, mas durante o período também não conseguimos encontrar tais atividades. Existem outras operações internas que podem causar o uso de arquivos temporários?

É possível especificar pgbouncer reserve_pool_timeoutem milissegundos, tentei especificá-lo com '500 ms', mas gerando um erro e tentei especificar 0,5, desta vez sem erro, mas não consegui descobrir que está realmente funcionando ou apenas desativei o tempo limite, mas reserve_pool está sendo utilizado .

Recentemente tivemos alto uso de CPU/memória e E/S em nosso MongoDB. Ao verificar os logs, tudo que encontrei foram alguns insertdurante esse período. Ao inspecionar os logs, notei que a maioria dos logs de inserção está bytesReadna seção de armazenamento. Portanto, suspeito que isso cause E/S e o armazenamento em cache dos dados cause muita memória.

Após o pico de inserção, a E/S e a CPU caíram, mas a memória permaneceu a mesma, o que foi resolvido após a reinicialização.

A leitura deste disco é normal com a operação de inserção? Estamos usando o Mongo v4.0 com WiredTigermecanismo de armazenamento na VM CentOS7.

2024-02-14T23:39:44.533+0800 I COMMAND  [conn939845] insert db.user_log ninserted:1 keysInserted:11 numYields:0 locks:{ Global: { acquireCount: { r: 1, w: 1 } }, Database: { acquireCount: { w: 1 } }, Collection: { acquireCount: { w: 1 } } } storage:{ data: { bytesRead: 34390, timeReadingMicros: 140837 } } 141ms
2024-02-14T23:40:16.785+0800 I COMMAND  [conn939845] insert db.user_log ninserted:1 keysInserted:11 numYields:0 locks:{ Global: { acquireCount: { r: 1, w: 1 } }, Database: { acquireCount: { w: 1 } }, Collection: { acquireCount: { w: 1 } } } storage:{ data: { bytesRead: 24150, timeReadingMicros: 506594 } } 507ms

Estamos usando o modo de arquivo de autenticação no pgbouncer. A parte de autenticação do Pgbouncer é muito confusa. Seria útil se alguém pudesse esclarecer minhas dúvidas abaixo.

• As conexões Pgbouncer são autenticadas duas vezes no lado do segurança e na camada de banco de dados?

• Qual é a utilidade da autenticação no Pgbouncer se ele estiver usando as mesmas credenciais do banco de dados ?

• É possível usar um conjunto diferente de credenciais de usuário para a autenticação Pgbouncer diferente das próprias credenciais do banco de dados?

Tenho visto muitos blogs de ajuste de desempenho do PostgreSQL e empresas como a EDB sugerindo colocar a configuração max_worker_processes do PostgreSQL para o número de CPUs na máquina.

Estamos usando uma VM PostgreSQL 13 dedicada na nuvem com 16 vCPUs . Mas a configuração padrão do Postgres max_worker_processes=8 . Baseia-se no valor padrão O que eu estava pensando O Postgres irá apenas até 8 vCPUs no máximo e o uso máximo esperado da CPU está em torno de 50% até alguns dias atrás, tivemos algum pico de conexão que na verdade estava ligado à sobrecarga de E/S, mas a CPU atingiu 95 -99% durante o pico.

Então, como max_worker_processes está relacionado à CPU? Isso terá algum impacto se eu deixar o valor padrão de 8? Ou existem outras maneiras de encontrar um valor ideal?