Re: Postgres e CentOS 8

Em qua., 3 de jun. de 2020 às 11:45, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
escreveu:

> Em qua., 3 de jun. de 2020 às 11:34, André Ormenese <aormenese(at)gmail(dot)com>
> escreveu:
>
>>
>> Em qua., 3 de jun. de 2020 às 10:22, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
>> escreveu:
>>
>>> Em qua., 3 de jun. de 2020 às 09:10, André Ormenese <aormenese(at)gmail(dot)com>
>>> escreveu:
>>>
>>>>
>>>>
>>>> Em ter., 2 de jun. de 2020 às 21:40, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
>>>> escreveu:
>>>>
>>>>> Em seg., 1 de jun. de 2020 às 18:10, André Ormenese <
>>>>> aormenese(at)gmail(dot)com> escreveu:
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Em seg., 1 de jun. de 2020 às 16:58, Leandro Guimarães Faria Corcete
>>>>>> DUTRA <l(at)dutras(dot)org> escreveu:
>>>>>>
>>>>>>> Le lundi 01 juin 2020 à 12:58 -0300, André Ormenese a écrit :
>>>>>>> > Vou responder os questionamentos todos aqui ....
>>>>>>>
>>>>>>> Mas não foi o que fizeste, explico.
>>>>>>>
>>>>>>>
>>>>>>> > Como é uma máquina de produção, já fiz o reboot, então não tenho
>>>>>>> como
>>>>>>> > enviar top, htop e demais comandos.
>>>>>>>
>>>>>>> Sugiro deixar um [h]top ao menos rodando para capturar o problema.
>>>>>>>
>>>>>> Ok !!!
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> > Reiniciar o serviço do Postgres resolve por pouco tempo. Mesmo
>>>>>>> > fazendo isso o uso de CPU não volta aos padrões de utilização da
>>>>>>> > máquina, e logo em seguida sobe acima dos 80%.
>>>>>>>
>>>>>>> O que indicaria um problema do CentOS. Só para descartar um eventual
>>>>>>> problema do núcleo do sistema, eu sugeriria um telinit 1 da próxima
>>>>>>> vez
>>>>>>
>>>>>> Ok !!!
>>>>>>
>>>>>>> .
>>>>>>>
>>>>>>>
>>>>>>> > Os processos que aumentam o consumo da CPU, são processos do
>>>>>>> > Postgres, que acabam demorando muito para rodar e vão se
>>>>>>> acumulando.
>>>>>>>
>>>>>>> ¿Mas quais?
>>>>>>>
>>>>>> Processos gerados quando se executa um select. Como esse abaixo
>>>>>> gerado através de um select no pgadmin.
>>>>>>
>>>>>> PID USER PR NI VIRT RES SHR S %CPU %MEM
>>>>>> TIME+ COMMAND
>>>>>> 24913 postgres 20 0 20,5g 234108 231492 R 60,9 0,4 0:13.07
>>>>>> postmaster
>>>>>>
>>>>>> Mas não é só o banco que fica lento. A máquina como um todo, senta.
>>>>>>
>>>>> Não sei ao certo, mas me parece um problema de bloqueio pendente (race
>>>>> condition)?
>>>>> Teria como você fazer um EXPLAIN da (s) queries que estão travadas?
>>>>> e postar?
>>>>>
>>>>
>>>> Ranier,
>>>> obrigado pela atenção, mas o problema não está diretamente no banco, e
>>>> sim no conjunto da obra.
>>>>
>>>> As queries (todas) rodam sem problemas quando a máquina está ok. E ela
>>>> fica ok por 3...4.. meses.
>>>>
>>> Eu entendi, que o problema ocorre após algum tempo. E pelo que você
>>> reportou, o problema é o Postgres.
>>> Então, algo acontece na máquina, que provoca o problema.
>>> Como disse o colega, são inúmeros os problemas que podem estar
>>> acontecendo.
>>> Alguns tolos, outros mais sérios e difíceis de descobrir.
>>> Como por exemplo, o Postgres pode estar indo pro disco, por algum motivo.
>>> Então quando a máquina estiver lenta, seria o caso de se investigar com
>>> explain, para tentar
>>> verificar o que está acontecendo.
>>> Existe também, algumas instruções sql, que podem ser usadas para se
>>> recuperar informações
>>> das estruturas internas do banco, que poderiam ajudar.
>>>
>>> Ranier Vilela
>>>
>>
>> Pessoal, eu entendo a necessidade das informações do estado da máquina no
>> momento que o problema está acontecendo, porém este cluster suporta
>> sistemas médicos de alta criticidade, 24 x 7, por isso tentei solucionar o
>> problema o mais rápido possível, e a coleta de informações ficou
>> prejudicada.
>>
>> Vou deixar alguns scripts prontos para disparar quando o problema
>> acontecer novamente.
>>
>> Agradeço a ajuda de todos !!!
>>
>> Ranier, quais informações da estrutura interna do banco seriam
>> interessantes recuperar ?
>>
> Principalmente as informações relacionadas aos status dos "locks", não
> tenho tais sqls, fácil nesse momento,
> mas nas minhas pesquisas já me deparei com algumas.
> Postgres registra várias status em tabelas internas, que podem ser
> recuperadas por meio de selects.
>
Aqui está um exemplo, dos recursos que o Postgres têm que podem ajudá-lo a
investigar a causa da lentidão.

1. pg_safe_snapshot_blocking_pids(int)
https://www.postgresql.org/docs/12/functions-info.html
2. https://wiki.postgresql.org/wiki/Lock_Monitoring
3. https://wiki.postgresql.org/wiki/Monitoring
4. https://wiki.postgresql.org/wiki/Show_database_bloat

Vaccum também pode "sentar" servidor, ao ser executado fora de hora.

Ranier Vilela