Oggetto heap e stringa di grandi dimensioni Oggetti provenienti da una coda

Question

Ho un'app di console di Windows che dovrebbe funzionare senza riavvii per giorni e mesi. L'app recupera "lavoro" da un MSMQ e lo elabora. Ci sono 30 thread che elaborano un blocco di lavoro contemporaneamente.

Ogni blocco di lavoro proveniente da MSMQ è di circa 200 kb, la maggior parte dei quali è allocata in un singolo oggetto String.

Ho notato che dopo l'elaborazione di circa 3-4 migliaia di questi blocchi di lavoro il consumo di memoria dell'applicazione è ridicolmente alto consumando 1 - 1,5 GB di memoria.

Eseguo l'app tramite un profiler e ho notato che la maggior parte di questa memoria (forse un ingaggio) non è in uso nell'heap di oggetti grandi ma la struttura è frammentata.

Ho trovato che il 90% di questi byte inutilizzati (garbage collection) sono stati assegnati in precedenza a String. Ho iniziato a sospettare che le stringhe provenienti da MSMQ siano state allocate, utilizzate e quindi deallocate e siano quindi la causa della frammentazione.

Capisco che cose come GC.Collect (2 o GC.Max ...) non siano d'aiuto dato che gc l'heap di oggetti grandi ma non lo compattano (che è il problema qui). Quindi penso che quello di cui ho bisogno è di mettere in cache queste stringhe e riutilizzarle in qualche modo ma, dal momento che le stringhe sono immutabili, dovrei usare StringBuilder.

La mia domanda è: è comunque necessario non modificare la struttura sottostante (ad esempio utilizzando MSMQ poiché questo è qualcosa che non posso cambiare) ed evitare comunque di inizializzare una nuova stringa ogni volta per evitare di frammentare il LOH?

Grazie, Yannis

UPDATE: A proposito di come questi pezzi "lavoro" sono attualmente recuperati

Attualmente questi sono memorizzati come oggetti WorkChunk nel MSMQ. Ciascuno di questi oggetti contiene una stringa denominata Contenuto e un'altra stringa denominata Intestazioni. Questi sono dati testuali reali. Posso cambiare la struttura di archiviazione in qualcos'altro se necessario e potenzialmente il meccanismo di archiviazione sottostante se necessario per qualcos'altro rispetto a un MSMQ.

Sul lato nodi lavoratori attualmente facciamo

WorkChunk pezzo = _Queue.Receive();

Quindi c'è poco che possiamo memorizzare in questa fase. Se abbiamo cambiato la struttura (s) in qualche modo, allora suppongo che potremmo fare un po 'di progressi. In ogni caso, dovremo risolvere questo problema, quindi faremo tutto il necessario per evitare di buttare fuori mesi di lavoro.

AGGIORNAMENTO: Ho continuato a provare alcuni dei suggerimenti riportati di seguito e ho notato che questo problema non può essere riprodotto sul mio computer locale (con l'app Windows 7 x64 e 64 bit). questo rende le cose molto più difficili - se qualcuno sa perché allora sarebbe davvero utile ripubblicare questo problema localmente.

Answer 1

Il problema sembra essere dovuto all'allocazione della memoria sull'heap di un oggetto di grandi dimensioni: l'heap di oggetti di grandi dimensioni non è compattato e quindi può essere una fonte di frammentazione. C'è un buon articolo qui che entra più nel dettaglio tra cui alcuni passi di debug che è possibile seguire per confermare che la frammentazione della grande mucchio oggetto che sta accadendo:

Large Object Heap Uncovered

Si sembrano avere due tre soluzioni:

1. modificare la vostra applicazione per eseguire l'elaborazione in pezzi/stringhe più brevi, in cui ogni pezzo è più piccolo di 85.000 byte - questo evita l'assegnazione di oggetti di grandi dimensioni.
2. Modificare l'applicazione per allocare alcuni blocchi di memoria di grandi dimensioni e riutilizzare quei blocchi copiando i nuovi messaggi nella memoria allocata. Vedi Heap fragmentation when using byte arrays.
3. Lascia le cose come sono - Finché non si verificano eccezioni di memoria esaurita e l'applicazione non interferisce con altre applicazioni in esecuzione sul sistema, è probabile che si lascino le cose come sono.

sua importante comprendere la distinzione tra memoria virtuale e memoria fisica - anche se il processo utilizza una grande quantità di memoria virtuale, se il numero di oggetti allocato è relativamente bassa, allora CaM essere che la memoria fisica l'utilizzo di tale processo è basso (la memoria non utilizzata è paginata su disco), il che ha un impatto limitato su altri processi sul sistema. Potresti anche scoprire che l'opzione "Accumulazione VM" aiuta a leggere l'articolo "Oggetto di grandi dimensioni scoperto" per ulteriori informazioni.

O una modifica comporta la modifica dell'applicazione per eseguire alcuni o tutti i suoi processi utilizzando array di byte e sottostringhe brevi invece di una singola stringa di grandi dimensioni - quanto sarà difficile dipenderà da che tipo di elaborazione è che stai facendo

Answer 2

Forse è possibile creare un pool di oggetti stringa che è possibile utilizzare durante l'elaborazione del lavoro, quindi tornare al termine.

Una volta che un oggetto di grandi dimensioni è stato creato nel LOH, non può essere rimosso (AFAIK), quindi se non puoi evitare di creare questi oggetti, il piano migliore è riutilizzarli.

Se è possibile modificare il protocollo su entrambe le estremità, ridurre la stringa "Contenuto" in un gruppo di più piccoli (< 80k ciascuno) dovrebbe impedirne l'archiviazione nel LOH.

Answer 3

Quando c'è una frammentazione sul LOH, significa che ci sono oggetti assegnati su di esso. Se riesci ad annullare il ritardo, puoi attendere una volta finché tutte le attività in corso non sono terminate e chiamare GC.Collect(). Quando non ci sono oggetti di grandi dimensioni referenziati, saranno tutti raccolti, rimuovendo efficacemente la frammentazione del LOH. Ovviamente questo funziona solo se (al massimo) tutti gli oggetti di grandi dimensioni non sono referenziali.

Inoltre, anche il passaggio a un sistema operativo a 64 bit può essere d'aiuto, poiché la memoria insufficiente a causa della frammentazione è molto meno probabile che sia un problema nei sistemi a 64 bit, perché lo spazio virtuale è quasi illimitato.

Answer 4

Come utilizzare String.Intern (...) per eliminare i riferimenti duplicati. Ha una penalizzazione delle prestazioni, ma a seconda delle stringhe potrebbe avere un impatto.