[MatLab] Out of memory errors

[0rbit]

Sinds kort heb ik een probleem met MatLab wat ik maar niet definitief op kan lossen.

Sinds mijn MatLab scripts steeds grotere vormen aan beginnen te nemen is het geheugengebruik van MatLab enorm toegenomen. Op een gegeven moment gedurende het draaien van een script krijg ik dan ook steevast een OUT OF MEMORY error.

Ik heb op de MathWorks website de diverse tips opgevolgd. Het volgende heb ik gedaan:

1) Ik initieer mijn dataset zodat in één keer een blok geheugen van de juiste grootte gereserveerd wordt. (De dataset is maximaal een GB of 4 groot)
2) Ik laat Windows de grootte van mijn pagefile beheren.
3) Ik draai de scipts door MatLab zonder JVM op te starten (-nojvm op de commandline).
4) Daar waar mogelijk heb ik het commando PACK uitgevoerd om de variabelen weg te schrijven en weer in te lezen. Dit zou fragmentatie van het geheugen moeten tegengaan. (Fragmentatie zou al voorkomen moeten zijn doordat ik punt 1) uitvoer)

Dit alles heeft er weliswaar voor gezorgd dat de out of memory errors steeds later optreden; toch zou ik nog net iets langer door willen simuleren, om zo betere resultaten te krijgen.

De volgende opties lijken mij onmogelijk:
• Meer werkgeheugen installeren. (2 van de 3 bankjes zitten vol (2x512MB); de chipset lijkt niet stabiel te kunnen omgaan met een derde dimm)
• Afwijken van het double datatype; De bewerkingen zouden dan een conversie terug naar dit type vereisen en dat zou dezelfde eisen aan het geheugen gaan stellen.
• Het omschrijven van grote delen van het script naar C om zo alsnog te kunnen afwijken van het double type. Voor zover ik weet gebruikt MatLab voor zijn MEX bestanden ook gewoon de LAPACK DLL's; intern wordt daar wederom alles met 8 bytes per double uitgevoerd en ben je net zo ver van huis.

Zou het helpen om het complete werkgeheugen te defragmenteren? Weet iemand hier een goede tool voor? (de shareware-probeer-tools die ik vind vertrouw ik veelal niet)

De wanhoop nabij, vrees ik dat er bijna niets anders op zit dan de bewerkingen in recursieve vorm te schrijven en het performanceverlies maar te accepteren.

Heeft er iemand nog een geniale tip die ik over het hoofd gezien heb?

[Sallin]

heb je al geprobeerd in je scripts grote matrices die je niet meer gebruikt te clearen?
Probeer zo weinig mogelijk gebruik te maken van for loops. Een hele hoop stappen kan je als matrix of vector uitvoeren. Verder kan de find functie ook nog weleens helpen.

dus ipv

code:

for n= 1:N
for p = 1:P
if x(n,p) == 1
x(n,p) = 2;
end 
end
end

code:

xiseen = find(x==1);
x(xiseen)=2;

[Cool_Mod_E]

Welke versie / SP gebruik je ? (zowel van OS als MatLab)?

[Daedalus]

Ik ben niet zo'n held in MatLab, maar heb je al naar het commando 'sparse' gekeken? Als je matrices met een hoop nullen hebt, kan het aanzienlijk schelen in geheugengebruik.

[Verwijderd]

Heb je dit gelezen:

http://www.mathworks.com/support/tech-notes/1100/1106.html

[Oceria]

Tsja, ik heb geen verstand van Matlab en de geniale tip heb ik niet, maar als ik zie dat je met bestanden van 4 Gig groot werkt, en "maar" 1 gig aan werkruimte hebt, zou mijn eerste overweging toch zijn om die 2x512 te vervangen door 2x1024 of indien mogelijk 2x2048.
Verder kun je overwegen om een tweede harde schijf als master aan te sluiten en die als swapfile-schijf te gebruiken (zoek op Microsoft knowledgebase over hoe precies, dit luistert nauw bij NT).
Kijk ook eens of je MOBO wel de laatste BIOS versie heeft, om de stabiliteitsproblemen te voorkomen bij het bijplaatsen van een derde geheugenbank. Mogelijk heeft dit ook te maken met het feit dat je chipset (afhankelijk van welk type je hebt) maar 4 lanes heeft, waardoor in bank 2 en 3 alleen singlesided geheugen reepjes mogen zitten. Controleer dat ook!

