Un program fugitiv a generat un număr mare (cel puțin un milion?) de fișiere în /var/log. Chiar și după ștergerea tuturor fișierelor (?) necinstite, orice interogare pe folder/arborele durează acum aproximativ 5 minute și poate duce la încetinirea întregului sistem.
Problema era că fișierele .gz create de logrotate erau adăugate la alte arhive .gz, iar acestea erau arhivate și... hopa. Deci, toate fișierele .gz nevalide au fost șterse din /var/log - problema sursă a fost remediată.
Cum pot afla exact ce cauzează încă întârzieri?
- În arborele /var/log există 75 de directoare cu 1606 fișiere, consumând doar 1 GB.
ls /var/log procesarea durează peste 5 minute.- Alți arbori de foldere mai mari necesită mult mai puțin timp pentru a interoga
ls, găsi, grep, etc.
copac pe /var/log durează, de asemenea, aproximativ 5 minute și rezultatul este un arbore de foldere/fișiere complet normal.df -i arată un total de 10 milioane de inoduri, mai puțin de un milion utilizate, peste 9 milioane neutilizate. Sistemul a fost repornit de mai multe ori.
Mi-ar fi bine rm -rf pe întreg arborele de jurnal urmat de o repornire. Cu mv sau cp într-un folder diferit, „unele resetare” și mutând totul înapoi, aș fi îngrijorat că aș copia problema dintr-un loc în altul.
Mă întreb dacă putem scana/curăța pentru inoduri corupte, sau poate dacă ar ajuta la reducerea numărului de inoduri la minimum și apoi să-l reporniți după o repornire.
Este o instalare simplă cu /var în singura partiție / root pentru OS/date. Deci demontarea/înlocuirea nu este o opțiune.
Pot rula cu ușurință diagnostice și pot oferi informații relevante.
Acesta este un server cloud v20.04.3 complet corecţionat. Pot deschide o consolă dacă este necesar.
e4defrag nu a arătat fragmentare. Poate alerga fsck (e2fsck sau oprire -rF) dacă acest lucru este recomandat.Acestea sunt exemple de tipuri de utilitare pe care caut să le ajut cu diagnosticarea pentru acest tip de problemă.
