OutOfMemory v GUI v 32bit – .NET – Fórum – Programujte.com

Zdravím,

měl bych takovej dotaz ohledně BinaryWriteru a OufOfMemory s GUIčkem a konzolí...

Jde o to, že při stejném kodu (32bit) mi přes konzoli projde všechno v pohodě, ale jakmile stejný kod volám z GUI tak mě to vyhodí OutOfMemory kde kapacita při erroru je 268435456, ale když to volám z konzole kapacita je když doběhne binarywriter 536870912 kde délka je 300673812 (žádná chyba OutOfMemory).

Může mi někdo vysvětlit proč tomu tak je? Nebo jak tohle by se dalo opravit?

Když vytvořím klasicky x64 app tak vše funguje v pohodě. Chápu, že asi problém je v 32bitu ale co nechápu proč (v x86) přes konzoli žádný error a přes GUI vyskočí OutOfMemory (teda občas se stane, že nevykočí a vše se provede jak má, ale to je fakt málokdy)

PS Aplikaci bych měl rád jak pro 32 tak 64bit

Díval bych se na omezení paměti přidělené aplikaci. Každopádně jestli ty čísla jsou v Bytech, tak jsou to docela velké kusy.

hu

32-bit proces má k dispozici "jen" 2G virtuální paměti, takže souhlasím s uchem, že alokuješ docela hodně. Nemyslím si, že by to GUI nějak šíleně žralo, ale může být paměť fragmentovaná tak, že se takový blok prostě nikam nevejde i když máš třeba celkově pořád dostatek volné paměti.

Navíc tam asi někde figuruje MemoryStream, což je souvislý blok paměti a při zvětšování kapacitu zdvojnásobuje. Nebo něco podobného. To by odpovídalo tomu, že ti to buď klekne na 268M, nebo projde na 536M. Tam by mohlo pomoct zadat požadovanou kapacitu předem, pokud ji znáš, ať neplýtváš.

Jinak klasika -- ujisti se, že nikde nekopíruješ nic, co nemusíš a uvolňuješ všechno, co nepotřebuješ. Myslím, že ve VS je nějaký memory profiler, který by ti mohl ukázat, co kde visí. Ideálně to uprav tak, ať velké bloky paměti vůbec nepotřebuješ.

#3 gna
No jasný to jsem nějak pochopil, že se to do paměti prostě nikam nevejde, ale jakej je rozdíl mezi konzolovou aplikaci a winformem, že jakmile to zavolám z winform tak automaticky to klekne, ale z konzole je to v pořádku? To se mi prostě nezdá že by winform alokoval pamět tak hrozně že se to prostě s prominutím posere.

Už takhle jsem to zredukoval protože si to ještě ukádalo do cache každou bitmapu i po zapsání ... Takže aspon že tohle jsem vyřešil vyprazdnováním a nedostanu se (RAM využítí) nad 350mb...

Když jsi to už načnul, jak u binarywriteru dopředu naalokuju pamět? protože +- vím kolik jí dohromady bude a vím, že to určitě 350000000 nepřesáhne ...

Napadlo mě to udělat tak, že bych to každých třeba 50mb vyprazdnoval tak že bych zapsal do souboru a pak zapsal na konec souboru další data, ale jelikož tento kod který právě zapisuje tak nejsem autor a jenom ho upravuji tak netuším zda by to mělo nebo nemělo vliv na výslednou funkčnost.

#4 Mutagen
žádnej rozdíl neni prostě pro x32 aplikace nemužeš mít víc než 2GB chápeš ? tak to kompiluj jako x64 a máš to ? o co ti de ?

co myslíš tim "alokuju paměť" u binary writeru ???? co je to za chujovinu ?

takhle vytvoříš BinaryWriter:

 BinaryWriter bw = new BinaryWriter(File.Open(fileName, FileMode.Create));

nepleteš si to s alokací paměti ??? dej sem ten kod

Možná i narážíš na problém jak pracuje Garbage Colector. On totiž mrtvé objekty neodstraňuje hned a tak můžeš mít v paměti hromadu smetí pokud vícekrát kopíruješ něco většího.