Misschien is het toch ook wel handig om wat meer info te geven:
CPU, mobo type, geheugen type, OS versie etc.

Succes iig!

[0rbit]

Sallin schreef op maandag 03 oktober 2005 @ 15:24:
heb je al geprobeerd in je scripts grote matrices die je niet meer gebruikt te clearen?
Probeer zo weinig mogelijk gebruik te maken van for loops. Een hele hoop stappen kan je als matrix of vector uitvoeren. Verder kan de find functie ook nog weleens helpen.

dus ipv

code:

for n= 1:N
for p = 1:P
if x(n,p) == 1
x(n,p) = 2;
end 
end
end

code:

xiseen = find(x==1);
x(xiseen)=2;

Ik gebruik helemaal geen for loops in de berekening, alleen een enkele om een lijst met bestanden te doorlopen.

Het probleem sluipt erin als ik een SVD doe op mijn dataset die bestaat uit een sloot vectoren, waarbij iedere vector een meting is. Het maken van de dataset doe ik door eerst alle bestanden (waarin de metingen zich bevinden) te doorlopen en precies uit te rekenen welke afmetingen de matrix moet hebben.

Dan wijs ik met zeros een matrix toe en ga deze vullen met de vectoren door andermaal de bestanden te doorlopen. Als je dat niet doet dan komt MatLab er achter dat hij die matrix halverwege ineens niet meer groter kan maken door fragmentatie in het geheugen. De SVD moet je wel op die manier doen anders komen je eigenvectoren er niet uit of hebben ze maar betrekking op een (te) klein deel van je metingen.

Ik draai dit alles op Matlab 7.0 R14 onder Windows XP SP2.

Je kunt het probleem gemakkelijk simuleren door een array van zeros te maken van ongeveer 50k bij 5000 elementen. (nFeatures = 50000; nSamples = 5000; X = zeros(nFeatures, nSamples); oid)

[0rbit]

Daedalus schreef op maandag 03 oktober 2005 @ 15:27:
Ik ben niet zo'n held in MatLab, maar heb je al naar het commando 'sparse' gekeken? Als je matrices met een hoop nullen hebt, kan het aanzienlijk schelen in geheugengebruik.

Hmja, dat weet ik, maar mijn matrices hebben natuurlijk geen nullen om te comprimeren. De SVD van een verzameling nullen is niet bijster nuttig. Het moet ook nog werken zeg maar

Verwijderd schreef op maandag 03 oktober 2005 @ 15:28:
Heb je dit gelezen:

http://www.mathworks.com/support/tech-notes/1100/1106.html

Ja, dat is het lijstje wat ik heb afgewerkt. Het helpt absoluut, maar blijkbaar is het gewoon vrijwel onmogelijk om MatLab slim dit geheugen te laten managen. Hij zou bijvoorbeeld op vector-basis kunnen swappen. Blijkbaar doet hij dat niet.

Oceria schreef op maandag 03 oktober 2005 @ 15:28:
Tsja, ik heb geen verstand van Matlab en de geniale tip heb ik niet, maar als ik zie dat je met bestanden van 4 Gig groot werkt, en "maar" 1 gig aan werkruimte hebt, zou mijn eerste overweging toch zijn om die 2x512 te vervangen door 2x1024 of indien mogelijk 2x2048.

De bestanden zijn maar enkele MB, maar ik pluk een selectie van vectoren uit die bestanden. Samen zijn die vectoren in MatLab zeker groter dan 3,5 GB.

Geheugenupgrade, hmja, dat zou kunnen helpen, echter de berekeningen duren lang genoeg om het intensief gebruik van een swap-file te rechtvaardigen. Daarnaast is er geen budget en geen tijd voor aanvraag van budget om een upgrade te verwezenlijken, ben ik bang.

