Onderwerp: Virtual memory (vm.dirty)

Ik ben een beetje rond gaan kijken omdat ik binnenkort een server ga configureren. Uiteraard, naar veel lezen kom je soms op dingen dat mogelijk wel of mogelijk niet goed is.

Het gaat over de:
vm.dirty_ratio
vm.dirty_background_ratio

Dit zorgt ervoor dat een bepaald aantal geheugen gebruikt kan worden als cache voor schrijven. Dat is leuk en aardig maar dat wil ik niet aangezien deze voor risico's zorgen tijdens een spontaan uitval of crash. Ik heb rond gezocht en het wordt aangeraden om het te configureren gebaseerd op het aantal geheugen.

De server heeft 128 GB geheugen, dus als ik 1% als maximaal cache gebruik is dat (128*0.01=1.28 GB) en dat is een redelijk groot aantal data dat verloren kan gaan!

Dit geeft risico's en daarmee ben ik uiteraard niet blij. Je kan het om een bepaalde tijd laten flushen maar nog steeds heeft hij dan risico's

Ik heb ook immers een raid controller met een veilige cache hiervoor, dus om het dubbel in systeem geheugen te doen vind ik niet kunnen.

Hebben jullie suggesties of tips? Kan deze uitgeschakeld worden? zo ja zijn er beperkingen dat er kan gebeuren?

Graag vriendelijk en netjes antwoorden, aangezien ik erop hoop dat meerdere personen hier baat aan hebben.
[spoiler]Moest ik kwijt - Iedereen op WHT is vriendelijk, weet ik [/spoiler]

Oorspronkelijk geplaatst door xentos

Ik ben een beetje rond gaan kijken omdat ik binnenkort een server ga configureren. Uiteraard, naar veel lezen kom je soms op dingen dat mogelijk wel of mogelijk niet goed is.

Het gaat over de:
vm.dirty_ratio
vm.dirty_background_ratio

Dit zorgt ervoor dat een bepaald aantal geheugen gebruikt kan worden als cache voor schrijven. Dat is leuk en aardig maar dat wil ik niet aangezien deze voor risico's zorgen tijdens een spontaan uitval of crash. Ik heb rond gezocht en het wordt aangeraden om het te configureren gebaseerd op het aantal geheugen.

De server heeft 128 GB geheugen, dus als ik 1% als maximaal cache gebruik is dat (128*0.01=1.28 GB) en dat is een redelijk groot aantal data dat verloren kan gaan!

Dit geeft risico's en daarmee ben ik uiteraard niet blij. Je kan het om een bepaalde tijd laten flushen maar nog steeds heeft hij dan risico's

Ik heb ook immers een raid controller met een veilige cache hiervoor, dus om het dubbel in systeem geheugen te doen vind ik niet kunnen.

Hebben jullie suggesties of tips? Kan deze uitgeschakeld worden? zo ja zijn er beperkingen dat er kan gebeuren?

Graag vriendelijk en netjes antwoorden, aangezien ik erop hoop dat meerdere personen hier baat aan hebben.
[spoiler]Moest ik kwijt - Iedereen op WHT is vriendelijk, weet ik [/spoiler]

Ik denk dat je een voodoo verhaal gelezen hebt, en je server performance enorm om zeep gaat helpen met een dubieuze reden.

1 : server crashes zijn _zeldzaam_
2 : een applicatie die een transactie commit wil (/meent nodig te hebben) tot en met het disk systeem kan dat vragen aan het OS.
3 : De kernel VM weet meer en is (veel) sneller dan raid cache.
4 : vm tweaking zie ik alleen maar langskomen in de vorm van een specifieke applicatie (vaak databases) en uitgebreid meten voor na. Als je de vraag stelt vanuit 'ik ben _een server_ aan het inrichten' kun je daar feitelijk nog niks over zeggen.

Kortom - met de informatie die je gegeven hebt zeg ik : niks aan doen.

1) Hoe zeldzaam het ook is, het blijft mogelijk.

