Newsgroup: it.comp.lang.delphi
Titolo: D7E - memory leak (FORSE..) su TAdoConnection

Ciao a tutti.
Ho una app che fa ogni tanto un batch che:
 
1) chiude la connessione al db
2) apre la connessione al db
3) legge n record (n e' su un file ini)
4) scrive dei file (una riga x record)
5) etichetta i record processati 
 
La memoria cresce, cresce cresce, anche se di poco.
Dopo aver cercato memroy leak nel mio codice, ho fatto un test....
 
Ho creato una app scema che tramite un timer on 10 secondi chiude a apre una TAdoConnection.
Bene.
La app all'inizio era su 22584
Dopo circa 1 ora e' su 22852.
 
Ho ovviamente (ma non per tutti) cercato info su questa stranezza.
Ho trovato solo qualche post dove uno che fatto esattamente lo stesso tipo di test segnala esattamente la stessa cosa.
 
Qualcuno sa se c'e' un modo di sistemare sto casino?
 
A.
 
 
 
 
 
 


hai installato il service pack 1 e il non ufficiale service pack 2 per 
delphi 7?
...magari è stato risolto....non ho provato e non posso provare al 
momento...sorry
 

 Qualcuno sa se c'e' un modo di sistemare sto casino?
 
Una cosa che mi viene in mente di chiederti è se le risorse vengono 
tutte distrutte e ricreate ogni volta, o se semplicemente chiudi e 
riapri files e connessione.
Per distrutte intendo proprio che riesci a loggare la free della 
adoconnection, adoquery e di tutti gli oggetti di cui fai uso.
 
Se non ne esci e hai fretta di chiudere, ricordati sempre il vecchio 
trucco di schedulare col windows scheduler un bat che lancia 
periodicamente il tuo processo che esegue il workflow una sola volta poi 
esce.
 
-- 
morde
Android
QT 4.7
Delphi (5,6,7.. expired)
Firebird Database
 

lo stesso problema l'avevo riscontrato anch'io, ed è un problema che ho anche riscontrato utilizzando l'Enterprise Manager a corredo di Sql Server, l'unico che rilascia correttamente la memoria è il DbaMgr di Andrea Montanari

 riapri files e connessione.
 
 
Come per la app di test, chiudo, apro, uso, chiudo.
Gli oggetti sono creati all'avvio e distrutti in uscita.
L'unica differenza e' che nella app di test sono creati a designtime.
La app vera e propria li crea da codice.
Questa cosa non sembra avere impatti sul problema.
 
A.


scusa ma mi sono perso... :-|
 
Io parlo di una MIA APP SCRITTA IN DELPHI 7.
Cosa c'entra SqlServer e il suo enterprise manager?
 
A

 Cosa c&#39;entra SqlServer e il suo enterprise manager?
ho fatto questo riferimento perche' se un auto funziona male, non e' detto che sia colpa del motore, magari la benzina puo' avere dei problemi. il fatto che altre applicazioni non scritte in delphi soffrano dello stesso difetto a suo tempo mi avevano portato alla conclusione che il problema poteva risiedere nell'interfacci ado, anche se successivamente sono stato contraddetto dall'applicazione di Montanari che essendo scritta in Visual Basic sicuramente utilizza questa interfaccia, ciao Brunello

 Qualcuno sa se c'e' un modo di sistemare sto casino?
 
Generalmente con FastMM riesci a trovare molti cadaveri
sparsi in giro.
 
-- 
Virgilio Lattanzi        Teamsystem Communication srl
Tel: 
+39 0733 818863
     via Fontanella, 38
Fax: 
+39 0733 819133
     62012 Civitanova Marche MC
WWW: 
www.tscomm.it
       ITALY

 Dopo circa 1 ora e' su 22852.
 
Questi numeri da dove vengono? Che tipo di controllo fai?
Non � detto che la crescita della memoria utilizzata, in un determinato 
lasso di tempo, sia necessariamente indice di memory leak.
 

Prima di tutto, bentornato a bordo, Andrea.
 
