Re: Postgres e CentOS 8

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 ?