Array DML (FireDAC) ->Zostáva neuvoľnená pamäť

[Stanislav Hruška]

Ja som mal na mysli len to spracovanie záznamov, nie predmet diskusie.

[miroB]

Ja verim vic FireDAC nez Mirovi Myslim si, ze kdyby v prenosu byl memory leak, nekdo by na nej uz upozornil. ..

Aj ja mám rád FireDAC. Netvrdím, že je zlý. Naopak. Ale pamätáš sa snáď, že sme mu museli v nejakých prípadoch pomôcť. Niekde to tu bude zachytené.
Táto otázka začala, že či neexistuje po Array DML nejaký flush. Teraz síce nemám priamu odpoveď, len viem, že keď je query preč, pamäť je zjavne a s istotou voľná. Zatiaľ to stačí.
Myslím aj Radek písal, že si Query a spol vytvára v runtime. Nič zvláštne teda nespravím.

[miroB]

.. a na konci cyklu Exec a Commit..

Nie. Exec a Commit už v cykle. Vždy keď sa naplní 10t riadkov.
No a po cykle tiež, len už tam bude zrejme riadkov menej než 10t.
Pretože tabuľka má v danom prípade cca 500t riadkov, tak v cykle je to dosť veľa krát, čo musí prísť Exec.
A po cykle ešte jeden Exec na záver.

[Stanislav Hruška]

Nerozumiem prečo píšeš o dvoch cykloch, keď na to určite stačí jeden.

[miroB]

Nerozumiem prečo píšeš o dvoch cykloch, keď na to určite stačí jeden.

Nepíšem o počte cyklov. Cyklus je jeden. Ale sú dve miesta, kde robím Exec a Commit. Ak je to vnútri v cykle, tak za tým ešte aj StartTransaction.

Sú dve základné kombinácie:

• ArraySize > počet riadkov tabuľky, tak sa Exec/Commit vykoná iba raz a to až za cyklom
• V opačnom prípade sa Exec/Commit vykoná aj vnútri cyklu.
  Presne toľkoto krát: (počet riadkov div ArraySize). No a potom raz pravdepodobne aj za cyklom.
  To ak platí ( počet riadkov > ( ArraySize * (počet riadkov div ArraySize) ).
  Inak nie, lebo čírou náhodou by to znamenalo, že počet riadkov je presným násobkom ArraySize

[miroB]

..TLDR DML Array je velmi efektivni zpusob prenosu dat a FireDAC jej ma (nebo alespon mel) resen korektne, takze bych v tomto pripade hledal spis chybu na strane programatora nez FireDAC. Mozna se vsak pletu a FireDAC obsahuje memory leak. Pro analyzu vsak potrebuji MCVE..

Ani mne to nedá. Po ránu s občerstveným elánom, sa pokúšam program učesať.
Okrem iného som zamenil Query za Command. Zdá sa, že sa znížilo rezíduum cca o 40%.
Ale prekopávam aj svoju štruktúru. Aby som poctivo a v pravý čas likvidoval všetky Pointre, Tarray<> a TDictionary. Podľa toho, ako dopadnem, by som následne zvážil aj to MCVE

[miroB]

Táto otázka začala, že či neexistuje po Array DML nejaký flush. Teraz síce nemám priamu odpoveď, len viem, že keď je query preč, pamäť je zjavne a s istotou voľná.

Muzes uvolnit hodnoty DML pole napr. nastavenim ArraySize. To je vec, kterou pro Tebe FireDAC neudela (resp. udela tusim s odpripravenim prikazu; pisu z hlavy). Primo po spusteni vsak zustavaji hodnoty parametru v kolekci.

Napada me ze by to nakonec mohlo byt i pointou dotazu... Nejde vsak o memory leak. Jde jen o krok jenz si musi programator zaridit sam.

Už mám MVCE. Správa sa to presne.. Na .. (škaredý výraz nedopíšem, aj keď som s tým stratil hafo času)
Nepomôže

Kód: Delphi [Vybrat]

1.   FD_cmd.Params.ArraySize := 1; // NEPOMOZE
2.   FD_cmd.Params.Clear; // NEPOMOZE

Hmm nepomôže dokonca nič?

Projekt vytvorí *.db3, a naplní na veľkosť 123 MB. Tam kde je exe.
Tabuľka sa zobrazí po vygenerovaní dát. Je tam aj pokus o vyčistenie. Ale to nefunguje.
Myslím, že mi zostáva visieť na 25 MB, bez ohľadu na to, či sú výsledné data 123 MB, alebo cca 40 MB
Naďalej robím len s Task Managerom. Nemám čas na iné. Ale princíp je jasný.

Spravil som si medzitým verziu 2: Všetky data som strčil do dataModule.
Tu pomôže jediné na záver: DataModule1.Free A pamäť je okamžite k dispozícii.

[miroB]

..Ja verim vic FireDAC nez Mirovi

No tak ja ti teraz nejak neviem.. Možno by si mi mohol začať veriť:)

..Tak ci tak, mereni pameti pomoci OS neni spravne..

Hmm, no vysvetli užívateľovi, ktorý nič iné nevie, než TM.
Keď som použil TFDQuery, zostávalo visieť cez 50 mega. Veru nijak málo.
Začal by som autora programu podozrievať, že asi nemá vo svojom diele poriadok. (myslím svoj program, nie FireDAC)
Tomu som sa chcel určite vyhnúť.

