Executando verificação de segurança...
2

O artigo ficou legal, mas se me permite acrescentar duas observações (2 cents como o Oletros diz hahaha):

prontamento retornou os arquivos principais do banco de dados

Você mencionou que seu comando apontou o banco de dados como maior consumidor. Minha sugestão é analisar quais bases e tabelas estão ocupando o maior espaço.

Na maioria das vezes, clientes deixam logs e registros sem necessidade alguma residindo em alguma tabela sem nunca realizar uma limpezinha.

E quando for fazer tal análise, utilize a CLI da base de dados. Por exemplo, no MySQL/MariaDB, você possui a information_schema que guarda uma porção de estatísticas úteis pra investigar situações assim.

rm -rf /tmp/* /var/tmp/*

Outra coisa que você mencionou foi remover o tmp.

Cuidado com as sugestões do ChatGPT. Elas são valiosas, mas você não pode sair executando à risca tudo que ele sugere sem antes se questionar só um pouquinho.

Por exemplo, você poderia ter removido um arquivo temporário que o MySQL estivesse usando para uma query longa e que estava retornando muitos dados. Sem uma análise mais precisa, você só estaria causando um problema diferente e que provavelmente voltaria assim que o cliente conectado ao MySQL executasse a query novamente.

Você também poderia ter invalidado todas as sessões que uma aplicação php estivesse usando. Se fosse um ecommerce, por exemplo, tchau pros carrinhos das pessoas que estivessem há 30 minutos num site fazendo compras hahahah

Carregando publicação patrocinada...
1

MySQL/MariaDB, você possui a information_schema que guarda uma porção de estatísticas úteis pra investigar situações assim.

Isso me lembra que eu esqueci ligado o performance_schema do Mysql em um servidor. A base inteira estava usando uns 7GB, e o performance_schema chegando em quase 30GB