Linux exclude folder from file cache

[Verwijderd]

Hoi,

Ik heb een vraag mbt. Linux waar ik weinig tot geen verstand van heb. Ik zit met het volgende:

Een collega van mij beheerd een Linux fileserver die wij gebruiken om files vanaf te halen met onze Windows 2008 R2 IIS webbservers. De laatste tijd komen de files steeds trager van de fileserver waardoor onze sites soms behoorlijk traag gaan. Nu is dit voglens mijn collega omdat de fileserver constant aan het swappen is. Nu is het zo dat er vanaf deze fileserver ook films voor ons VOD gehost worden wat het swappen tot gevolg heeft.

Nu wil ik de VOD folders excluden zodat deze folders niet meer in het geheugen gecached worden. Is dit mogelijk en zo ja is er een online document waar dit beschreven wordt zodat ik hiernaar kan verwijzen aangezien hij zegt "kan niet".

[Kees]

Nee, dat kan ook niet.

Als je last hebt van een swappende fileserver zou je wel de swapiness omlaag kunnen zetten, dan zal hij minder snel swappen, en eerder de cache hergebruiken. En eens kijken naar wat er precies geheugen gebruikt, en dat eventueel uitzetten. Dingen als een GUI zijn op een server behoorlijk overbodig. En je zou ook kunnen kijken naar een betere caching op de webservers zelf, zodat ze niet elke file elke keer van de fileserver ophalen.

[ Voor 17% gewijzigd door Kees op 29-07-2010 13:46 ]

[Verwijderd]

Kees schreef op donderdag 29 juli 2010 @ 13:46:
Nee, dat kan ook niet.

Als je last hebt van een swappende fileserver zou je wel de swapiness omlaag kunnen zetten, dan zal hij minder snel swappen, en eerder de cache hergebruiken. En eens kijken naar wat er precies geheugen gebruikt, en dat eventueel uitzetten. Dingen als een GUI zijn op een server behoorlijk overbodig. En je zou ook kunnen kijken naar een betere caching op de webservers zelf, zodat ze niet elke file elke keer van de fileserver ophalen.

Het geheugen wordt gebruikt door de films die voor het VOD vanaf deze fileserver wordt gehaald. Voordat de files voor het VOD van de fileserver gehaald werden ging alles goed. Caching in de Flash Media Server die server files voor het VOD van de fileserver haalt is een lastig verhaal. De fileserver zelf is naar mijn idee wel goed geconfigureerd en hier valt weinig in te verbeteren. Het geheugen verhogen van 4GB naar bv 8GB heeft dus weinig zin omdat de grote VOD files elke keer in het geheugen geplaatst worden of heb ik dat verkeerd?

[Kees]

Verwijderd schreef op donderdag 29 juli 2010 @ 13:56:
[...]


Het geheugen wordt gebruikt door de films die voor het VOD vanaf deze fileserver wordt gehaald. Voordat de files voor het VOD van de fileserver gehaald werden ging alles goed. Caching in de Flash Media Server die server files voor het VOD van de fileserver haalt is een lastig verhaal. De fileserver zelf is naar mijn idee wel goed geconfigureerd en hier valt weinig in te verbeteren. Het geheugen verhogen van 4GB naar bv 8GB heeft dus weinig zin omdat de grote VOD files elke keer in het geheugen geplaatst worden of heb ik dat verkeerd?

Geheugen bijplaatsen heeft altijd zin, geheugen is goedkoop, en meer geheugen is goed

Maar een OS leest normaal gegesproken een file in van de disk, naar het geheugen, en dan verder via het netwerk, tenzij je directio gebruikt. Maar daar zou hij niet van mogen gaan swappen. Als hij dat wel doet, dan staan er parameters verkeerd, want als er swap is, dan zal linux die swap gebruiken om pages die langere tijd in het geheugen staan weg te schrijven, en op die manier meer geheugen beschikbaar te hebben. Linux zal echter nooit de filecache gaan swappen (dat is nogal dubbelop). Als je collega zegt dat de fileserver loopt te swappen, dan is er iets wat geheugen opvreet, en dat is niet de cache, want cache is geheugen dat vrijgegeven wordt zodra dat nodig is, en het kan ook zo 'weggegooit' worden (want het staat toch al op de disk).