2) Ik weet nog niet zeker hoe ik dit kan beantwoorden aangezien ik hier nog weinig verstand van heb. MYSQL heeft een eigen buffers dat gebruikt wordt voor onder andere commits. VM.Dirty zorgt ervoor dat i.p.v. kleine 64kb files bijvoorbeeld 512 MB bestanden geschreven wordt(1.28 GB in mijn geval). Dit is handig aangezien een harde schijf een slechte I/O heeft en slecht met kleine bestanden overweg kan.

The Linux kernel stages disk writes into cache, and over time asynchronously flushes them to disk. This has a nice effect of speeding disk I/O but it is risky. When data isn’t written to disk there is an increased chance of losing it.

3) Dat klopt. Maar dat zorgt er niet voor dat potentiele writes weggehaald wordt? een groter cache is altijd leuk om te hebben maar daar zijn andere oplossingen voor. Wel langzamer maar meer dan dat is niet echt nodig.

4) Dat klopt. Maar het gaat specifiek over de write cache, vm.dirty* zorgt ervoor dat geheugen gebruikt kan worden als een buffer/cache zodat hij in een keer alle data naar de HDD kan schrijven. Het heeft ook z'n nadelen en deze probeer ik te verhelpen.

Uiteraard, zoals je zegt zit ik ook te denken om dit gewoon erop te laten en bijvoorbeeld een 'flush naar een bepaalde tijd te zetten'. Zo ver ik weet kan je ook in fstab een 'sync' neerzetten zodat hij direct geflushed wordt.

Je kunt beter de tijd verlagen dat iets in de cache blijft staan. Het is namelijk niet zo dat dat de server pas bij een volle cache gaat schrijven tenslotte.

Oorspronkelijk geplaatst door systemdeveloper

Je kunt beter de tijd verlagen dat iets in de cache blijft staan. Het is namelijk niet zo dat dat de server pas bij een volle cache gaat schrijven tenslotte.

Klopt! Je hebt een minimum wanneer hij gaat beginnen en een maximum wanneer hij gaat forceren om de data weg te schrijven. Als je een groot aantal geheugen hebt dan is 1% al snel 1 GB of meer. Dat is redelijk veel data dat gevaar kan lopen en dat is iets wat ik wilt vermeiden. Je hebt ook een timer (vm.dirty_expire_centisecs) wanneer het ongeacht de aantal data weg wordt geschreven als hij vervallen is zodat hij bijvoorbeeld niet langer dan 30 seconden in het geheugen mag blijven zitten.

Maar toch blijft het idee dat het meer kans geeft dat meer data hierdoor corrupt kan raken. Aangezien geheugen niet beschermd is. De raid controller heeft een write cache met een capacitator, dat zorgt ervoor dat deze data veilig naar de harde schijf kan komen.

Het is niet dat ik het erg vind dat hij de server ram gebruikt als buffer. Maar het gaat mij erom dat hij dan extra tijd in een plek rond hangt waarbij het eigenlijk niet nodig is.

De raid controller laat alleen write cache toe(geen read) en heeft uiteraard een capacitator. En heeft een capaciteit van 1 GB, voor kleine bestanden is dat genoeg. Eventueel kan ik er een SSD cache toevoegen zodat hij extra write cache ruimte heeft.

Maar dit is wat ik wilt gebruiken, voorbeeld:
Send write -> raid controller(cache small files !safe!) -> harddisk

Dat is iets veilig en zorgt voor minimum risico's, maar met de OS buffer erbij is het bijvoorbeeld:
Send write -> OS RAM BUFFER(cache small files !NOT SAFE!) -> raid controller(cache small files !safe!) -> harddisk

Dat zorgt eigenlijk voor een ruimte dat niet nodig is, niet alleen dat maar het is ook gelijk een stuk gevaarlijker. En het zorgt ervoor dat de cache van de raid controller niet gebruikt wordt ~OUCH~

Oorspronkelijk geplaatst door xentos

1) Hoe zeldzaam het ook is, het blijft mogelijk.