hu

#5 jerry
Určitě mužu na 32bitu spustit 64bit ;) Pokud ses chtěl vyjádřit negativně jdi si kámošema co ti tohle trpěj a nevotravuj tady ... btw nastavíš velikost binary writeru dopředu aby se nezdvojnásoboval jakmile přeteče?

Jestli jsem se přepsal a tobě to vadí tak se jdi projevovat jinam, ostatní tu radí nemají připomínky a tvuj příspěvěk? Nulová hodnota.

#6 hlucheucho
Bohužel máš asi pravdu, snažím se co nejvíce eliminovat zůstavání objektu v paměti (jsme zvyklej uvolnovat pamět tak jak potřebuju já z delphi)...

Já vlastně načítám postupně x desítek tisíc bitmap a zapisuju do souboru podle určitý struktury. A jak řikáš, bordel tam může díky tomu zůstavat, spíš jestli to nejde nějak oblafnout aby to uvolnilo pamět hned.

#7 Mutagen
hele ty toxická nádhero ... tak používej GC.Collect() a máš vystaráno ne ?

prostě neumíš programovat ... a k čemu ti je mít v paměti desítky tisíc bitmap ? nestačí ti jedna ? nebo dvě ?

#7 Mutagen
https://www.codeproject.com/Articles/483475/Memory-Limits-in-a-NET-Process

#7 Mutagen
a ještě tady

https://bhrnjica.net/2012/07/22/with-net-4-5-10-years-memory-limit-of-2-gb-is-over/

#7 Mutagen
http://assets.red-gate.com/community/books/under-the-hood-of-net-memory-management.pdf

#6 hlucheucho
https://memprofiler.com/

#8 jerry
Jasně neumím programovat :))))) To, že se tu zeptám na důvody a jedinej kdo tu začal vyjíždět jsi byl ty. Oplátka stejnou mincí ...

Spamuj si jinde tady to nikoho nezajímá.

PS. Neukládám si bitmapy ale načítám, který právě v určitý struktuře naplnuju do bw, psal jsme to nahoře pokud neumíš číst. Ale ty nečteš vše, jen to co se ti hodi na hate :)

#4 Mutagen

To se mi prostě nezdá že by winform alokoval pamět tak hrozně že se to prostě s prominutím posere.

Ty související knihovny a data dohromady dají docela dost. Podívej se kolik ten program žere po spuštení a kolik ti z těch 2G zbývá. Ale nemusí alokovat hrozně, stačí ta fragmentace. Můžeš mít 400M volných, za tím 1M využitých a na konci zase 400M volných, takže máš 800M volných, ale 500M z toho nevykousneš.

Když jsi to už načnul, jak u binarywriteru dopředu naalokuju pamět?

BinaryWriter jen tlačí data do Streamu. Jestli je to právě MemoryStream, tak tomu můžeš zadat výchozí kapacitu při vytváření. Když teda rovnou začneš na těch 350M, které nepřekročíš, tak se vyhneš tomu automatickému zvětšování z 268M na 536M, ale 350M je pořád hodně.

Řešení s nejmenšími změnani bude nahradit ten Stream. Našel jsem třeba MemoryTributary, který to drží v menších blocích, nebo rovnou použij soubor.

#13 Mutagen
pokud použiješ MemoryStream tak 500MB bez problémů uložíš do paměti i v x32 systému. A z něj pak mužeš zapisovat do souboru po 64KB blocích.

#13 Mutagen
jestli opravdu potřebuješ ukládat obrovský množství dat až na úroveň 2GB v x32, použij RAMDisk a ukládej to do něj. Je to stejně rychlý jako klasická RAM. Můžeš použít paměť grafický karty třeba 24GB DDR5 a AMD Radeon RAM Disk http://www.radeonramdisk.com/software_downloads.php  ... 

#14 gna
No právě to je ten největší problém asi v tý využití paměti, že se to nějak blbě nafragmentuje a hned je to prostě problém...