Als een file niet in het geheugen staat, dan zal hij dus een stukje geheugen vrij moeten maken, de file inlezen, en vervolgens overpompen naar de fileservers. Je geheugen kan dus het beste een grootte hebben van je workingset, dan is de server het snelste, anders is hij maar zo snel als de disks in die fileserver (en bij heel veel random access en geen SSD's kan dat best langzaam zijn als je veel IOops hebt).

Magoed, begin eens met 'echo 10 > /proc/sys/vm/swappiness', en bekijk de output van top/ps auxfww/vmstat 1 om te zien of daar nog iets valt te halen. Mocht daar niets te halen zijn, kijk dan eens of er budget is om de 'video' en 'scripts(?)/documenten' server te scheiden.

Wat wij hier bij tweakers doen is de 'webscripts' en 'layoutelementen' lokaal op de webservers opslaan (en dmv rsync te syncen als we iets veranderen), en de video's usercontent etc staat op een fileserver (met opensolaris/zfs, 24G geheugen, en een paar SSD's als cache).

[CAPSLOCK2000]

Ik vind het maar een vreemd verhaal. Tenzij iemand de swappiness veel te ver omhoog heeft gezet zou een fileserver nooit moeten gaan swappen. Zelfs als ie gaat swappen zouden filetransfers die eenmaal begonnen zijn niet veel langzamer moeten zijn, dat data komt immers van dezelfde disk.
Is die server niet gewoon overbelast?
Je laat het ding meer werk doen (VOD is er bij gekomen) en de boel wordt langzamer, simpel lijkt me.

Post eens de uitvoer van het "free" commando die wordt namelijk nogal vaak verkeerd begrepen.
Hoeveel schijven zitten er in de server en hoeveel files worden er tegelijkertijd gelezen?

[Verwijderd]

Kees schreef op donderdag 29 juli 2010 @ 14:21:
[...]

Geheugen bijplaatsen heeft altijd zin, geheugen is goedkoop, en meer geheugen is goed

Maar een OS leest normaal gegesproken een file in van de disk, naar het geheugen, en dan verder via het netwerk, tenzij je directio gebruikt. Maar daar zou hij niet van mogen gaan swappen. Als hij dat wel doet, dan staan er parameters verkeerd, want als er swap is, dan zal linux die swap gebruiken om pages die langere tijd in het geheugen staan weg te schrijven, en op die manier meer geheugen beschikbaar te hebben. Linux zal echter nooit de filecache gaan swappen (dat is nogal dubbelop). Als je collega zegt dat de fileserver loopt te swappen, dan is er iets wat geheugen opvreet, en dat is niet de cache, want cache is geheugen dat vrijgegeven wordt zodra dat nodig is, en het kan ook zo 'weggegooit' worden (want het staat toch al op de disk).

Als een file niet in het geheugen staat, dan zal hij dus een stukje geheugen vrij moeten maken, de file inlezen, en vervolgens overpompen naar de fileservers. Je geheugen kan dus het beste een grootte hebben van je workingset, dan is de server het snelste, anders is hij maar zo snel als de disks in die fileserver (en bij heel veel random access en geen SSD's kan dat best langzaam zijn als je veel IOops hebt).

Magoed, begin eens met 'echo 10 > /proc/sys/vm/swappiness', en bekijk de output van top/ps auxfww/vmstat 1 om te zien of daar nog iets valt te halen. Mocht daar niets te halen zijn, kijk dan eens of er budget is om de 'video' en 'scripts(?)/documenten' server te scheiden.

Wat wij hier bij tweakers doen is de 'webscripts' en 'layoutelementen' lokaal op de webservers opslaan (en dmv rsync te syncen als we iets veranderen), en de video's usercontent etc staat op een fileserver (met opensolaris/zfs, 24G geheugen, en een paar SSD's als cache).

Mijn dank is groot!

Nu komt hij met iets andere info:S

"in linux loopt elke schijfactie via het geheugen het grootste gedeelte van het geheugen zal dan ook schijfinformatie bevatten maak als er meer files regelmatig worden opgevraagd dan er geheugen aanwezig is dan moet de data daadwerkelijk van de schijf worden gehaald en in het geheugen worden gezet, hetgeen dan weer inhoud dat er een andere file uit het geheugen wordt gegooid etc,etc,etc