2) Ik weet nog niet zeker hoe ik dit kan beantwoorden aangezien ik hier nog weinig verstand van heb. MYSQL heeft een eigen buffers dat gebruikt wordt voor onder andere commits. VM.Dirty zorgt ervoor dat i.p.v. kleine 64kb files bijvoorbeeld 512 MB bestanden geschreven wordt(1.28 GB in mijn geval). Dit is handig aangezien een harde schijf een slechte I/O heeft en slecht met kleine bestanden overweg kan.

Dat, maar waar ik doel in punt 2 is dat een applicatie die een transactie wil met garantie dat de disk gehaald is als de write() terugkomt daar gewoon calls voor heeft.
(file openen met O_SYNC , aanroepen van fsync() ).
Als dat applicatie dat (al) niet doet, is het faken van 'ongeveer' dat gedrag door een kleine vm cache gerommel in de marge.

Daarmee kan de applicatie zorgen dat lopende zaken consistent op disk staan, en dat na een eventuele crash helder is wat de laatste succesvolle transactie was.

Overigens wordt de vm dirty cache niet alleen weggeschreven bij 'vol' maar ook regelmatig qua tijd. Het is dus niet zo dat je bij een heel grote cache potentieel uren van disk writes kwijt raakt.

Nu quote je 1 zin, zonder context, zonder uitleg en zonder auteur.
"I read it on the Internet, so it must be true" .

3) Dat klopt. Maar dat zorgt er niet voor dat potentiele writes weggehaald wordt? een groter cache is altijd leuk om te hebben maar daar zijn andere oplossingen voor. Wel langzamer maar meer dan dat is niet echt nodig.

4) Dat klopt. Maar het gaat specifiek over de write cache, vm.dirty* zorgt ervoor dat geheugen gebruikt kan worden als een buffer/cache zodat hij in een keer alle data naar de HDD kan schrijven. Het heeft ook z'n nadelen en deze probeer ik te verhelpen.

Uiteraard, zoals je zegt zit ik ook te denken om dit gewoon erop te laten en bijvoorbeeld een 'flush naar een bepaalde tijd te zetten'. Zo ver ik weet kan je ook in fstab een 'sync' neerzetten zodat hij direct geflushed wordt.

Tweaken op pseudo-betrouwbare writes doe je op een laptop met buggy suspend modes of een gare batterij.

Met die reden dit deze tweaks op een database server doen levert je bijna zeker de volgende thread op in databases - performance valt tegen .

Maar als de server nu niet kapot gaat maar je raidcontroller?
Dan moet je je klanten vertellen dan je al die tijd de performance hebt opgeofferd voor veiligheid terwijl je toch 1GB aan JSF orders kwijt bent...

Oorspronkelijk geplaatst door visser

Nu quote je 1 zin, zonder context, zonder uitleg en zonder auteur.
"I read it on the Internet, so it must be true" .

Met deze conclusie kwam ik zelf, dus ging een beetje rond zoeken voor een basis daarvan. Het is een voorbeeld en ik vond het beter uitgelegd dan ik deed :P

Dus het is voor applicaties? en geen normale bestanden read/write, dat buffer?

Ik had het idee dat alle bestanden zoals .php of andere kleine bestanden daar opgeslagen werd.

Oorspronkelijk geplaatst door systemdeveloper

Maar als de server nu niet kapot gaat maar je raidcontroller?
Dan moet je je klanten vertellen dan je al die tijd de performance hebt opgeofferd voor veiligheid terwijl je toch 1GB aan JSF orders kwijt bent...

Haha, daar heb ik inderdaad niet aan gedacht. Het heeft inderdaad een risico. Maar extra zekerheid is leuk om te hebben

Oorspronkelijk geplaatst door xentos

Met deze conclusie kwam ik zelf, dus ging een beetje rond zoeken voor een basis daarvan. Het is een voorbeeld en ik vond het beter uitgelegd dan ik deed :P

Dus het is voor applicaties? en geen normale bestanden read/write, dat buffer?

Ik had het idee dat alle bestanden zoals .php of andere kleine bestanden daar opgeslagen werd.

