OUT OF MEMORY

[Giulio Ballabio]

Buongiorno a tutti,

riprendo questo mio vecchio Topic allegandone un'altro che fa riferimento alla stessa problematica: https://forum.instantdeveloper.com/viewtopic.php?f=5&t=93442&p=181977&hilit=out+of+memory#p181977

Da tempo abbiamo realizzato un gestionale da ufficio che si basa sull'integrazione di .dll (realizzate sempre in INDE) all'interno di un progetto principale deployato ed installato sotto la wwroot di IIS.

Come spiegavo in precedenza, monitorando 5 diversi clienti tra quelli a cui abbiamo installato il gestionale, abbiamo riscontrato un'incrementale aumento di memoria utilizzata da w3wp.exe.

Per chiarire meglio la situazione riporto di seguito i risultati dell'analisi di ieri:
Ore 10:15 >> Occupati 308 MB || Ore 11:00 >> Occupati 474 MB || Ore 15:15 >> Occupati 1.96 GB || Ore 17:00 >> Occupati 2.26 GB

Quando questo servizio, all'interno della giornata, raggiunge i 2.8 GB / 3 GB tutto il sistema si blocca in "Out of Memory" fino ad un riavvio manuale dell' Application pool.

Sono un po' in difficoltà in quanto non è un qualcosa che riusciamo a replicare ma è una problematica che da diverso tempo a questa parte si presenta da alcuni clienti.

Non vorrei arrivare a "finte" soluzioni come il programmare un riavvio ogni tot ore di IIS dato che questa cosa causa disguidi durante l' utilizzo di un gestionale.
Credo di trovarvi daccordo con me che riavviare il sistema mentre potenzialmente qualcuno sta inserendo ordini / fatture facendo perdere tutto non è una soluzione.

Ad oggi, data la difficoltà di replica, non abbiamo inoltrato la questione direttamente al reparto assistenza di INDE ma se qualcuno del reparto dovesse leggere questo topic e ritenere che
questa problematica possa essere indagata e risolta ci attiveremo in merito.

Per riassumere tutto, ancora prima di capire come intervenire, la domanda è:
E' normale questo incrementale aumento della memoria RAM utilizzata da IIS durante l'utilizzo di un applicativo sviluppato con INDE ?

Grazie a tutti,
Buona Giornata

[d.termini]

Ciao
No non è normale e probabilmente è collegato a qualche oggetto che non viene rilasciato, dovresti indagare su cosa causa questo problema (inizialmente nel nostro caso era un problema col motore di reportistica, poi abbiamo avuto lo stesso problema con procedure veramente pesanti), al limite potresti passare a 64bit che ti dà un po' di respiro ma probabilmente devi controllare che anche tutte le dll etc possano funzionare a 64bit.

[r.bianco]

Avete IMDB che popolate in modo massivo e che non svuotate? Le IMDB, anche se all'interno di Forms, non vengono svuotate alla close della Form.
Di norma, più per buona abitudine che per altro, alla fine del codice mi occupo di svuotare tutti gli oggetti con .close(), .clear() e = NULL; avvisando in modo esplicito il garbage collector che non ho più bisogno di quegli oggetti.
Altra cosa, l'appication pool è impostato per un recycle regolare? Il sito ha un timeout per le sessioni morte ma ancora appese?

[Giulio Ballabio]

Ciao
No non è normale e probabilmente è collegato a qualche oggetto che non viene rilasciato, dovresti indagare su cosa causa questo problema (inizialmente nel nostro caso era un problema col motore di reportistica, poi abbiamo avuto lo stesso problema con procedure veramente pesanti), al limite potresti passare a 64bit che ti dà un po' di respiro ma probabilmente devi controllare che anche tutte le dll etc possano funzionare a 64bit.

Grazie del feedback, cercando una soluzione online ci siamo imbattuti in questa "soluzione" visto che lavorando sul 64bit verrebbe bypassato il limite di memoria imposto dall'utilizzo a 32bit, non abbiamo intrapreso questa soluzione perchè non ci piaceva l'idea di perdere il controllo sulla memoria utilizzata semplicemente alzando la soglia limite superata la quale si presenta il problema.

[Giulio Ballabio]

Avete IMDB che popolate in modo massivo e che non svuotate? Le IMDB, anche se all'interno di Forms, non vengono svuotate alla close della Form.
Di norma, più per buona abitudine che per altro, alla fine del codice mi occupo di svuotare tutti gli oggetti con .close(), .clear() e = NULL; avvisando in modo esplicito il garbage collector che non ho più bisogno di quegli oggetti.
Altra cosa, l'appication pool è impostato per un recycle regolare? Il sito ha un timeout per le sessioni morte ma ancora appese?

