Filesystem 12G, 1.3G vrij, 1.1G files --> waar is de rest??

[Verwijderd]

Dag mede-Tweakers,

Vreemd fenomeen. Nu moet ik eerst zeggen dat ik vooral een Oracle man ben en geen UNIX-specialist, dus misschien is mijn vraag perfect logisch voor jullie.

Ik heb een filesystem gemount /oracle, 12G groot. Vraag ik een du -h dan krijg ik dat er 1.3G vrij is. Doe ik een df -h in /oracle, dan krijg ik dat er 1.1G files op staat.

12G - 1.1G = ongeveer 10.9G die vrij zou moeten zijn. Dat is lang niet die 1.3G die volgens du -h vrij is, een verschil van 9G en een beetje. Waar is die naar toe?

Ik heb wel onlangs een reusachtige logfile gewist van Oracle webcache, 5G groot, als root rm -rf.

Domme vraag misschien, maar blijven gewiste bestanden ergens "hangen" tot die ruimte vrijgegeven wordt? Ik dacht toch van niet??

Hoop dat jullie licht op deze zaak kunnen werpen want de krappe ruimte op mijn /oracle begint toch problematisch te worden.

Dank!

[benoni]

Verwijderd schreef op maandag 11 oktober 2010 @ 08:37:
Domme vraag misschien, maar blijven gewiste bestanden ergens "hangen" tot die ruimte vrijgegeven wordt? Ik dacht toch van niet??

De ruimte wordt inderdaad niet vrijgemaakt zolang het bestand is geopend door een proces. Met lsof kun je dat controleren (zoek op 'lsof deleted file').

[Verwijderd]

benoni schreef op maandag 11 oktober 2010 @ 09:00:
[...]


De ruimte wordt inderdaad niet vrijgemaakt zolang het bestand is geopend door een proces. Met lsof kun je dat controleren (zoek op 'lsof deleted file').

Aha... dat zou dan betekenen dat zolang ik mijn Oracle Application Server niet reboot, de ruimte die deze logfile innam, "gereserveerd" blijft door de Application Server die nog steeds draait? (Logisch eigenlijk, als ik er eens verder over nadenk).

Ik reboot dat ding deze week eens als er eens niet te veel mensen op kantoor zijn en dan zien we wel...

Dank voor de hulp!

[ACM]

Kent die omgeving zelf geen functionaliteit om logfiles te roteren/vrij te geven? (let er trouwens op dat niet alle soorten (database)logs zomaar weggegooid mogen worden)

[Verwijderd]

even een cronjob instellen dat de desbetreffende service vanacht om 00:00 oid restart?

[RvdH]

Verwijderd schreef op maandag 11 oktober 2010 @ 09:07:
even een cronjob instellen dat de desbetreffende service vanacht om 00:00 oid restart?

Een cronjob is niet bedoeld voor eenmalige taken, daar kan je beter 'at' voor gebruiken.

[benoni]

Nu weet ik weer niets van Oracle, maar is er geen optie om logfiles regelmatig te wisselen / flushen of zo? Of kun je naast een reboot opdracht ook een reload geven (die dan zo snel zou moeten zijn dat de clients kunnen blijven draaien)?

Mmm... ben niet de enige die dat zich afvraagt

[ Voor 14% gewijzigd door benoni op 11-10-2010 09:14 ]

[Verwijderd]

ACM schreef op maandag 11 oktober 2010 @ 09:07:
Kent die omgeving zelf geen functionaliteit om logfiles te roteren/vrij te geven? (let er trouwens op dat niet alle soorten (database)logs zomaar weggegooid mogen worden)

Nee, die functionaliteit is door mijn voorganger nooit ingesteld en ik had er nog de ervaring/tijd niet voor om dat te doen.

Betreft Application Server logs, die weergeven welk IP wanneer geconnecteerd heeft en in de afgelopen 5 jaar of zo was die opgelopen tot 5GB. File ge-rm-f-fed bij acuut plaatsgebrek op /oracle en dat ding draait nog steeds OK.

benoni schreef op maandag 11 oktober 2010 @ 09:13:
Nu weet ik weer niets van Oracle, maar is er geen optie om logfiles regelmatig te wisselen / flushen of zo? Of kun je naast een reboot opdracht ook een reload geven (die dan zo snel zou moeten zijn dat de clients kunnen blijven draaien)?

Mmm... ben niet de enige die dat zich afvraagt

Dat moet zeker kunnen, en ik ga dat ook uitzoeken nu er daar problemen mee beginnen te komen, maar zoals ik reeds zei hierboven, mijn voorganger heeft dat nooit gedaan en ik had er nog de ervaring/kennis/tijd niet voor...

[ Voor 33% gewijzigd door Verwijderd op 11-10-2010 09:15 ]

[Tim]

du -h geeft juist aan hoe groot een directory is, dus het verschil is toch maar 200mb?

[Verwijderd]

Tim schreef op maandag 11 oktober 2010 @ 09:35:
du -h geeft juist aan hoe groot een directory is, dus het verschil is toch maar 200mb?