Verder kun je overwegen om een tweede harde schijf als master aan te sluiten en die als swapfile-schijf te gebruiken (zoek op Microsoft knowledgebase over hoe precies, dit luistert nauw bij NT).

Het probleem is dat Windows een maximale swapfile van 4GB toestaat. De helft hiervoor is (onder Windows XP dan) gereserveerd voor adressering (geen idee waarom eigenlijk). De andere helft blijft dus over voor de data. Ik weet dus niet of een tweede swapfile van 4GB wordt aangemaakt of dat ze samen maximaal 4GB mogen zijn. Dat zal ik eens uitzoeken.

Kijk ook eens of je MOBO wel de laatste BIOS versie heeft, om de stabiliteitsproblemen te voorkomen bij het bijplaatsen van een derde geheugenbank. Mogelijk heeft dit ook te maken met het feit dat je chipset (afhankelijk van welk type je hebt) maar 4 lanes heeft, waardoor in bank 2 en 3 alleen singlesided geheugen reepjes mogen zitten. Controleer dat ook!

Ik heb het laatste BIOS. Er staat ook in het boekje van het moederbord dat het niet gegarandeerd werkt met drie dimms. En als het werkt, dan alleen op een lagere bussnelheid. Ik zou potentieel er dus nog 512 MB op vooruit kunnen gaan. Meer/grotere dimmetjes heb ik helaas niet.

Misschien is het toch ook wel handig om wat meer info te geven:
CPU, mobo type, geheugen type, OS versie etc.

Ik gebruik nu een Athlon XP-M 2800+ in een Asrock K7S8X moederbord. Ik gebruik hierin een matched-pair Twinmos 512MB PC3200 geheugen en draai zoals gezegd Windows XP SP2 en Matlab 7.0 R14.

Bedankt voor de tips

[Borizz]

Een 32 bits processor (een Ahtlon XP-M is 32 bits), kan maximaal 4 GB aan geheugen adresseren (virtueel geheugen is daarbij inbegrepen), aangezien je files van maximaal 4 GB gebruikt en windows en andere applicaties ook nog geheugen nodig hebben, zou het goed kunnen dat daar je probleem in zit.

[Sallin]

Mr_Atheist schreef op maandag 03 oktober 2005 @ 15:32:
Ik gebruik helemaal geen for loops in de berekening, alleen een enkele om een lijst met bestanden te doorlopen.

Het probleem sluipt erin als ik een SVD doe op mijn dataset die bestaat uit een sloot vectoren, waarbij iedere vector een meting is. Het maken van de dataset doe ik door eerst alle bestanden (waarin de metingen zich bevinden) te doorlopen en precies uit te rekenen welke afmetingen de matrix moet hebben.

Dan wijs ik met zeros een matrix toe en ga deze vullen met de vectoren door andermaal de bestanden te doorlopen. Als je dat niet doet dan komt MatLab er achter dat hij die matrix halverwege ineens niet meer groter kan maken door fragmentatie in het geheugen. De SVD moet je wel op die manier doen anders komen je eigenvectoren er niet uit of hebben ze maar betrekking op een (te) klein deel van je metingen.

Ik draai dit alles op Matlab 7.0 R14 onder Windows XP SP2.

Je kunt het probleem gemakkelijk simuleren door een array van zeros te maken van ongeveer 50k bij 5000 elementen. (nFeatures = 50000; nSamples = 5000; X = zeros(nFeatures, nSamples); oid)

Ken je het commando svds? Daarbij kies je het aantal componenten dat je mee wilt nemen en hoeft er geen volledige svd uitgevoerd te worden. Op een gegeven moment ga je toch alleen maar ruis modelleren.

Edit: eventueel, als je een PCA achtige oplossing wilt kan je ook een nipals algoritme programmeren. Die trekt ook alleen de componenten die jij wilt hebben en is erg snel.

[ Voor 6% gewijzigd door Sallin op 03-10-2005 16:23 ]

[0rbit]

Sallin schreef op maandag 03 oktober 2005 @ 16:20:
[...]

Ken je het commando svds? Daarbij kies je het aantal componenten dat je mee wilt nemen en hoeft er geen volledige svd uitgevoerd te worden. Op een gegeven moment ga je toch alleen maar ruis modelleren.