Nee, alle disk-IO loopt via vm en de disk/io cache.

Alleen een applicatie die een bestand schrijft kan kiezen om bij het schrijven te vragen direct (zonder cache) te schrijven. De write call is dan pas 'klaar' als de data op disk staat.
Of de applicatie kan alle gecachte writes "nu" naar disk flushen.
Standaard is schrijven de data aan het OS geven, en zodra het OS de data heeft aangepakt is de write 'klaar' . Het OS schrijft dan 'later' . Dat is de vm/disk (dirty) cache.

Een applicatie die wil "NU naar disk en kom pas terug als je klaar bent" kan dat gewoon krijgen, door een file met de juiste parameters te openen (O_SYNC) , of door fsync() aan te roepen na schrijven.

(klassiek voorbeeld : syslog. Lees de manpage over het verschil als er een '-' voor de filename staat. En voel het verschil op een drukke logserver met en zonder synchronous writes ).

Oorspronkelijk geplaatst door visser

Nee, alle disk-IO loopt via vm en de disk/io cache.

Alleen een applicatie die een bestand schrijft kan kiezen om bij het schrijven te vragen direct (zonder cache) te schrijven. De write call is dan pas 'klaar' als de data op disk staat.
Of de applicatie kan alle gecachte writes "nu" naar disk flushen.
Standaard is schrijven de data aan het OS geven, en zodra het OS de data heeft aangepakt is de write 'klaar' . Het OS schrijft dan 'later' . Dat is de vm/disk (dirty) cache.

Een applicatie die wil "NU naar disk en kom pas terug als je klaar bent" kan dat gewoon krijgen, door een file met de juiste parameters te openen (O_SYNC) , of door fsync() aan te roepen na schrijven.

(klassiek voorbeeld : syslog. Lees de manpage over het verschil als er een '-' voor de filename staat. En voel het verschil op een drukke logserver met en zonder synchronous writes ).

Ingewikkeld :P

Laat ik de vraag zo stellen:

Je kan als je een schijf mount met 'SYNC' kan je deze buffers als goed is overslaan. Zodat hij direct gaat schrijven.

Wat zijn de nadelen en/of voordelen hiervan -> Alles zit achter een raid controller met ongeveer hetzelfde grote cache.

Bedankt voor de snelle antwoorden, waardeer ik echt

Oorspronkelijk geplaatst door xentos

Ingewikkeld :P

Laat ik de vraag zo stellen:

Je kan als je een schijf mount met 'SYNC' kan je deze buffers als goed is overslaan. Zodat hij direct gaat schrijven.

Wat zijn de nadelen en/of voordelen hiervan -> Alles zit achter een raid controller met ongeveer hetzelfde grote cache.

Bedankt voor de snelle antwoorden, waardeer ik echt

Ik ken er nauwelijks een voordeel van, ik heb nog nooit iemand gehoord die dat serieus wilde doen op een server.
Als ik wat rondkijk zie ik voordelen voor dingen als 'floppies - zodat je 'm er veilig uit kunt gooien als hij gestopt is met schrijven' .
(en idem usb stick)

Je raid met battery ram cache komt nog niet in de buurt van IO ops die 'vm cache' levert.

Verder verwacht ik meer writes, en een dramatisch slechtere performance.

Maar goed, als je het nu zo graag wilt probeer je het toch gewoon ?

(als je googled vind je ongeveer de antwoorden die ik je gaf op ongeveer het idee wat jij ook had .
http://www.linuxquestions.org/questi...option-618823/
http://unix.stackexchange.com/questi...ync-var-or-not

http://www.scs.stanford.edu/13wi-cs2...es/xsyncfs.txt
"What is a synchronous mount?
All IO operations force the log (like an implicit fsync after each syscall)
Who uses synchronous mounts?
No one. People expect apps to use fsync properly
Why does paper talk about synchronous mounts?
Semantically, they set the gold standard--couldn't ask for more
But performance numbers aren't so interesting, as nobody uses them"