Înființat
- Ubuntu 20.04
- Dell PowerEdge R820
- [PERC H710] 2x unități virtuale (RAID-1 Boot, RAID-0 Work Drive)
- Totul a fost bine de 6 luni
- Nici măcar fără precedent, doar brusc, conduceți plin.
Detalii...
Această mașină este folosită pentru a trasa Chia (criptomonedă) - funcționează de luni de zile fără probleme.
Am observat că procesul de plotare s-a prăbușit (bladebit) - ceea ce este destul de neobișnuit, se întâmplă poate o dată la 2 luni - așa că m-am dus să-l pornesc și am început imediat să primesc aparat plin tipuri de erori.
Am tras o rapidă df -h pentru a vedea ce se întâmplă și am primit asta:
Filesystem Size Used Avail Use% Montat pe
udev 252G 0 252G 0% /dev
tmpfs 51G 2,9M 51G 1% /run
/dev/sda2 549G 512G 8,7G 99% /
tmpfs 252G 4.0K 252G 1% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 252G 0 252G 0% /sys/fs/cgroup
/dev/sda1 511M 5,3M 506M 2% /boot/efi
tmpfs 51G 0 51G 0% /run/user/1000
<... SNIP ...>
/dev/sda2 este unitatea de pornire - este de fapt un disc virtual RAID-1 (2-disk) gestionat de placa RAID H710 de pe server, dar nu cred că este teribil de relevant.
ÎN MOD NORMAL această unitate este plină cu 3%, are instalat doar Ubuntu Server 20.04 bootabil și nimic altceva.
A trebuit să șterg fișierul tmp din root și alte câteva fișiere gunoi pentru a elibera spațiu suficient pentru ca lucrurile să funcționeze din nou, dar este aproape plin.
Am urmat nenumărate sfaturi „găsește cel mai mare fișier de pe serverul tău” de aici și de pe web, de exemplu Aceasta, cu comanda sudo du -a / 2>/dev/null | sortare -n -r | cap -n 20 revenind:
$ sudo du -a / 2>/dev/null | sortare -n -r | cap -n 20
[sudo] parola pentru utilizator:
1010830919685 /
1010823681740 /mnt
<<... SNIP...>
Ok, așa că ceva uriaș stau înăuntru / aparent? Un simplu ls nu arată nimic interesant acolo:
$ ls -lFa /
total 84
drwxr-xr-x 20 rădăcină rădăcină 4096 12 ianuarie 17:45 ./
drwxr-xr-x 20 rădăcină rădăcină 4096 12 ianuarie 17:45 ../
lrwxrwxrwx 1 root root 7 Aug 24 08:41 bin -> usr/bin/
drwxr-xr-x 4 root root 4096 6 ianuarie 06:22 boot/
drwxr-xr-x 2 root root 4096 28 septembrie 14:04 cdrom/
drwxr-xr-x 21 root root 6920 5 ianuarie 16:05 dev/
drwxr-xr-x 105 root root 4096 5 ianuarie 01:54 etc/
drwxr-xr-x 3 root root 4096 28 septembrie 14:18 home/
lrwxrwxrwx 1 root root 7 august 24 08:41 lib -> usr/lib/
lrwxrwxrwx 1 root root 9 august 24 08:41 lib32 -> usr/lib32/
lrwxrwxrwx 1 root root 9 august 24 08:41 lib64 -> usr/lib64/
lrwxrwxrwx 1 root root 10 august 24 08:41 libx32 -> usr/libx32/
drwx------ 2 root root 16384 28 septembrie 14:03 pierdut+găsit/
drwxr-xr-x 2 root root 4096 24 august 08:42 media/
-rw-r--r-- 1 rădăcină rădăcină 6678 9 ianuarie 00:59 MegaSAS.log
drwxr-xr-x 64 root root 4096 5 ianuarie 01:48 mnt/
drwxr-xr-x 3 root root 4096 30 noiembrie 18:14 opt/
dr-xr-xr-x 1356 root root 0 3 ian 04:40 proc/
drwx------ 7 root root 4096 Nov 30 18:07 root/
drwxr-xr-x 34 root root 1100 12 ianuarie 08:04 rulare/
lrwxrwxrwx 1 root root 8 Aug 24 08:41 sbin -> usr/sbin/
drwxr-xr-x 9 root root 4096 28 septembrie 22:06 snap/
drwxr-xr-x 2 root root 4096 24 august 08:42 srv/
dr-xr-xr-x 13 root root 0 3 ian 04:40 sys/
drwxrwxrwt 13 rădăcină rădăcină 4096 12 ianuarie 17:15 tmp/
drwxr-xr-x 15 root root 4096 24 august 08:46 usr/
drwxr-xr-x 13 rădăcină rădăcină 4096 24 august 08:47 var/
Folosind sudo ncdu -x / (legătură) nu arată nimic destul de ciudat de interesant:
2.4 GiB [##########] /usr
1,5 GiB [###### ] /var
732,5 MiB [## ] /acasă
202,8 MiB [ ] /boot
5,5 MiB [ ] /opt
5,4 MiB [ ] /etc
1,9 MiB [ ] /rădăcină
168,0 KiB [ ] /tmp
<<... SNIP...>
Unde se află acest ~510 GB de spațiu folosit?
Tragerea a sudo lsof | grep a fost șters pentru a vedea dacă există vreun fișier uriaș reținut, mi-a dat asta:
systemd-j 1134 root 36u REG 8,2 134217728 5246838 /var/log/journal/771d7f1addf64a7b930191976176149e/system@ae2f8b2397c441f7a286d25144be755f-0000000000315312-0005d4e51ab8f8e9.journal (deleted)
unattende 3932 root 3w REG 8,2 113 5246631 /var/log/unattended-upgrades/unattended-upgrades-shutdown.log.1 (șters)
unattende 3932 3943 gmain root 3w REG 8,2 113 5246631 /var/log/unattended-upgrades/unattended-upgrades-shutdown.log.1 (șters)
Ok, deci păstrează un fișier jurnal de 134 MB, dar asta încă nu explică de ce dintr-o dată sunt ocupați 510 GB de unitate.
Am încercat și câteva căutări suplimentare, de exemplu Aceasta, și nici nu a rezultat în nimic util.
Am folosit pana la urma megacli pentru a verifica datele SMART de pe cele 2 unități din matricea RAID-0 și au 0 erori raportate, așa că nu pare că matricea a fost deteriorată.
Vreo idee sau trucuri suplimentare pe care aș putea încerca să-mi dau seama ce absorb acel spațiu?
ACTUALIZARE #1 - Am observat când am tastat top acea buff/cache era aproape exact de dimensiunea GB-urilor care erau consumate pe unitatea rădăcină. Știu că spațiul nu este luat în considerare folosit, dar am decis să trag o scurtă:
sudo sh -c „/usr/bin/echo 3 > /proc/sys/vm/drop_caches”
care a durat aproximativ 3 minute, dar în cele din urmă s-a întors - top acum arată buff/cache ca < 1k, DAR df -h nu arată nicio modificare în utilizarea discului.
Am sperat că este un fișier cache misterios pe disc sau ceva de genul ăsta.