Inizio con il ringraziarti per gli spunti che ci hai fornito.
Ammetto anche un po' di ignoranza in merito ad alcune cose che hai suggerito di verificare. Se fossi così gentile da fornirci degli input ulteriori te ne sarei molto grato.

All'interno dei nostri progetti utilizziamo regolarmente i documenti ma non è raro utilizzare VARIABILI GLOBALI e IMDB. (Che sia buona norma sbiancare questi oggetti concordo a pieno, sinceramente con un po' di leggerezza abbiamo sempre inteso che questo tipo di oggetti fossero, passami il termine, "volatili"). Da come scrivi intuisco che caricare ad esempio 10 righe di dati in una IMDB all'apertura di un programma senza mai sbiancare manualmente questa IMDB, a livello visivo non mi cambia nulla ma a livello di memoria questo genera potenzialmente ogni volta un 10MB (numero a caso) di memoria allocata in più. Ho capito bene ?

Attualmente l' Application pool è impostato per default con un recycle ogni 1740 minuti (29h) ma all'atto pratico non abbiamo capito con che precisione viene rispettata questa impostazione dato che da un cliente, dove di default su IIS questa impostazione era settata a 0, abbiamo impostato ieri sera alle 18:00 1740 minuti ma già questa mattina la memoria era stata resettata tornando a 100MB circa.

Cosa intendi con "timer per sessioni morte" ? Ti riferisci a "Timeout di inattività" ? Se si, nei nostri application pool manteniamo l'impostazione di default ogni 20 minuti.

Di seguito riporto la schermata di configurazione del nostro Application Pool:

Screen-ApplicationPool.png (62.38 KiB) Viewed 507 times

Mentre all'interno del progetto principale che apre poi tutte le .dll di cui il nostro gestionale è composto abbiamo questa impostazione:

RefreshInterval.png (4.76 KiB) Viewed 502 times

Aggiunto per evitare che ogni 20 minuti programmi che devono rimanere sempre attivi in produzione si resettino.
Adesso mi sta venendo il dubbio che questa impostazione renda inutile il refresh ogni 20m dell' Application Pool.
In questo caso cosa suggerisci ? Creare 2 application pool a livello di IIS ?

Grazie ancora per il tuo tempo!

[r.bianco]

All'interno dei nostri progetti utilizziamo regolarmente i documenti ma non è raro utilizzare VARIABILI GLOBALI e IMDB. (Che sia buona norma sbiancare questi oggetti concordo a pieno, sinceramente con un po' di leggerezza abbiamo sempre inteso che questo tipo di oggetti fossero, passami il termine, "volatili"). Da come scrivi intuisco che caricare ad esempio 10 righe di dati in una IMDB all'apertura di un programma senza mai sbiancare manualmente questa IMDB, a livello visivo non mi cambia nulla ma a livello di memoria questo genera potenzialmente ogni volta un 10MB (numero a caso) di memoria allocata in più. Ho capito bene ?

In generale, la memoria allocata da ogni variabile/oggetto viene liberata automaticamente quando decade il suo scope. In altre parole, se dichiari una variabile dentro ad un blocco di codice (if, ciclo, funzione, procedura, evento...), una volta che l'esecuzione di quel blocco di codice termina la memoria occupata viene liberata senza che tu debba fare nulla. Non sono però convinto che il sistema "automatico" sia del tutto efficiente, così preferisco essere esplicito nel codice.
Per quanto riguarda le IMDB, volevo sottolineare che anche se nell'albero del progetto la IMDB è dentro una videata, in realtà è un oggetto globale, per cui non beneficia della "sbiancatura" automatica una volta che la form viene chiusa. In altre parole, sei costretto a eseguire una delete della IMDB all'evento Unload della videata, perché altrimenti la sua memoria occupata permane per l'intera sessione. Chiaro che una volta che la sessione muore, anche la IMDB muore e la memoria viene liberata.
Mi auguro di essere stato chiaro.

Attualmente l' Application pool è impostato per default con un recycle ogni 1740 minuti (29h) ma all'atto pratico non abbiamo capito con che precisione viene rispettata questa impostazione dato che da un cliente, dove di default su IIS questa impostazione era settata a 0, abbiamo impostato ieri sera alle 18:00 1740 minuti ma già questa mattina la memoria era stata resettata tornando a 100MB circa.