Jinak napadlo mě že bych při každý bitmapě zapsal do souboru a vyprázdnil BinaryWriter a tím i MemoryStream ... Sice by to asi vyřešilo tento problém, ale zase netuším jak by to ovlivnilo rychlost zápisu...

Teď je jen otázka zda se vyplatí zápis do souboru co bitmapa nebo nastavit pamět dopředu.

Pokud nastavím u MS kapacitu na 350M tak se automaticky nastaví i binaryWriter?

#14 gna
Tak nastavení kapacity memorystreamu to vyřešilo ... Prošlo to, ale nevidím to bohužel jako ideální řešení. Docela se přikláním k postupnému přidávání dat do souboru, ale zase se určitě neskutečně zpomalí zápis.

#18 Mutagen
jak to muže neskutečně zpomalit zápis když se stejně nezapisuje celých 350MB najednou ????

to je prostě ta mladá generace ... vysoký sebevědomí a piliny v hlavě

#19 jerry
Třeba to myslím tak, že načtu bitmapu, zapíšu do souboru (tím ho i zavřu) a vyprázdním memorystream a znova ho otevřu pro další zápis? Opravdu si myslíš, že jsem blbej, že tohle není "zpomalení" zápisu? Nebo spíš mám říct když si už hrajem na slovíčka zvýší čas doby ukládání? ...

Nevím na kom si léčíš komplexy ale je tu od tebe víc příspěvků jak od jiných a zajímavý příspěvěk (upozorňuju zajímavý, né užitečný) se tu objevil maximálně jeden.

Takže pokud k tomu nemáš co říct víc než jen hate tak si dej zpátečku... Blbý kecy umí mít každej, v tvým případě jsou to jen blbý kecy.

#20 Mutagen
Ponechávat otevřený soubor je jedna ze základních chyb začátečníků. Soubor by se měl pokaždé uzavřít, když čtení z něj se přerušuje na delší dobu jiným algoritmem. Tyhle pravidla platí už od 80. let. Existuje přeci funkce seek ne ? Jde o to, že poměrně často sem někdo píše žádost o info, ale nedává úplné informace. Naposled to byl nějakej kluk co dělal zobrazování bójí na moři. Trvalo mu rok než vubec vysvětlil co chce a než přišel na to jak se to dělá. Když načítáš najednou 350MB soubor do paměti tak se to dělá tak, že nejdřív paměť alokuješ a zjistíš, jestli se tam soubor vejde. A teprve pak do přiděleného úseku data načteš. Zapsáním do souboru se soubor nezavře. Na to potřebuješ funkci Close(). Pokud ji nezavoláš, tak poslední data se nezapíší !!!. S tim souborem v paměti se obvykle něco dělá. Pokud je to obrázek, tak se třeba nějak transformuje apod. Ty si hlavně hledal proč ti nejde do paměti načíst 5GB soubor když si pod x32 Windows. No to dost dobře není možné, protože jsou tu ty limity 2GB. Je však možné soubor rozdělit po 2GB částech což se běžně dělalo u střihových karet v řívější době když ještě nebyl x64 procesor. Konverze programu, který byl napsaný pro x64 platformu na x32 je blbost a nikdo to nedělá. Tohle se ošetřuje už při programování projektu. Proto se např. Inventor 2018 už nedělá ve verzi x32 protože to bylo moc náročné na udržování a finance pro AutoDesk atd....

#18 Mutagen
Ono není jasné, co s těmi daty potřebuješ dělat. Mně to připadá, že BinaryWriterem naplníš MemoryStream a ten pak bez změny celý zapíšeš do souboru. Tak vlastní zápis vyhoď a místo MemoryStreamu dej rovnou FileStream (ten má interní buffer 4K, který bych zvýšil třeba na 4M ať to na disk nehrabe moc často, pokud by default byl hodně pomalý).

#21 jerry
Já pořád nechápu co na tom nechápeš, psal jsem to nahoře jak to funguje, ale pro tebe ZNOVU...