df -h geeft een filesystem /oracle van 12G, waar er 1.3G van vrij is, dus zou er een goeie 10.7 G of zoiets volzet zijn
du -h op /oracle daarentegen geeft aan dat er 1.1G files opstaan

DUS volgens df -h 10.7G volzet en volgens du -h 1.1G volzet

Ik ben eens nieuwsgierig wat er na reboot Application Server (en ik reboot ook meteen maar eens de Linux server ook) gebeurt.

[Tim]

Verwijderd schreef op maandag 11 oktober 2010 @ 09:43:
[...]
DUS volgens df -h 10.7G volzet en volgens du -h 1.1G volzet

Ah, in je startpost staat het precies andersom.

[Verwijderd]

Tim schreef op maandag 11 oktober 2010 @ 10:18:
[...]

Ah, in je startpost staat het precies andersom.

Heb ik het nu helemaal verkeerd? Komt er gewoon op neer dat volgens een df -h er een slordige 10G "verdwenen" is, maar zoals iemand eerder zei, zal die gelocked staant door processen van mijn Application Server. Als ik die es reboot zullen die normaal gezien vrijgegeven worden.

[deadinspace]

benoni schreef op maandag 11 oktober 2010 @ 09:00:
De ruimte wordt inderdaad niet vrijgemaakt zolang het bestand is geopend door een proces.

Dat is overigens ook een van de redenen dat bijvoorbeeld logrotate logfiles niet weggooit, maar truncate

Verwijderd schreef op maandag 11 oktober 2010 @ 10:51:
Heb ik het nu helemaal verkeerd?

Je schreef in de startpost:

Verwijderd schreef op maandag 11 oktober 2010 @ 08:37:
Vraag ik een du -h dan krijg ik dat er 1.3G vrij is. Doe ik een df -h in /oracle, dan krijg ik dat er 1.1G files op staat.

Het lijkt er sterk op dat je daar du en df omgedraaid hebt. Ik denk dat Tim daarop doelde.

[Verwijderd]

Servers deze middag gereboot.

Het wissen van een logfile die nog in gebruik was door Oracle (en waardoor de vrijgekomen gigabytes dus nog niet vrijgegeven waren) was inderdaad het probleem.

Van 93% vol naar 10% vol gegaan, perfect.

[Verwijderd]

Verwijderd schreef op woensdag 20 oktober 2010 @ 13:27:
Servers deze middag gereboot.

Het wissen van een logfile die nog in gebruik was door Oracle (en waardoor de vrijgekomen gigabytes dus nog niet vrijgegeven waren) was inderdaad het probleem.

Van 93% vol naar 10% vol gegaan, perfect.

Kun je Oracle niet 1x per - bijvoorbeeld - week een nieuwe logfile aan laten maken? Dan hoef je de service niet te herstarten om wat oude logging weg te gooien. Logrotation is leuk, maar niet zo handig als je je oude logging toch nog ergens zou willen bewaren.

Wij draaien trouwens nog ergens een wat oudere (5.0.nogwat) MySQL-server en hadden daar logrotation voor ingesteld. Helaas werkt die niet vanwege een bug. Oplossing: upgraden naar 5.1.x of hoger. Leuke klus. Je weet nooit wat er allemaal niet meer werkt na een upgrade van MySQL. Gaat weer een hoop tijd kosten voor een applicatie die alleen intern gebruikt wordt en ook niet van buiten benaderd kan worden.

Misschien moeten we gewoon die logrotation maar overboord gooien en kijken of we MySQL zover kunnen krijgen dat er elke week een nieuwe logfile aangemaakt wordt en de oude wordt gearchiveerd. Dan logging naar tape laten backuppen en wekelijks de gearchiveerde logfile(s) laten verwijderen ofzo.

[DikkieDick]

Ipv rm'en kan je ook cat >logfile doen. Is ie ook leeg en alloceert ie niet de 5G meer. rm'en van open files is nooit een handige optie. Ben daar zelf in het verleden ook wel eens ingetrapt. En wil je kijken of een (log)file al dan niet gebruikt wordt, kan je het commando fuser gebruiken.

Overigens kan ik me vaag herinneren dat er wel rotatelogs-scriptbestanden onder $ORACLE_HOME/Apache staan. Is mijn vrije dag dus kan het niet verfiëren. Wil dat morgen wel ff doen als ik op het werk ben. Maar wellicht kun je aan de hand van deze info er ook wel wat mee. In ieder geval is je filesysteem inmiddels een stuk leger. ;-)

[ Voor 36% gewijzigd door DikkieDick op 20-10-2010 17:02 ]

[Big Mama]

Als je een logfile leegmaakt (> logfile) of verwijdert (rm logfile), wees er dan wel zeker van dat er geen proces is dat hem geopend heeft. Want de read/write-pointer van dat proces wat hem openhoudt verandert er niet van. Dus als dat proces opnieuw gaat schrijven lijkt de logfile weer de originele grootte te hebben. Het is afhankelijk van het gebruikte filesysteem of dit laatste daadwerkelijk zo is (de meest UNIX-filesystemen ondersteunen fantoomblokken, waardoor een file wel heel groot lijkt te zijn, maar dat misschien niet is).