HDD Vol maar toch niet helemaal

[Blokker_1999]

Heb zonet een zeer vreemd fenomeen gehad waarvan ik niet direct begrijp wat er gebeurd is.

Mijn MySQL server (dit is een KVM virtuele machine) kwam ineens met volgende melding af op client systemen:

HY000 SQLSTATE[HY000]: General error: 1030 Got error 28 from storage engine

Even snel op Google kijken leerde me dat dit een indicatie kan zijn dat de harde schijf volstaat. Dit leek mij vreemd aangezien de HDD 200GB is en alle databases samen slechts enkele GB groot zijn. Maar inderdaad, een df toonde aan dat er geen ruimte meer was:

root@watt:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       197G  187G     0 100% /
udev             10M     0   10M   0% /dev
tmpfs           794M   25M  769M   4% /run
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup

Ik ging dus even op zoek naar de schuldige en dacht dat er misschien nog wat logging aan stond waardoor er in /var toch wat ruimte moest verbruikt zijn. Evenwel

root@watt:/var# du -sh .
14G     .

Maar als het niet in /var zit ... waar dan wel? Verbruikt het rootfs echt zo veel?

root@watt:/# du -sh .
du: cannot access ‘./proc/17071/task/17071/fd/4’: No such file or directory
du: cannot access ‘./proc/17071/task/17071/fdinfo/4’: No such file or directory
du: cannot access ‘./proc/17071/fd/4’: No such file or directory
du: cannot access ‘./proc/17071/fdinfo/4’: No such file or directory
15G     .

Op dat moment kan ik niet meer volgen wat er gebeurd. Ik heb dan een risico genomen (omdat dit toch een vrij belangrijk systeem is) en de machine herstart en na een herstart:

root@watt:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       197G   15G  173G   8% /
udev             10M     0   10M   0% /dev
tmpfs           794M  8.3M  785M   2% /run
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           5.0M  8.0K  5.0M   1% /run/lock
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup

Iemand die mij in de goede richting kan zetten van wat hier mogelijks gebeurd is? En waar ik eens snel naar kan kijken mocht dit zich opnieuw voordoen?

[BoAC]

Dat probleem heb ik eerder gehad met een systeem waar een buggy applicatie op draaide die bestanden verwijderde die nog open stonden. Kijk eens naar open bestanden die verwijderd zijn maar dus nog open staan. Commando: lsof. Let wel op dat je voldoende rechten moet hebben omdat je anders niet alle bestanden kunt zien

Wat is trouwens het filesystem wat je gebruikt op die drive?

Ow en die fout die je krijgt op /proc/17071/* kun je negeren, dat is van een proces wat ondertussen weer verwijderd is

[ Voor 22% gewijzigd door BoAC op 13-07-2016 08:10 ]

[Blokker_1999]

Het bestandssysteem is EXT4

Indien ik de komende dagen het probleem terug zie opdagen (al verwacht ik dat het een traag process zal zijn dat over maanden de schijf doet vollopen) zal ik zeker eens met lsof kijken (had daar eigenlijk zelf al aan moeten denken, stupid me).

[Cyphax]

Als je iets meer wilt nagaan wat er hoeveel ruimte gebruikt, dan is ncdu een handig tooltje. Soort treesize maar dan voor de cli.

[BoAC]

Cyphax schreef op woensdag 13 juli 2016 @ 08:46:
Als je iets meer wilt nagaan wat er hoeveel ruimte gebruikt, dan is ncdu een handig tooltje. Soort treesize maar dan voor de cli.

Maar die zal geen verwijderde bestanden tonen die nog open staan verwacht ik en de du toonde netjes de 15G die na herstart gewoon in gebruik is

[ Voor 8% gewijzigd door BoAC op 13-07-2016 09:07 ]

[Hero of Time]

Gewoon lsof gebruiken en zoeken op 'deleted'. Simpelweg dit:

# lsof | grep deleted

En dan krijg je het command, PID e.d. terug wat welke bestanden open houd die eigenlijk verwijdert zijn. Een herstart van die service en je hebt je schijfruimte weer terug.

[BoAC]

Klopt inderdaad, zo deed ik dat ook

[Blokker_1999]

Wel, van wat ik de afgelopen uren heb zien gebeuren op die server en van wat ik terugvind op internet hebben we mogelijks last van een bug in MySQL. lsof geeft nu al weer 165 open maar verwijderde bestanden weer, allen van MySQL. Voorlopig nog optimistisch blijven en hopen dat dit een traag process over meerdere maanden is geweest waardoor ik wat tijd heb op de rustige dagen om dit beter te onderzoeken.

[BoAC]

Blokker_1999 schreef op woensdag 13 juli 2016 @ 14:41:
Wel, van wat ik de afgelopen uren heb zien gebeuren op die server en van wat ik terugvind op internet hebben we mogelijks last van een bug in MySQL. lsof geeft nu al weer 165 open maar verwijderde bestanden weer, allen van MySQL. Voorlopig nog optimistisch blijven en hopen dat dit een traag process over meerdere maanden is geweest waardoor ik wat tijd heb op de rustige dagen om dit beter te onderzoeken.

Ik heb er ook 150 staan van MySQL maar nu wordt mijn server niet zo intensief gebruikt, dus dat zegt niet zoveel. Heb je wel je server up-to-date?

[_eXistenZ_]

Upgraden naar Mariadb een optie? Hun bug tracker is tenminste open voor niet-betalende gebruikers dus ik heb daar meer vertrouwen in...

[ Voor 87% gewijzigd door _eXistenZ_ op 19-07-2016 08:27 ]