Ik was een beetje aan het rommelen om DNZM toch eens daadwerkelijk te verhuizen naar mijn thuis-servert -- nee, dat is nog steeds niet gebeurd -- alleen... Het ding liep iedere keer schijfruimtetechnisch vol. Gisteravond nog wat spul eraf gegooid, 5 of 6 GB vrij, en vanmorgen was het weer vol. Raar. Eigenlijk was die 5 à 6 GB al aan de vrij lage kant; er zit "maar" een 40 GB schijf in, maar voor een simpel servertje zou je daar meer dan genoeg aan moeten hebben.
Na wat rondgepord te hebben met du
kwam ik erachter dat de bulk van alle verbruik in /tmp
zat. Eén ls
later zat ik, hardop facepalmend, te wachten tot het probleem opgelost was. Zoals wel vaker vond ook dit probleem zijn oorsprong tussen de stoel en het toetsenbord...
Xdebug
Een paar maanden geleden ontdekte ik [Xdebug](), een extensie voor PHP die het debuggen makkelijker maakt. Eén van de mogelijkheden van Xdebug is het genereren van een profiel van een draaiend PHP-script, door een bestand op te slaan met wat informatie over welke functies werden uitgevoerd, en hoe vaak, en hoe lang dat duurde. Vrij handig als je een app aan het ontwikkelen bent en je wilt weten waar eventuele bottlenecks zitten.
Het nadeel ervan is dat het, op een server die de hele dag door allerlei PHP-script staat uit te voeren, de hele dag bestanden genereert, soms nog vrij grote bestanden ook. U ziet vast al waar dit heen gaat?
Ik heb blijkbaar die automatische traces een keer aangezet en er nooit meer bij stilgestaan.
Honderdmiljoenmiljard bestanden weggooien later was er volgens df
weer zo'n 6 GB vrij. Mooi, zou je zeggen, ware het niet dat du
vertelde dat er op de hele schijf (van 40 GB, dus) maar iets van 4.5 GB in gebruik was. 40 - 4.5 is, volgens mijn beperkte hoofdrekenkunsten, iets meer dan 6. Er was dus nog iets aan de hand.
Over du
en df
en in gebruik zijnde bestanden
Uit een klein stukje googlen werd duidelijk dat df
en du
verschillend kunnen denken over de hoeveelheid verbruikte ruimte, als er nog bestanden open staan. Dat bleek het geval; er draait op het systeem een PHP-script als daemon (in tegenstelling tot een vanaf de webserver opgeroepen script bleef het dus full-time doordraaien) en, uiteraard, dat script werd door Xdebug geprofileerd, en dat script had dus een -- episch grote -- file openstaan.
Script gestopt, en even later waren du
en dh
het eens over hoe het met de vrije ruimte was gesteld: 30GB vrij.
Lessen geleerd
- Op een (semi-)productiemachine moet je voorzichtig zijn met profiling, en zeker met automatische profiling
- Als je home directory niet de grootste verbruiker is, wordt het tijd om naar
/var
en/tmp
te kijken - Als je na uitgebreide wis-acties een verschil tussen
du
endf
ziet, wordt het tijd om metlsof | grep 'deleted'
te kijken of er nog ergens (grote) bestanden open staan die al verwijderd zijn.