Edit: eventueel, als je een PCA achtige oplossing wilt kan je ook een nipals algoritme programmeren. Die trekt ook alleen de componenten die jij wilt hebben en is erg snel.

Ja, ik doe al een recursive SVD, die alleen de componenten neemt die gezien het aantal samples zinnig zijn. Het probleem is dat die functie nu één grote variabele X verwacht die al te groot is voor MatLab.

Het feit dat het recursive is is wel makkelijk; Ik kan dus later per vector uit X de SVD updaten en zodoende tot eenzelfde resultaat komen als dat ik had gekregen als ik de SVD op de totale matrix X had uitgevoerd. Het probleem is dat de implementatie van deze functie vooralsnog uitgaat van een matrix X en niet van een directory met daarin een zooi bestanden die op basis van een aantal criteria al dan niet moeten worden opgenomen in X (en dus in de SVD).

nipals ken ik niet; Ik zal er eens naar gaan kijken. Het moet inderdaad een PCA-achtige functionaliteit hebben; het enige criterium is dat er een schatting van de eigenvectoren uit komt rollen gebaseerd op zoveel mogelijk data.

Het lijkt erop dat het gebruik van meerdere swapfiles ook geen effect gaat hebben; Dat weet ik pas als mijn simulatie weer ergens ophoudt; later deze dag waarschijnlijk

Ik ga nu die functie maar omschrijven, zodat hij volledig recursief op alle data werkt en geen matrix X meer nodig heeft. Het is alleen wel vervelend als je eerst gewoon

code:

muG = mean(X, 2)

kunt doen terwijl je dan steeds alle data los moet gebruiken of moet partitioneren.

code:

muG1 = mean(X1,2);
muG2 = mean(X2, 2); etc

of:

for i=1:veel
 bestand lezen;
 variabelen selecteren;
 Xtotaal = Xtotaal+Xbestand
end;

muG = Xtotaal / aantal_vars*veel

Dat is wel om moedeloos van te worden

Misschien is het dan toch tijd om een Athlon 64 met veel geheugen en een 64 bits Matlab aan te schaffen... Helaas zal dat nog wel even op zich laten wachten.

[0rbit]

Nou, de recursieve code werkt goed; het duurt alleen vooralsnog een factor 100 langer om uit te rekenen. Ik zal er dus nog een beetje aan moeten optimaliseren.

Bedankt voor de tips allemaal!

[Oceria]

Het ziet er naar uit dat Windows XP (de 32 bits versie) maximaal 4 GB aan geheugen kan adresseren en daarnaast nog 16 TB (Tera byte) aan swapfile ruimte kan behappen. (bron).

Daarnaast heeft Microsoft nog wat tips om de swapfile zo efficiënt mogelijk te gebruiken:

• You can optimize virtual memory use by dividing the space between multiple drives and by removing space from slow or heavily accessed drives. To best optimize your virtual memory space, divide it among as many physical hard drives as possible. When you select drives, follow these guidelines:
• Try to avoid having a paging file on the same drive as the system files.
• Avoid putting a paging file on a fault-tolerant drive such as a mirrored volume or a RAID-5 volume. Paging files do not require fault-tolerance, and some fault-tolerant computers experience slow data writes because they write data to multiple locations.
• Do not put multiple paging files on different partitions on the same physical disk drive.

(bron)

Hoop dat je daar nog wat aan hebt

[0rbit]

Bedankt!

Ik had daar gisteren al even op gezocht. Het lijkt inderdaad toch nog een beetje helpen als je op zoveel mogelijk fysieke schijven een swapfile aanmaakt. Uiteindelijk loop ik dan weer tegen een of andere out of memory error op, maar met de itererende variant van het algoritme (die trouwens ook best wel wat geheugen slurpt om de tussenstappen tijdens het itereren op te slaan) lijkt het grotendeels opgelost of in ieder geval lijkt de grens wederom verlegt

Simuleren met alle data op de hoogste kwaliteit lijkt nog niet mogelijk, maar met wat herschrijven en wat dimensionaliteit fine-tuning moet het lukken.