[C++] Out of Memory: catch || die?

[Olaf van der Spek]

Hoe gaan jullie om met out of memory errors in apps? Ik heb er eigenlijk nooit rekening mee gehouden, heb me altijd afgevraagd of en hoe je er rekening mee zou kunnen houden en heb nog nooit een app gezien die er wel goed mee om kan gaan.
Die (abort) lijkt de enige manier.

[Icekiller2k6]

ja enigste wat je kunt doen als je Out of memory hebt is serialize van uw programma en afsluiten..

zodat je tenminste geen data/informatie kwijt bent.

Denk dat dat over het algemeen de veiligste manier is.

[Radiant]

In de embedded toepassingen die ik maak (waar je met een aantal processen vaak een kleine heap moet delen) is het vrij gebruikelijk gewoon te wachten tot er weer geheugen vrij is, meeste dingen zoals I/O commands met veel data worden toch weer gefree'd nadat ze succesvol zijn uitgevoerd en het resultaat is uitgelezen, zolang je maar oplet dat dit soort states niet te vaak voorkomen..

Op de PC moet dat ook wel redelijk werken vermoed ik, de meeste OS'en hebben wel een mechanisme dat zelf processen gaat afschieten als de hoeveelheid vrij geheugen kritiek wordt, daarna kan je weer vrolijk doordraaien, mits je toepassing niet heel tijdkritisch is.

[farlane]

Radiant schreef op woensdag 13 april 2011 @ 19:45:
In de embedded toepassingen die ik maak (waar je met een aantal processen vaak een kleine heap moet delen) is het vrij gebruikelijk gewoon te wachten tot er weer geheugen vrij is, meeste dingen zoals I/O commands met veel data worden toch weer gefree'd nadat ze succesvol zijn uitgevoerd en het resultaat is uitgelezen, zolang je maar oplet dat dit soort states niet te vaak voorkomen..

Hecht je veel waarde aan je realtime gedrag? Dat haal je toch gigantisch onderuit zo?

[Radiant]

farlane schreef op woensdag 13 april 2011 @ 20:48:
[...]

Hecht je veel waarde aan je realtime gedrag? Dat haal je toch gigantisch onderuit zo?

Dingen die écht realtime moeten gebeuren gebruik ik in zo'n situatie dan geen allocation voor Verder wacht er nooit iets blocking, dus die processen hebben er geen last van.

Als bijvoorbeeld de communicatie met een extern, niet heel kritisch, apparaat de heap gebruikt om z'n commando's in op te bouwen en je wil iets van een USB stick importeren en je daardoor even flink wat RAM consumeert om wat sectoren in op te slaan is het niet erg als dat even stilstaat.
Het zijn ook vooral dit soort "vervelende" dingen die soms eventjes veel RAM nodig hebben als een gebruiker bijvoorbeeld iets doet, voor tijdens normaal bedrijf zorg ik er altijd wel voor dat dit nooit voorkomt.

[matthijsln]

Het is natuurlijk wat je onder goed er mee om gaan als applicatie verstaat? Als een applicatie geheugen nodig heeft en dat is er niet, kan de code niet uitgevoerd worden. Of je dan netjes een "out of memory" error geeft of je applicatie crasht maakt dan verder misschien niet zo heel veel meer uit voor de gebruiker, tenzij je gegevens verliest of inconsistentie veroorzaakt. Dat kan je uiteraard proberen te voorkomen op allerlei manieren die uiteraard afhankelijk zijn van het soort applicatie, denk aan een geopend bestand eerst opslaan, database transacties bij een databaseapplicatie, uitvoeren taken in child processes, etc.

Dat een malloc() of new faalt is op zich ook gewoon een fout net alsof het netwerk down kan zijn of een hardware failure ofzo. Je kan dat wel, niet, goed, fout of als een catastrophic failure afhandelen

[farlane]

matthijsln schreef op woensdag 13 april 2011 @ 21:23:
Dat een malloc() of new faalt is op zich ook gewoon een fout net alsof het netwerk down kan zijn of een hardware failure ofzo. Je kan dat wel, niet, goed, fout of als een catastrophic failure afhandelen

Dat zie ik toch iets anders, zonder RAM kun je niet zoveel maar zonder netwerk kun je bijna alles.

Wat zou je bijvoorbeeld nog willen/kunnen doen als een malloc( 16 ) het niet doet?

[matthijsln]

farlane schreef op woensdag 13 april 2011 @ 21:59:
[...]
Dat zie ik toch iets anders, zonder RAM kun je niet zoveel maar zonder netwerk kun je bijna alles.

Wat zou je bijvoorbeeld nog willen/kunnen doen als een malloc( 16 ) het niet doet?