kortom, op dit moment is de fileserver de meeste tijd bezig met files (zo'n 300GB in totaal wat gebruikt wordt) van schijf halen"

Hieruit en uit jou verhaal maak ik op dat wanneer bv. video1 van 1GB wordt opgevraagd maar video's 2,3,4,5 (allen van 1GB) al in het geheugen van 4GB staat hij eerst video 2, 3, 4 of 5 moet verwijderen alvorens video 1 geserveerd kan worden... klopt dit?

Er zitten 16 schijven (146GB 15K SCSI) in raid 5 in de fileserver en er wordt in totaal ongeveer 300GB aan files geserveerd waarvan ongeveer 280GB aan video voor het VOD is.

Is er een mogelijkheid om met de huidige server het probleem op te lossen of moet er echt andere hardware in/nieuwe fileserver voor het VOD? Ik heb al voor een aantal (voor ons) high traffic sites (7000-25000 unieke per dag) de files op de lokale webservers gezet alleen is dit niet echt de beste oplossing aangezien die applicaties ook bestanden wegschrijven die later weer opgevraagd moeten worden door de applicaties.

[Verwijderd]

CAPSLOCK2000 schreef op donderdag 29 juli 2010 @ 14:23:
Ik vind het maar een vreemd verhaal. Tenzij iemand de swappiness veel te ver omhoog heeft gezet zou een fileserver nooit moeten gaan swappen. Zelfs als ie gaat swappen zouden filetransfers die eenmaal begonnen zijn niet veel langzamer moeten zijn, dat data komt immers van dezelfde disk.
Is die server niet gewoon overbelast?
Je laat het ding meer werk doen (VOD is er bij gekomen) en de boel wordt langzamer, simpel lijkt me.

Post eens de uitvoer van het "free" commando die wordt namelijk nogal vaak verkeerd begrepen.
Hoeveel schijven zitten er in de server en hoeveel files worden er tegelijkertijd gelezen?

Ik denk niet dat die server overbelast is (dit is ook niet wat mijn collega zegt)... de load op die VOD is nog erg laag. Ik beheer deze server helaas niet zelf en kan geen commando's uitvoeren en mijn collega is niet erg meewerkend.

Er zitten 16 schijven (146GB 15K SCSI) in raid 5 in die server en er wordt ongeveer 300GB aan files vanaf die server geserveerd waarvan ongeveer 280GB aan video's.

[Rainmaker]

Maar dan nog; files van schijven richting netwerk pompen is "makkelijk".

Lijkt me dat een beetje server dat er wel doorheen gestouwd krijgt. Of wordt er nog een encodering tussendoor overheen gehaald? Want anders zie ik echt niet in hoe dat ding kan gaan swappen...

Je zou eens kunnen kijken met

code:

ps -eo pid,comm,rss,vsize | sort -n -k 3

hoeveel geheugen welk proces inneemt. Maar dan moet je wel een shell hebben (geen root).

[Kees]

Verwijderd schreef op donderdag 29 juli 2010 @ 17:27:
[...]


Mijn dank is groot!

Nu komt hij met iets andere info:S

"in linux loopt elke schijfactie via het geheugen het grootste gedeelte van het geheugen zal dan ook schijfinformatie bevatten maak als er meer files regelmatig worden opgevraagd dan er geheugen aanwezig is dan moet de data daadwerkelijk van de schijf worden gehaald en in het geheugen worden gezet, hetgeen dan weer inhoud dat er een andere file uit het geheugen wordt gegooid etc,etc,etc

kortom, op dit moment is de fileserver de meeste tijd bezig met files (zo'n 300GB in totaal wat gebruikt wordt) van schijf halen"

Hieruit en uit jou verhaal maak ik op dat wanneer bv. video1 van 1GB wordt opgevraagd maar video's 2,3,4,5 (allen van 1GB) al in het geheugen van 4GB staat hij eerst video 2, 3, 4 of 5 moet verwijderen alvorens video 1 geserveerd kan worden... klopt dit?

Er zitten 16 schijven (146GB 15K SCSI) in raid 5 in de fileserver en er wordt in totaal ongeveer 300GB aan files geserveerd waarvan ongeveer 280GB aan video voor het VOD is.

Is er een mogelijkheid om met de huidige server het probleem op te lossen of moet er echt andere hardware in/nieuwe fileserver voor het VOD? Ik heb al voor een aantal (voor ons) high traffic sites (7000-25000 unieke per dag) de files op de lokale webservers gezet alleen is dit niet echt de beste oplossing aangezien die applicaties ook bestanden wegschrijven die later weer opgevraagd moeten worden door de applicaties.

Dat is inderdaad wat er aan de hand is, waarbij hij files uit het geheugen haalt die de oudste 'accesstime' hebben. Als je dus 5 files van 1 gig hebt, en je vraagt ze op alla '1-2-3-4-5-1-2-3-4-5' dan zal hij altijd alles van de disk moeten lezen (1 van disk naar geheugen, dan 2,3,4 - geheugen vol, 1 wordt weggedaan, 5 wordt ingelezen, 1 wordt weer opgevraagt, 2 eruit gehaald, 1 ingelezen etc).

De enige remedie daartegen is er domweg meer geheugen instoppen. Ik denk niet dat 8, 16, 32G zoveel extra gaat kosten, en het zal je wel een boel helpen in het algemeen. Tenzij je workset heel random is. Bij ons is dat iets minder random, slechts de laatst toegevoegde files worden gelezen, een video van een jaar oud vraagt bij ons bijna niemand meer op, dus komen we weg met ~400G aan data en slects 24G geheugen (en 100G SSD cache).

Opzich zoude de disks die je erin hebt hangen wel gewoon makkelijk 1Gbit/s random moeten kunnen lezen, maar blijkbaar gaat dat toch niet helemaal lekker, en het is sowieso trager dan geheugen access, dus elke leesactie vereist een fysieke leesactie, en dat kan dan al snel erg traag aanvoelen, helemaal omdat geheugen toch een factor 100-1000 sneller is qua random access tijden.

Dus tja, oplossingen:
Meer geheugen, SSD's, scheiden video/scripts

[igmar]

Verwijderd schreef op donderdag 29 juli 2010 @ 13:37:
Een collega van mij beheerd een Linux fileserver die wij gebruiken om files vanaf te halen met onze Windows 2008 R2 IIS webbservers. De laatste tijd komen de files steeds trager van de fileserver waardoor onze sites soms behoorlijk traag gaan. Nu is dit voglens mijn collega omdat de fileserver constant aan het swappen is. Nu is het zo dat er vanaf deze fileserver ook films voor ons VOD gehost worden wat het swappen tot gevolg heeft.

Wat is de uitvoer van free -m op die machine ? De filecache veroorzaakt geen swap, dat probleem zit 'm ergens anders in.

[Osiris]

igmar schreef op vrijdag 30 juli 2010 @ 17:09:
[...]


Wat is de uitvoer van free -m op die machine ? De filecache veroorzaakt geen swap, dat probleem zit 'm ergens anders in.

Het kan echter wel degelijk voorkomen dat Linux pages die hij echt gewoon niet meer gebruikt in z'n swap pleurt ten einde meer RAM over te houden voor disk cache. Echter zou dit geen swapping mogen veroorzaken, omdat die pages in principe niet gebruikt worden. (Hooguit uiteraard weer zodra hij ze wel nodig heeft, maar dat zal buiten dit probleem vallen.)

[serkoon]

Het probleem is dus dat de grotere files voor de films je buffer cache steeds vervuilen zodat de kleinere files voor je webservers niet uit cache komen.

Als je dus direct i/o kunt forceren voor die grotere files, kun je er voor zorgen dat je kleine grut in ieder geval in cache blijft zitten.

De vraag is dus: op welke manier host je die files? Samba? Zo ja, dan zou je Samba moeten kunnen africhten om de grote files via direct I/O te lezen. Als Samba de mogelijkheid niet biedt per share, file of filegrootte direct I/O in te stellen, zou je dat er natuurlijk zelf in kunnen hacken (lang leve open source)

[ Voor 10% gewijzigd door serkoon op 30-07-2010 22:33 ]

[Verwijderd]

serkoon schreef op vrijdag 30 juli 2010 @ 22:32:
Het probleem is dus dat de grotere files voor de films je buffer cache steeds vervuilen zodat de kleinere files voor je webservers niet uit cache komen.

Als je dus direct i/o kunt forceren voor die grotere files, kun je er voor zorgen dat je kleine grut in ieder geval in cache blijft zitten.

De vraag is dus: op welke manier host je die files? Samba? Zo ja, dan zou je Samba moeten kunnen africhten om de grote files via direct I/O te lezen. Als Samba de mogelijkheid niet biedt per share, file of filegrootte direct I/O in te stellen, zou je dat er natuurlijk zelf in kunnen hacken (lang leve open source)

De files worden idd met Samba gehost. Ik heb zelf geen verstand van Linux en beheer deze machine's (het zijn er twee met heartbeat) niet zelf. Dit is precies wat ik wil (direct I/O per share, file of filegrootte) maar dit moet dus wel mogelijk zijn en zo ja heb je dan eventueel een link waar dit beschreven staat (dan kan ik dit doorgegven aan degene die deze machines beheerd)?