Mi spiego:
 
lancio la app
la faccio girare per alcuni minuti
lancio il processxp.exe di sysinternals e faccio una scrennshot della sua finestra
Dopo un certo tempo faccio un cfr tra quanto riporta processxp e quello che vedo nella screenshot
 
A.

 lancio il processxp.exe di sysinternals e faccio una scrennshot della sua finestra
 
Ok, ma la domanda resta: quei numeri a cosa corrispondono? Stai confrontando i valori della colonna "working set"? Se fosse questo, ad esempio, il VMM ha le sue politiche di gestione della memoria e non è detto che un aumento di quel valore corrisponda, necessariamente, ad un memory leak della tua applicazione. Devi utilizzare sistemi diagnostici studiati apposta per l'individuazione dei memory leak (e che, tra l'altro, potrebbero non essere efficaci al 100%). Considera che, in generale, il rilascio della memoria da parte del SO avviene in maniera molto più lenta rispetto all'allocazione, proprio perché il sistema si riserva di applicare ottimizzazioni/caching.

Andrea Laforgia ha scritto:
 
<cut>
 
E' davvero lui o � un fake?
 
Se fosse davvero lui, la profezia Maya sul 2012 sarebbe pi� vicina al suo 
compimento!
 
-- 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it
 
 
 

 compimento!
 
Trovatevi un riparo.

 Trovatevi un riparo.
 
Ehi, qui si programma in Delphi: sono anni che ci stiamo preparando alla
Fine del Mondo!


 
Si..ok...
Pero se quando parte sta, tanto per dire a 100, e dopo 24 ore sta a 1000, questa cosa come andrebbe interpretata?
 
A.

 Pero se quando parte sta, tanto per dire a 100, e dopo 24 ore sta a 1000, questa cosa come andrebbe interpretata?
 
Fino a che non specifichi quale colonna stai analizzando, non è possibile interpretare nulla. Process Explorer ti offre un'ampia gamma di colonne, per quel che riguarda la memoria di un processo. Tu quale stai guardando?
 

Working set
 
A.

 Working set
 
E' difficile stabilire a priori quant'è la memoria effettivamente utilizzata da un processo, sotto Windows, da un valore "macroscopico" come quello del ws. Il working set (totale o privato del processo) è solo indicativo e di solito sovra/sotto-stima il reale utilizzo di memoria nel sistema. Come già detto, per individuare dei memory leak non puoi basarti su questa informazione. Cerca di fare un'analisi utilizzando qualche tool diagnostico. Con FastMM, che ti è stato già consigliato, c'è lo Usage Tracker, per esempio.
 
 

Appena ho tempo faro delle prove con quanto mi e' stato suggerito.
 
CQM, se ho una app che si limita ad usare SOLO oggetti ADO (TAdoConnection e dTAdoQuery), fa solo close, open, close.... e dopo una settimana la memoria e' cresciuta da 100 a 10000 ci sono forti possibilita' che qualcosa funzioni in modo cinofallico.
 
Sarebbe carino fare la stessa prova su xe/xe2 e vedere cosa succede.
 
A.
 
 
 
 
 
 
 
 
 
 
 
All'atto pratico, pero', se oggi lancio la mia app e occupa 100 e dopo una settimana occupa 10.000 tutte le considerazione sulle porcate che winzozz fa o non fa ne gestire la memoria cadono nel vuoto...

 CQM, se ho una app che si limita ad usare SOLO oggetti ADO (TAdoConnection e dTAdoQuery), fa solo close, open, close.... e dopo una settimana la memoria e&#39; cresciuta da 100 a 10000 ci sono forti possibilita&#39; che qualcosa funzioni in modo cinofallico.
 