Zdá sa, že pre FDCommand, je kus menšia spotreba pamäti. (aspoň tej, čo sa opticky neuvoľní)

Inak súkromne povedané, memory Leak to nebude. Pretože som schopný napriek tomu otvárať a čítať ďalšie a ďalšie Excel súbory, bez zavretia programu.
Ak by šlo o memory leak, určite by som časom zamrzol.

[miroB]

Práve v tomto je rozdiel medzi IT študovaným a nami ostatnými.
Som osobne ochotný uvažovať o kompromisoch MM vs TM.
Lenže keď si uvedomím, že do hodiny prifrčí študent, ktorý príde na to, že program je nejaký veľký, väčší než obvykle..
Preto na záver pekne radšej zhodím celý DataModule. A budem mať pokoj.
To mi za to určite stojí. Mám iné veci, ktoré musím obhajovať
Nakoniec programy robíme pre bežných ľudí. Nie pre IT fajnšmekerov..

[miroB]

Sklapnul som opätky. Kontroloval som aplikáciu.
Skúsil som to najprv s FastMM4. Ten sa išiel zblázniť. Ja tiež.
Vadí mu aj TZip.Header, ktorý mám úplne oficiálne podľa návodu. Potom UnicodeStringy. Aj TStringList a pod.
Preto som sa poobzeral po fóre. Pozrel som na Stanovu históriu (Dík).
Našiel som najmä:

• MadExcept - pomohol mi nájsť dve reálne chyby (memory Leak)
• Eurekalog - už keď som bol vo švungu, vyskúšal som ju tiež. Ani tá už nič nenašla

Upresnenie: Vyskúšal som vzorové chyby z Radkovho článku:
https://delphi.cz/post/Detekce-problemu-za-pomoci-FastMM4.aspx
Oba vyššie uvedené programy tam pekne zabučali. Takže nakonfigurované ich mám správne. Verím, že by tie TStringListy objavili. Ak by tam boli nekorektne. Ako teda ešte stále vypisuje FastMM4.

PS
Task Manager hlási na záver presne takú istú obsadenosť pamäti ako predtým. Čo teda bol môj prvotný impulz pre experimentovanie.
Ale fajn, že som sa naučil používať tie dva šikovné programy.
Ďakujem všetkým za usmernenia.

[Stanislav Hruška]

Len taká pripomienka: Ak zabudneš zlikvidovať napr. TFDQuery, tak Ti to FMM4 vypíše a k tomu Ti hodí kopu ďalších vecí. Aj ten TStringList. Uvoľníš TFDQuery a odrazu je všetko čisté
Naučil som sa jeho výpis čítať od konca.

[miroB]

Fakt, že tá nevrátená pamäť ma vystrašila.
Zdrojáky len na tento čiastkový účel majú cca 550 kB. (Bez tretích strán).
Je to obrovské množstvo na prípadnú detailnú manuálnu kontrolu.
Bohužiaľ, nepoužíval som doteraz žiadne kontrolné programy.
Iba som vyskúšal prevod z desiatok rôznych excel súborov. Prevod sa zdal byť konečne bezchybný.
Nevrátená pamäť bola však indikátorom možných problémov. Teraz po overení (a oprave), za pomoci MadExcept a EurekaLog som podstatne spokojnejší. Navyše som tú vlastnosť DML Array overil aj kontrolným programom, čo som zavesil tu niekde vyššie. Konečne budem môcť kľudne spať.

[miroB]

Len taká pripomienka: Ak zabudneš zlikvidovať napr. TFDQuery, tak Ti to FMM4 vypíše a k tomu Ti hodí kopu ďalších vecí. Aj ten TStringList. Uvoľníš TFDQuery a odrazu je všetko čisté
Naučil som sa jeho výpis čítať od konca.

Dík, to vyzerá rozumne aj logicky.
Ozaj dá sa vôbec napísať väčší program, kde FastMM4 bude úplne spokojný?
Ten madExcept spolu s EurekaLog nie sú dostatočnou kontrolou?

[miroB]

Takze finalni resume? FireDAC nema memory leak? Nebo?

Nemyslel som, že FireDAC má memory leak. Myslím, že to som snáď nemohol napísať, lebo ma to ani nenapadlo.
Je pre mňa na záver dôležité vedieť, že pamäť sa síce nevrátila, ale nie je to spôsobené mojou chybou.
Jasne.. vidieť vrátenú celú pamäť by bolo pekné (ušetrilo by mi to aj nejaké tie nervy), ale keď to je "stav techniky", ako rada tvrdí jedna veľká auto firma, tak musím byť spokojný
K tomu filozofickému fóru. Ozaj to tak asi vyzerá. Len ti poviem, že keby som si toto mohol prečítať na začiatku, nestratil by som more času. Preto: možno sa ešte niekomu zíde.
Dnes a predtým mnohokrát som použil vyhľadávanie na fóre.. Sú tu niektoré dobré kľúčové slová aj zaujímavé info. Aspoň pre tých, čo sú na hľadanie odkázaní.

[pf1957]

2) Kolekce hodnot parametru zustava po spusteni prikazu v objektu FireDAC zachovana (s urcitou konfiguraci, celkem i verim ze nektery z parametru konfigurace dokaze toto chovani ovlivnit; nejde ovsem o memory leak, ale umysl kvuli perzistenci)

Pro podobne ucely by se mel dat pouzit Unprepare, ne?