Wat ik bedoel te zeggen is dat het niet kunnen alloceren van geheugen vaak ook gewoon een foutcode/exception oplevert waardoor je programma die fout moet afhandelen in plaats van de actie succesvol afronden.

OOM is natuurlijk wel veel onvoorspelbaarder (maar minder onvoorspelbaar dan hardware fouten) en bij kleine alloc's kan je niet meer dan wat naar stderr printen en afsluiten, maar als je algoritme 100mb nodig hebt en je alloceert dat in een keer kan je het wel ongeveer hetzelfde afhandelen als een netwerkfout.

[Olaf van der Spek]

matthijsln schreef op woensdag 13 april 2011 @ 22:05:
OOM is natuurlijk wel veel onvoorspelbaarder (maar minder onvoorspelbaar dan hardware fouten) en bij kleine alloc's kan je niet meer dan wat naar stderr printen en afsluiten, maar als je algoritme 100mb nodig hebt en je alloceert dat in een keer kan je het wel ongeveer hetzelfde afhandelen als een netwerkfout.

Misschien slaagt de 100 mb alloc en faalt de 1 b alloc daarna. Daar schiet je dus ook niks mee op.
Je theorie is mooi, maar heb je die wel eens toegepast in de praktijk?

[matthijsln]

Olaf van der Spek schreef op donderdag 14 april 2011 @ 14:24:
[...]
Misschien slaagt de 100 mb alloc en faalt de 1 b alloc daarna. Daar schiet je dus ook niks mee op.
Je theorie is mooi, maar heb je die wel eens toegepast in de praktijk?

Ja, ik heb wel eens een fout afgehandeld (dat was mijn punt). Dat het soms niet goed kan gaf ik ook al aan...

[MLM]

Olaf van der Spek schreef op donderdag 14 april 2011 @ 14:24:
[...]

Misschien slaagt de 100 mb alloc en faalt de 1 b alloc daarna. Daar schiet je dus ook niks mee op.
Je theorie is mooi, maar heb je die wel eens toegepast in de praktijk?

Theoretisch gezien wel. Maar meestal zitten kleine allocations dichter op je logica (denk, STL collections, tijdelijk objecten etc), en als die falen, kan je logica niet verder, en zou je dat dus prima als fataal kunnen zien.

Grote allocations (zoals 100 mb) hebben een grotere kans om te falen (zowel door fragmentatie als grootte), en dan zou je dat specifieke geval best kunnen handlen in je logica.

In sommige gevallen kun je ook een "pool" hebben waaruit je kleinere objecten alloceert, die vooraf al ruimte voor X objecten alloceert, en dan kan je je OOM conditie op 1 moment afvangen, en er veilig van uit gaan dat latere allocaties in die pool altijd goed gaan. (mits je natuurlijk de hoeveelheid vereiste ruimte kan voorspellen)

[.oisyn]

farlane schreef op woensdag 13 april 2011 @ 21:59:
Wat zou je bijvoorbeeld nog willen/kunnen doen als een malloc( 16 ) het niet doet?

Je reservegeheugen aanspreken om de state gracefully op te slaan.

In onze games dumpen we tegenwoordig grote resources (zoals textures) als we out of memory gaan. Dit stelt ons in staat te tracken hoeveel geheugen er ongeveer nog in totaal nodig is voor die specifieke situatie, zodat memory budgets opnieuw ingedeeld kunnen worden of we specifieke delen kunnen optimaliseren. Maar een game is natuurlijk wat anders dan een applicatie.

[Olaf van der Spek]

.oisyn schreef op vrijdag 15 april 2011 @ 11:57:
Je reservegeheugen aanspreken om de state gracefully op te slaan.

Is dat handig? State altijd periodiek opslaan lijkt me makkelijker en is ook bruikbaar bij crashes.

In onze games dumpen we tegenwoordig grote resources (zoals textures) als we out of memory gaan. Dit stelt ons in staat te tracken hoeveel geheugen er ongeveer nog in totaal nodig is voor die specifieke situatie, zodat memory budgets opnieuw ingedeeld kunnen worden of we specifieke delen kunnen optimaliseren. Maar een game is natuurlijk wat anders dan een applicatie.

Dat alles handmatig neem ik aan? Of worden memory budgets automatisch bepaald?

[leuk_he]

handlen: Alleen als je heel grote buffers aan het allocaten bent

dumpen: Is het de moeite een dumpinterface te maken? Ga je iets met de dumps doen? (analyseren coredumps en deze automatisch opsturen?)

Tenzij je uiteraard weet dat je iets weer kunt uitswappen zoals in dat geval van de textures hierboven gaan mijn appicaties meestal gewoon dood.