Come già detto, non è così scontato. Fino a che non userai i tool adeguati, per indagare su certi "problemi", non caverai un ragno dal buco. Ci sono anche altri aspetti, da considerare. Per esempio, aprire e chiudere una connessione ogni 10 secondi non è affatto una buona strategia. Bisogna vedere se e come usi il connection pooling, su quale DB, con quali driver. Il sistema operativo non è dentro la tua testa, è programmato per ottimizzare, "cachare" (dai, questa te l'ho messa su un piatto d'argento), e sta a te adottare le strategie giuste per non far esplodere il consumo di memoria. Non è detto che il consumo di memoria aumenti in maniera spropositata solo per via di memory leaks.

 una buona strategia. 
 
Lo so. 
Normalmente non lo faccio ma questa cosa esula dalla "normalita'" per vari motivi. Ti riporto i primi 2:
 
1) il collegamento col db passa da una rete WAN e non LAN
Ho una sede centrale e 12 sedi distaccate.....
 
2) sono pianificati riavvi del server database 
 
Se capita una di queste cose l'utente dovrebbe andare sul pc, chiudere la app e riavviarla.
 
Se poi ci sono strategie diverse per evitare questo problema, ben vengano.
 
Riguardo il cavare il ragno dal buco, ribadisco:
 
a) Ho una app di test che connette, fa una query, chiude e ripete ste cose a distanza di n unita di tempo
b) la app ha SOLO una TAdoConnection, una tAdoquery ed un timer
c) La faccio partire usando FastMM o altro strumento del genere.
d) Se, e ribadisco se, trovo un leak, di certo non e' nel codice scritto da ME
 
 
A.

 d) Se, e ribadisco se, trovo un leak, di certo non e' nel codice scritto da ME
 
Come ti ho detto, non è detto che la crescita del consumo di memoria 
dipenda da un memory leak. Può essere, ovviamente, ma non è detto. 
Quando dici "SOLO una TADOConnection" devi considerare che Delphi ti 
semplifica molto la visione delle cose, perché ti fa ragionare per 
componenti. Dietro un componente TADOConnection, però, c'è un mondo 
intero di interazioni a basso livello. C'è l'interfacciamento ad un 
driver e l'utilizzo di socket. Considera che quando si invoca la 
chiusura di un socket, questo va in TIME_WAIT per un certo tempo. In 
quel lasso di tempo non è utilizzabile. Lo stesso sistema operativo va 
configurato adeguatamente, per consentire un alto tasso di connessioni 
di rete. Insomma, ci sono tanti aspetti da considerare.
 

 di una transazione critica?
 
Gli orari di lavoro sono TASSATIVAMENTE 7.00 18.00.
I riavvi sono pianificati alle 3 del mattino.
 
A.

 I riavvi sono pianificati alle 3 del mattino.
 
Domanda, solo per curiosità: perché?

Lui lavora cosi.
Quando qlc ha provato in modo soft a chiedere il xche di certe scelte il tono della risposta era sul tipo "fatti i cazzi tuoi".
Customer rulez....
 
A.

 Customer rulez....
 
Be', fino a un certo punto. Un cliente dovrebbe comunque essere disponibile a capire le ragioni di una scelta tecnica sbagliata. Se ti risponde "fatti i cazzi tuoi" è un cliente che è meglio perdere che trovare.
 
 

Andrea, sfondi una porta aperta.
Ma ci sono i clienti e poi ci sta *IL* CLIENTE.
 
A.
 
 
 

 Domanda, solo per curiosità: perché?
 
Un motivo alquanto semplice potrebbe essere perche` fa backup a freddo, 
ovvero:
 
 - Ferma il database;
 - Copia i file che compongono la base dati del database;
 - Riavvia il database.
 
Certo, ci sono metodologie migliori e piu` "soft" per fare un backup, ma 
ognuno si fa male come meglio crede :)
 
Enrico

 ognuno si fa male come meglio crede :)
 
Sì, potrebbe anche essere un cold backup notturno, ma, nonostante 
questo, a me la cosa puzza...
 

 questo, a me la cosa puzza...
 
Non chiedere quello che non vuoi sapere, ricordo che un cliente per cui 
lavoravo prevedeva tre partizioni del disco per i datafile di oracle salvo 
poi crearli tutti sulla stessa partizione...
 
Enrico