Re: Postgres e CentOS 8

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.

Ranier Vilela