Mam x desitek tisíc bitmap které si po 1 načítám do Bitmap objektu s tím, že mám jeden BinaryWriter(memorystream) a postupně ty bitmapy napisuju do binarywriteru ... kde na konci zípisu jednotlivé bitmapy vyprázdním bitmapu (= null) a v dalším cyklu opět načtu a takhle dokola s tím, že až doběhne poslední bitmapa tak se zapíše se .WriteTo(Filestream) a tím se vytvoří soubor o velikosti xmb (v mem případě něco okolo 300mb)...Už se chápem?

Nejsem začátečník jak si myslíš. To, že C# není muj hlavní jazyk je věc durhá, to, že jsme chtěl vědět pouze duvody proč to dělá, neznamená, že ten postup kterým to je napsaný je špatně! Proto hledám nějakou alternativu i jak by se to dalo jinak udělat a napadlo mě ten soubor vytvořit čistě na začátku a pak co bitmapa to zápis do souboru na konec.

Jak už jsem i psal, žen kod jsme nepsal přímo já, ale je převzat a já ho pouze upravuju pro vlastní potřeby, kde jsem už vyřešil i neskutečný využívání paměti (dřív se bitmapy načítaly, ale zustavaly neuvolněný, takže se to docela krásně dostalo s přehledem i na 2gb využití, kde teď to jede na 300mb po mých úpravách)

Chápeš, že já nenačítám do pamětí 350mb soubor ale čtu části souboru nebo přímo obrázek? Tzv si že souboru načtu jenom tu jednu bitmapu kterou potřbeuju a tu přeuložím zatím jen do memorystreamu kde na KONCI ten stream celej uložím.

NIkde jsem nepsal o 5Gb ale o cca 512mb ... A na to se celou dobu i ptám, proč mi nejde uložit do paměti 500mb i na 32bit systému, a napsal mi to gna a to mi stačí jako vysvětlení. Nepotřebuju rozsáhle teorie jak a co, sám vím dobře co potřebuju, to, že jsem se tu zeptal neni přece duvod mě tu urážet že jsme začátečník... Kdyby k tomu nebyl určitý postup jakl se to má ukládat tak to udělám úplně jinak a podle sebe, bohužel musí to mít tuhle strukturu tak s tím nic nenadělám. 

PS. Vyvýjím pod 32bit a ne není to psaný pro 64bit, jen sem hledal duvod proč to dělá.

#22 gna

Už jsem to psal, postup ukládání je takový jaký má být, pouze upravuju a přemýšlím jak by se to dalo zlepšit.

#23 Mutagen

Už jsem to psal, postup ukládání je takový jaký má být, pouze upravuju a přemýšlím jak by se to dalo zlepšit.

Ovšem ty jsi jediný, kdo ví, jaký ten postup je, takže těžko radit, jak ho zlepšit.

Podle mě jsi teď potvrdil mou domněnku, že BinaryWriterem naplníš MemoryStream, který jinak nepotřebuješ a jen ho nakonec dumpneš do FileStreamu. Takže do BinaryWriteru dej rovnou FileStream. Hotovo.

#23 Mutagen

Pokud můžeš tak zkus nahradit MemoryStream  za BufferedStream navázaný přímo do výstupního souboru. Ten pak průběžně ukládá vždy když se mu naplní buffer.
Nad ním pak udělat BinaryWriter stejně jako dřív nad MemoryStream-em takže ostatní kód by snad měl zůstat stejný.

Velikost bufferu v řádu 1..10MB by měla stačit. Ale je třeba to změřit, Teoreticky by to mohlo být podobně rychlé jako (memory stream + jednorázové uložení).

P.S. kdyby jsi to popsal tak pěkně jako v předchozím postu už dřív tak bych to možná pochopil dřív i já :)
       Ty to ze svých postů samozřejmě pochopíš, protože víš o čem jsi psal, ale pro ostatní, nebo alespoň pro mne, je o hodně těžší si to z těch střípků složit.

#23 Mutagen
500MB soubor se ti do paměti pod Win7x32 v pohodě vejde. Nacpeš ho do MemorySteramu. V tom bych problém neviděl...

ale pochop, že věta:

".......mám jeden BinaryWriter(memorystream) a postupně ty bitmapy napisuju do binarywriteru ... kde na konci zípisu jednotlivé bitmapy vyprázdním bitmapu .........."