Se ricordo bene il default è proprio 1740. Ti sconsiglio di metterlo a zero perché ogni tanto IIS ha necessità di ripulirsi. L'alternativa è togliere il limite in minuti e mettere quello ad orario fisso (comodo perché così decidi tu a che ora e non è più casuale).
Sempre se ricordo bene, se cambi le impostazioni dell'application pool, quello resetta tutte le sessioni per ricaricarsi. Inoltre, quando l'app pool va in out of memory, IIS fa cadere le sessioni per farlo ripartire (non ne sono certissimo, ma abbastanza).

Cosa intendi con "timer per sessioni morte" ? Ti riferisci a "Timeout di inattività" ? Se si, nei nostri application pool manteniamo l'impostazione di default ogni 20 minuti.

Esattamente quello. Anche in questo caso, ti sconsiglio di metterlo a zero.

(sono curioso di sapere come risolvi)

PS
Appoggio l'idea di d.termini di usare l'application pool a 64bit, magari dopo che avete risolto questo problema, in modo da non nasconderlo.

[Giulio Ballabio]

All'interno dei nostri progetti utilizziamo regolarmente i documenti ma non è raro utilizzare VARIABILI GLOBALI e IMDB. (Che sia buona norma sbiancare questi oggetti concordo a pieno, sinceramente con un po' di leggerezza abbiamo sempre inteso che questo tipo di oggetti fossero, passami il termine, "volatili"). Da come scrivi intuisco che caricare ad esempio 10 righe di dati in una IMDB all'apertura di un programma senza mai sbiancare manualmente questa IMDB, a livello visivo non mi cambia nulla ma a livello di memoria questo genera potenzialmente ogni volta un 10MB (numero a caso) di memoria allocata in più. Ho capito bene ?

In generale, la memoria allocata da ogni variabile/oggetto viene liberata automaticamente quando decade il suo scope. In altre parole, se dichiari una variabile dentro ad un blocco di codice (if, ciclo, funzione, procedura, evento...), una volta che l'esecuzione di quel blocco di codice termina la memoria occupata viene liberata senza che tu debba fare nulla. Non sono però convinto che il sistema "automatico" sia del tutto efficiente, così preferisco essere esplicito nel codice.
Per quanto riguarda le IMDB, volevo sottolineare che anche se nell'albero del progetto la IMDB è dentro una videata, in realtà è un oggetto globale, per cui non beneficia della "sbiancatura" automatica una volta che la form viene chiusa. In altre parole, sei costretto a eseguire una delete della IMDB all'evento Unload della videata, perché altrimenti la sua memoria occupata permane per l'intera sessione. Chiaro che una volta che la sessione muore, anche la IMDB muore e la memoria viene liberata.
Mi auguro di essere stato chiaro.

Attualmente l' Application pool è impostato per default con un recycle ogni 1740 minuti (29h) ma all'atto pratico non abbiamo capito con che precisione viene rispettata questa impostazione dato che da un cliente, dove di default su IIS questa impostazione era settata a 0, abbiamo impostato ieri sera alle 18:00 1740 minuti ma già questa mattina la memoria era stata resettata tornando a 100MB circa.

Se ricordo bene il default è proprio 1740. Ti sconsiglio di metterlo a zero perché ogni tanto IIS ha necessità di ripulirsi. L'alternativa è togliere il limite in minuti e mettere quello ad orario fisso (comodo perché così decidi tu a che ora e non è più casuale).
Sempre se ricordo bene, se cambi le impostazioni dell'application pool, quello resetta tutte le sessioni per ricaricarsi. Inoltre, quando l'app pool va in out of memory, IIS fa cadere le sessioni per farlo ripartire (non ne sono certissimo, ma abbastanza).

Cosa intendi con "timer per sessioni morte" ? Ti riferisci a "Timeout di inattività" ? Se si, nei nostri application pool manteniamo l'impostazione di default ogni 20 minuti.

Esattamente quello. Anche in questo caso, ti sconsiglio di metterlo a zero.

(sono curioso di sapere come risolvi)

PS
Appoggio l'idea di d.termini di usare l'application pool a 64bit, magari dopo che avete risolto questo problema, in modo da non nasconderlo.

Grazie per le precisazioni!! Faremo le opportune verifiche / modifiche e speranzoso di risolvere aggiornerò tutti qui sul forum.

Buona Serata

[Gionanni]

Anche noi abbiamo lo stesso problema. il fatto è che il progetto ha dimensioni ragguardevoli ed è difficile manualmente individuare e monitorare tutte le imdb di tutte le sessioni.
Qualcuno ha idea se sia possibile e come "contare i record" di ogni IMDB definita nell'applicazione? Spero di sbagliare ma non mi sembra sia possibile tramite la reflection...