Toon posts:

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

Pagina: 1
Acties:

  • SteveIT
  • Registratie: juli 2007
  • Laatst online: 11-11-2014
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
  • Registratie: november 2003
  • Niet online
SteveIT 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').

  • SteveIT
  • Registratie: juli 2007
  • Laatst online: 11-11-2014
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
  • Registratie: januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

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)

Saai uitzicht in je tuin? Hang er een foto voor!


  • Attitude
  • Registratie: oktober 2008
  • Laatst online: 07-11-2010
even een cronjob instellen dat de desbetreffende service vanacht om 00:00 oid restart?

  • RvdH
  • Registratie: juni 1999
  • Laatst online: 15-08 09:45

RvdH

Uitvinder van RickRAID

Attitude 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.

twitter - keybase


  • benoni
  • Registratie: november 2003
  • Niet online
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 :P

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


  • SteveIT
  • Registratie: juli 2007
  • Laatst online: 11-11-2014
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 :P
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 SteveIT op 11-10-2010 09:15]


  • Tim
  • Registratie: mei 2000
  • Laatst online: 24-08 14:09
du -h geeft juist aan hoe groot een directory is, dus het verschil is toch maar 200mb?

  • SteveIT
  • Registratie: juli 2007
  • Laatst online: 11-11-2014
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
  • Registratie: mei 2000
  • Laatst online: 24-08 14:09
SteveIT 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.

  • SteveIT
  • Registratie: juli 2007
  • Laatst online: 11-11-2014
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
  • Registratie: juni 2001
  • Laatst online: 27-08 10:35

deadinspace

The what goes where now?

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 :)
SteveIT schreef op maandag 11 oktober 2010 @ 10:51:
Heb ik het nu helemaal verkeerd?
Je schreef in de startpost:
SteveIT 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.

  • SteveIT
  • Registratie: juli 2007
  • Laatst online: 11-11-2014
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.

  • BazzH
  • Registratie: november 2001
  • Laatst online: 18:04

BazzH

Kei-goed...

SteveIT 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.

Think smart........ Act stupid........


  • DikkieDick
  • Registratie: maart 2004
  • Laatst online: 27-08 11:19
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
  • Registratie: mei 2000
  • Laatst online: 15:13
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).

Computers follow your orders, not your intentions.

Pagina: 1


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True

Tweakers maakt gebruik van cookies

Bij het bezoeken van het forum plaatst Tweakers alleen functionele en analytische cookies voor optimalisatie en analyse om de website-ervaring te verbeteren. Op het forum worden geen trackingcookies geplaatst. Voor het bekijken van video's en grafieken van derden vragen we je toestemming, we gebruiken daarvoor externe tooling die mogelijk cookies kunnen plaatsen.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Forum cookie-instellingen

Bekijk de onderstaande instellingen en maak je keuze. Meer informatie vind je in ons cookiebeleid.

Functionele en analytische cookies

Deze cookies helpen de website zijn functies uit te voeren en zijn verplicht. Meer details

janee

    Cookies van derden

    Deze cookies kunnen geplaatst worden door derde partijen via ingesloten content en om de gebruikerservaring van de website te verbeteren. Meer details

    janee