nedává smysl. :) Ani technologicky ani logicky. Data ze souboru mužeš do objektu Bitmap/Image přenést v paměti až když to potřebuješ. A to tak, že udržuješ jen JEDNEN objekt Bitmap. Když něco načteš a na konci čtení to zase zapíšeš a vynuluješ pamět tak to znamená že s tim nic neděláš :))) Hele tohle jsou principy stejné ve všech programovacích jazycích. BinaryWriter/BinaryReader měl už TurboBasic z roku 1989. Pochop, že tady se nemuší stydět. My tě nevidíme, ale snažíme se ti pomoct....... ... njn .. tak třeba za rok ....

#26 jerry
Prosím tě, ty už kušuj.

#25 Ovrscout
ehm, tedka koukam ze i primo FileStream ma konstruktory co umi bufferovani nastavit (dokonce i asynchroni). Tak muzes skusit primo FileStream.  

Je to jako s popelnicí a popeláři. Že něco hodím do popelnice a popelnici postavím před dům neznamená, že to popeláři hned odvezou. Obsah popelnice odvezou až nastane den svozu. Pokud referenci na objekt nastavíš na null, postavíš popelnici před dům. Garbage Colector paměť neuvolní ihned, popelnici vyveze v den svozu.

a tu přeuložím zatím jen do memorystreamu

neboli bitmapy hromadíš v nějakém objektu. Ten nabývá na objemu a každé jeho zvětšení vede k alokování větší paměti, kopírování, "postavení popelnice před dům" a její "vyvezení popeláři". Tím se paměť fragmentuje. Na fragmentaci paměti se podílí i setrvávání několika binarywriterů připravených k uvolnění. Při tom se někdy poštěstí, že popelnici vystavíš před dům těsně před okamžikem svozu a tak je smetí uklizené dřív a nedělá problémy a jindy popelnici postavíš před dům po svozu odpadu a pak se smetí hromadí. Pak se stane, že není kam dát nejen smetí, ale i užitečné věci. Pak nastane tebou popsaná chyba

Toto je moje představa mechanismu jak tvůj problém vzniká.

hu

#29 hlucheucho

Do memory streamu se neukládá přímo objekt ani vazba na něj. Tam se ukládaji serializovaná data do nějakého byte[] pole (respektive se nakopírují do toho pole..)
Takže původní objekt může být zrušen i když ten buffer je pak dál používaný.

Fragmentace je spíše problém "adresního prostoru" který vzniká mixováním alokací dlouhodobých a krátkodobě "žijících" kdy díky shodě okolností není mezi alokovanými oblastmi dost místa na novou velkou. I když celkově je místa dost. Pokud je tam jen hromada krátkodobě žijících objektů tak to nebývá problém.

Ve většině případů si ale gc v .NET poradí sám. A pokud není paměť přiPINovaná kvůli IO, použití v DLL atp. tak dokáže pamět i "defragmentovat". 

Ale v návaznosti na tvůj příspěvek ještě dodám pro Mutagen:

Mutagen

Možná to už tak máš, sorry pokud je to pro tebe běžná věc(proto mne to nenapadlo rovnou), ale:
  před tím "vynulováním" bitmapy = null,   děláš Dispose? - Obecně nad  každým Objektem co má IDisposable je dobré použít using( new ...) nebo Dispose(). A opět obecně, zkus projít vytvářené objekty a zkouknout to (někdy je to IDisposable zděděné jako zde a není na první pohled vidět).

Asi taky víš, ale zkoukni jestli ti nezůstávají reference, třeba ta Bitmapa, FileStreamy na čtení, … . Třeba v nějakých dlouho žijících objektech (ale i v krátce žijících se někdy vyplatí ušetřit GC práci a nepotřebné reference vynulovat, obzvlášt pokud se odkazují "kruhově" ale to tu asi nehrozí).

Ještě k tomu FileStream s bufferem měl jsem namysli toto

#30 Ovrscout
ještě v souvislosti s memory leaky můžeš skusit CLR profiler , ale zatím jsem to moc nepoužíval.

