181 messaggi dal 23 marzo 2006
ho messo in using anche il command, ma niente da fare...

prima ho sbagliato a fare i conti... il processo in memoria cresce di 4 KByte ogni secondo....
181 messaggi dal 23 marzo 2006
ho sostituito tutti i vari "OleDB-qualcosa" con degli "SqlDB-qualcosa", e ho modificato la connnection string per utilizzare un SqlProvider invece dell'OleDbProvider....


....ora sembra tutto ok.... l'occupazione di memoria del servizio è "stabile", anche con la versione "completa" dell'applicazione.

ufffffffffffffff

ora posso andare al mare
liscio wrote:
ho sostituito tutti i vari "OleDB-qualcosa" con degli "SqlDB-qualcosa", e ho modificato la connnection string per utilizzare un SqlProvider invece dell'OleDbProvider....

curiosità: perchè usavi il provider per OleDB quando in realtà hai SQL Server?

Daniele Bochicchio | ASPItalia.com | Libri
Chief Digital Officer@icubed | Chief Innovation Officer@openloop
Microsoft Regional Director, MV
181 messaggi dal 23 marzo 2006
eh.... retaggio... andando avanti poi ho visto che tanto fungeva tutto lo stesso, e non mi sono mai posto il problema. In generale sviluppo app web, nelle quali comportamenti di questo tipo non si palesano.

però non capisco perchè con il provider OLE deve avere questo comportamento strano.... mah...

cmq l'ho stressato per tutto il weekend, e sembra tutto ok. L'unico parametro che "cresce", quasi impercettibilmente, è la "occupazione di memoria virtuale".
È una cosa grave/rilevante?
liscio wrote:
però non capisco perchè con il provider OLE deve avere questo comportamento strano.... mah...

perchè internamente fa uso di risorse unamanged differenti rispetto al managed provider per SQL Server. ed evidentemente c'è un'allocazione differente della memoria. non ho però mai fatto un windows service con OLEdb, quindi le mie sono speculazioni.

cmq l'ho stressato per tutto il weekend, e sembra tutto ok. L'unico parametro che "cresce", quasi impercettibilmente, è la "occupazione di memoria virtuale".
È una cosa grave/rilevante?

dipende quanto si ingrossa.

Daniele Bochicchio | ASPItalia.com | Libri
Chief Digital Officer@icubed | Chief Innovation Officer@openloop
Microsoft Regional Director, MV
176 messaggi dal 04 giugno 2007
Contributi | Blog
Due parole: COM interop.
Il provider OLE e' internamente implementato con molte chiamate a codice nativo e le allocazioni sono molto meno ottimizzate e GC-friendly.

Quanto al problema del VAS che cresce, il SQL provider e' disegnato per essere molto avido con la memoria disponibile finche' ce n'e'. Comincia ad essere taccagno solo quando ci si avvicina al limite. Questo vuole dire che fino all'ordine delle centinaia di MB (a 32 bit) puoi stare tranquillo.
Da un certo punto di vista, ha senso: se hai ancora centinaia di MB di memoria disponibile, perche' sprecare cicli di clock facendo una raccolta della spazzatura?

Saluti

--Alessandro
181 messaggi dal 23 marzo 2006
grazie dell'illuminazione...

il "quanto" cresce: in 24 ore di esecuzione, in produzione, è passato da

Mem Usage = 21.352 / VM Size = 18.712

a:

Mem Usage = 21.548 / VM Size = 18.832


lo so che i parametri del taskmanager non sono molto affidabili...

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.