K jerrymu už nemám co bych vyjádřil, ten tu furt jede tu svojí písničku, že se mi to do 32bitu vejde, ale ano já vím, že se to tam vejde, tu řeším důvody proč se to děje v GUI aplikaci v konzolový ne.

A k tomu, jak se do mě furt navážíš, tak to je úplně zcestný. Všichni ostatní to pochopili, jen ty tu jedeš to svoje, že to dělám špatně apod...

Jinak #30 Ovrscout
Vše dělám jak bych měl ... jak jsem psal, kod co jsem začal upravovat jsem už redukoval tak aby si to neukládalo každou bitmapu do paměti ale po zápisu zničím referenci na ten objekt. Kdybych to nechal po staru tak si neuložím do streamu ani 2k bitmap *hehe*

Ono jde o to, že to co si načtu do streamu to po zápisu do souboru zanikne, takže tam prostě je problém převážně v tom, že ty všechny data (bitmapy) se ukládají do 1 objektu kterej díky tomu nabobtná, proč to ale v GUI nefunguje a v konzoli ano je mi záhada i když to tu bylo tolikrát řečeno pořád mě to hlava nebere proč se to neuspořádá do paměti líp. Zatím jsem to vyřešil tak, že dopředu nadefinuju kapacitu memorystreamu což nějakým způsobem "zatím" funguje, ale do budoucna to budu chtít nějak zapisovat třeba po 1k bitmapách do souboru a vždy vyčistím.

#32 Mutagen
no sou tu dvě různý cesty, možná že ta tvoje konzole neni 32 bitová :) a pak ANO GUI zabírá hodně místa v paměti a proto se ti to tam nevejde, když trváš na tý velikosti udělej si třídu v konzoli a tu pak volej z GUI jako samostatný thread. A máš to. A v čem že to vlastně programuješ ? C# ? WinForms ? WPF ? C++/CX ? MS VS 2013 ? 2015 ? 2017 ?

dobře no přiznávám chodim si sem pokecat no ...

#32 Mutagen
no jo no to víš no já sem už straej a nerudnej a blbej a pomalu mě to myslí všichni vždycky pochopí a já ne ...

tak to je ...

#33 jerry

VS2013 + konzole + volaný winform na 32bit systému...
Normální Winform čistý formulář kde mám jen listbox, 3 buttony a picturebox (na zobrazení bitmapy) ...
nechápu jak by tohle mohlo tolik zabírat. GUI vytvářím přímo v konzoli (protože GUI má být jen nadstavba, pro lidi co rádi klikají) a už jsem psal že to dělám doma na 32bit systému takže asi těžko to může být konzole pro 64bit.

Ale chápeš, že to tak mám udělaný od začátku to co jsi napsal? Vše je v konzoli a z gui volám jen společný funkce a ano volám to v threadu. Jinak bych celou dobu nepsal "stejný kod volaný z GUI hází out of memory a z konzole ne"

#35 Mutagen
no to je jasný GUI bude vždycky víc náročný a navíc je to jednothreadový algoritmus....

jestli cheš zjistit kde je problém stáhni si tohle

https://memprofiler.com/

a uvidíš to hned kde to vázne .. já to nepoužívám takže nemám crack ale někde bude ...

neumim si představit jak velkej .BMP to musí bejt když to nejde načíst najednou .. to je jpg ? png ? tga ?

tady někdo řešil to samý jako ty

https://www.researchgate.net/post/What_is_the_maximum_size_of_an_array_in_C

#36 jerry
eště mě napadlo, že muže použít externí konvertor pokud ty obrázky načítáš jen z duvodu konverze

http://freeimage.sourceforge.net/features.html

funguje dobře .. a je jich spousta druhů ...

aj tady něco bude

https://code.google.com/archive/p/aforge/

#37 jerry
ale koukám chybí mu ta určení směru směrnice .... ale na to přídeš sám

#38 jerry
tady to máš hezky popsaný

https://uloz.to/!HqWEFCt38Sym/under-the-hood-of-net-memory-management-pdf