Cos'è la frammentazione della memoria?

Ho sentito il termine "frammentazione della memoria" usato alcune volte nel contesto dell'allocazione dinamica della memoria C ++. Ho trovato alcune domande su come gestire la frammentazione della memoria, ma non riesco a trovare una domanda diretta che la affronti da sola. Così:

• Cos'è la frammentazione della memoria?
• Come posso sapere se la frammentazione della memoria è un problema per la mia applicazione? Che tipo di programma ha maggiori probabilità di soffrire?
• Quali sono i buoni modi comuni per gestire la frammentazione della memoria?

Anche:

• Ho sentito che usare allocazioni dinamiche molto può aumentare la frammentazione della memoria. È vero? Nel contesto di C ++, capisco che tutti i contenitori standard (std :: string, std :: vector, ecc.) Utilizzano l'allocazione dinamica della memoria. Se questi vengono utilizzati in un programma (in particolare std :: string), è più probabile che la frammentazione della memoria sia un problema?
• Come si può gestire la frammentazione della memoria in un'applicazione pesante per STL?

Immagina di avere una "grande" (32 byte) di memoria libera:

----------------------------------
|                                |
----------------------------------

Ora, alloca un po 'di esso (5 allocazioni):

----------------------------------
|aaaabbccccccddeeee              |
----------------------------------

Ora libera le prime quattro allocazioni ma non la quinta:

----------------------------------
|              eeee              |
----------------------------------

Ora prova a allocare 16 byte. Oops, non posso, anche se c'è quasi il doppio di quello gratuito.

Sui sistemi con memoria virtuale, la frammentazione è meno un problema di quanto si possa pensare, poiché le allocazioni di grandi dimensioni devono solo essere contigue nello spazio degli indirizzi virtuali , non nello spazio degli indirizzi fisici . Quindi nel mio esempio, se avessi una memoria virtuale con una dimensione della pagina di 2 byte, allora potrei effettuare la mia allocazione a 16 byte senza problemi. La memoria fisica sarebbe simile a questa:

----------------------------------
|ffffffffffffffeeeeff            |
----------------------------------

mentre la memoria virtuale (essendo molto più grande) potrebbe apparire così:

------------------------------------------------------...
|              eeeeffffffffffffffff                   
------------------------------------------------------...

Il classico sintomo della frammentazione della memoria è che si tenta di allocare un blocco di grandi dimensioni e non è possibile, anche se sembra che si disponga di memoria sufficiente. Un'altra possibile conseguenza è l'incapacità del processo di rilasciare nuovamente la memoria nel sistema operativo (poiché esiste ancora qualche oggetto in uso in tutti i blocchi che è stato allocato dal sistema operativo, anche se questi blocchi sono ora in gran parte inutilizzati).

Tattiche per prevenire la frammentazione della memoria nel C ++ funzionano allocando oggetti da aree diverse in base alle loro dimensioni e / o alla loro durata prevista. Quindi, se hai intenzione di creare molti oggetti e distruggerli tutti insieme in seguito, allocali da un pool di memoria. Qualsiasi altra allocazione effettuata tra di loro non proviene dal pool, quindi non si troverà tra loro in memoria, quindi la memoria non verrà frammentata di conseguenza.

Generalmente non è necessario preoccuparsene molto, a meno che il programma non sia di lunga durata e disponga di molte allocazioni e liberazioni. È quando hai miscele di oggetti di breve durata e di lunga durata che sei maggiormente a rischio, ma anche allora mallocfarà del suo meglio per aiutarti. Fondamentalmente, ignoralo fino a quando il tuo programma non ha errori di allocazione o causa inaspettatamente un esaurimento della memoria del sistema (prendilo nel test, per preferenza!).

Le librerie standard non sono peggio di qualsiasi altra cosa che alloca memoria e tutti i contenitori standard hanno un Allocparametro template che è possibile utilizzare per mettere a punto la loro strategia di allocazione se assolutamente necessario.

Cos'è la frammentazione della memoria?

La frammentazione della memoria si verifica quando la maggior parte della memoria viene allocata in un gran numero di blocchi o blocchi non contigui, lasciando una buona percentuale della memoria totale non allocata, ma inutilizzabile per la maggior parte degli scenari tipici. Ciò comporta eccezioni di memoria insufficiente o errori di allocazione (ovvero malloc restituisce null).

Il modo più semplice di pensarci è immaginare di avere un grande muro vuoto su cui è necessario mettere immagini di varie dimensioni . Ogni immagine occupa una certa dimensione e ovviamente non puoi dividerla in pezzi più piccoli per adattarla. Hai bisogno di un punto vuoto sul muro, delle dimensioni dell'immagine o altrimenti non puoi metterlo. Ora, se inizi a appendere le immagini sul muro e non stai attento a come disporle, presto finirai con un muro parzialmente coperto di immagini e anche se potresti avere punti vuoti la maggior parte delle nuove immagini non si adatterà perché sono più grandi dei punti disponibili. Puoi ancora appendere immagini molto piccole, ma la maggior parte non si adatta. Quindi dovrai riorganizzare (compatto) quelli già sul muro per fare spazio a più ..

Ora, immagina che il muro sia la tua memoria (heap) e che le immagini siano oggetti .. Questa è la frammentazione della memoria ..

Come posso sapere se la frammentazione della memoria è un problema per la mia applicazione? Che tipo di programma ha maggiori probabilità di soffrire?

Un segnale indicativo che potresti avere a che fare con la frammentazione della memoria è se ricevi molti errori di allocazione, specialmente quando la percentuale di memoria utilizzata è alta - ma non hai ancora esaurito tutta la memoria - quindi tecnicamente dovresti avere un sacco di spazio per gli oggetti che si sta tentando di allocare.

Quando la memoria è fortemente frammentata, le allocazioni di memoria probabilmente impiegheranno più tempo perché l'allocatore di memoria deve fare più lavoro per trovare uno spazio adatto per il nuovo oggetto. Se a sua volta hai molte allocazioni di memoria (cosa che probabilmente fai da quando hai finito con la frammentazione della memoria), il tempo di allocazione potrebbe anche causare notevoli ritardi.

Quali sono i buoni modi comuni per gestire la frammentazione della memoria?

Utilizzare un buon algoritmo per allocare memoria. Invece di allocare memoria per molti piccoli oggetti, pre-allocare memoria per un array contiguo di quegli oggetti più piccoli. A volte essere un po 'dispendioso durante l'allocazione della memoria può andare per strada per le prestazioni e può farti risparmiare il problema di dover gestire la frammentazione della memoria.

La frammentazione della memoria è lo stesso concetto della frammentazione del disco: si riferisce allo spazio sprecato perché le aree in uso non sono abbastanza vicine.

Supponiamo per un semplice esempio di giocattolo che hai dieci byte di memoria:

 |   |   |   |   |   |   |   |   |   |   |
   0   1   2   3   4   5   6   7   8   9

Ora assegniamo tre blocchi a tre byte, nome A, B e C:

 | A | A | A | B | B | B | C | C | C |   |
   0   1   2   3   4   5   6   7   8   9

Ora dealloca il blocco B:

 | A | A | A |   |   |   | C | C | C |   |
   0   1   2   3   4   5   6   7   8   9

Ora cosa succede se proviamo ad allocare un blocco a quattro byte D? Bene, abbiamo quattro byte di memoria libera, ma non abbiamo quattro byte contigui di memoria libera, quindi non possiamo allocare D! Questo è un uso inefficiente della memoria, perché avremmo dovuto essere in grado di memorizzare D, ma non siamo stati in grado di farlo. E non possiamo spostare C per fare spazio, perché molto probabilmente alcune variabili nel nostro programma indicano C, e non possiamo trovare e modificare automaticamente tutti questi valori.

Come fai a sapere che è un problema? Bene, il più grande segno è che la dimensione della memoria virtuale del tuo programma è considerevolmente più grande della quantità di memoria che stai effettivamente usando. In un esempio del mondo reale, avresti molti più di dieci byte di memoria, quindi D verrebbe allocato a partire da un byte 9 e i byte 3-5 rimarranno inutilizzati a meno che tu non assegni in seguito qualcosa di tre byte lungo o più piccolo.

In questo esempio, 3 byte non sono molto da sprecare, ma si consideri un caso più patologico in cui due allocazioni di una coppia di byte sono, ad esempio, distanti dieci megabyte in memoria ed è necessario allocare un blocco di dimensioni 10 megabyte + 1 byte. Devi andare a chiedere al sistema operativo più di dieci megabyte di memoria virtuale per farlo, anche se hai solo un byte di spazio in meno.

Come lo previeni? I casi peggiori tendono a manifestarsi quando si creano e distruggono frequentemente piccoli oggetti, poiché ciò tende a produrre un effetto "formaggio svizzero" con molti piccoli oggetti separati da molti piccoli fori, rendendo impossibile allocare oggetti più grandi in quei fori. Quando sai che lo farai, una strategia efficace è quella di pre-allocare un grande blocco di memoria come pool per i tuoi piccoli oggetti e quindi gestire manualmente la creazione di piccoli oggetti all'interno di quel blocco, piuttosto che lasciarlo l'allocatore predefinito lo gestisce.

In generale, minore è il numero di allocazioni eseguite, meno probabile è la frammentazione della memoria. Tuttavia, STL si occupa di questo piuttosto efficacemente. Se si dispone di una stringa che utilizza l'intera allocazione corrente e si aggiunge un carattere ad essa, non si riassegna semplicemente alla sua lunghezza corrente più una, ma raddoppia la lunghezza. Questa è una variazione della strategia "pool per piccole allocazioni frequenti". La stringa sta afferrando un grosso pezzo di memoria in modo che possa gestire in modo efficiente piccoli ripetuti aumenti di dimensioni senza effettuare piccole riallocazioni ripetute. Tutti i contenitori STL in effetti fanno questo genere di cose, quindi generalmente non dovrai preoccuparti troppo della frammentazione causata dalla riallocazione automatica dei contenitori STL.

Anche se ovviamente i contenitori STL non mettono in comune la memoria tra loro, quindi se hai intenzione di creare molti piccoli contenitori (anziché alcuni contenitori che vengono ridimensionati frequentemente) potresti doverti preoccupare di prevenire la frammentazione nello stesso modo in cui sarebbe per qualsiasi piccolo oggetto creato di frequente, STL o no.

• Cos'è la frammentazione della memoria?

La frammentazione della memoria è il problema che la memoria diventa inutilizzabile anche se teoricamente disponibile. Esistono due tipi di frammentazione: la frammentazione interna è la memoria allocata ma che non può essere utilizzata (ad es. Quando la memoria è allocata in blocchi di 8 byte, ma il programma esegue ripetutamente singole segnalazioni quando necessita di soli 4 byte). la frammentazione esterna è il problema della suddivisione della memoria libera in molti piccoli blocchi, in modo tale che le richieste di allocazione di grandi dimensioni non possano essere soddisfatte sebbene la memoria libera complessiva sia sufficiente.

• Come posso sapere se la frammentazione della memoria è un problema per la mia applicazione? Che tipo di programma ha maggiori probabilità di soffrire?

la frammentazione della memoria è un problema se il tuo programma utilizza molta più memoria di sistema di quanto richiederebbe i suoi dati paylod (e hai escluso perdite di memoria).

• Quali sono i buoni modi comuni per gestire la frammentazione della memoria?

Utilizzare un buon allocatore di memoria. IIRC, quelli che usano una strategia di "miglior adattamento" sono generalmente molto superiori nell'evitare la frammentazione, anche se un po 'più lenti. Tuttavia, è stato anche dimostrato che per qualsiasi strategia di allocazione, ci sono casi peggiori patologici. Fortunatamente, i modelli di allocazione tipici della maggior parte delle applicazioni sono in realtà relativamente benigni da gestire per gli allocatori. Ci sono un sacco di documenti là fuori se sei interessato ai dettagli:

• Paul R. Wilson, Mark S. Johnstone, Michael Neely e David Boles. Allocazione dinamica dello storage: un'indagine e una revisione critica. In Atti del Workshop internazionale sulla gestione della memoria del 1995, Springer Verlag LNCS, 1995
• Mark S.Johnstone, Paul R. Wilson. Il problema della frammentazione della memoria: risolto? Nelle note ACM SIG-PLAN, volume 34 n. 3, pagine 26-36, 1999
• MR Garey, RL Graham e JD Ullman. Analisi dei casi peggiori degli algoritmi di allocazione della memoria. Nel quarto simposio annuale ACM sulla teoria dell'informatica, 1972

Aggiornamento:
Google TCMalloc: Thread-Caching Malloc
È stato trovato che è abbastanza bravo a gestire la frammentazione in un lungo processo.

Ho sviluppato un'applicazione server che ha avuto problemi con la frammentazione della memoria su HP-UX 11.23 / 11.31 ia64.

Sembrava così. C'è stato un processo che ha fatto allocazioni di memoria e deallocazioni e ha funzionato per giorni. E anche se non c'erano perdite di memoria, il consumo di memoria del processo continuava ad aumentare.

Sulla mia esperienza. Su HP-UX è molto facile trovare la frammentazione della memoria usando HP-UX gdb. Imposti un punto di interruzione e quando lo colpisci esegui questo comando: info heape vedi tutte le allocazioni di memoria per il processo e la dimensione totale dell'heap. Quindi continui il tuo programma e dopo qualche tempo raggiungi di nuovo il punto di rottura. Lo fai di nuovo info heap. Se la dimensione totale dell'heap è maggiore ma il numero e la dimensione delle allocazioni separate sono uguali, è probabile che si verifichino problemi di allocazione della memoria. Se necessario, fare questo controllo alcune volte in anticipo.

Il mio modo di migliorare la situazione era questo. Dopo aver fatto alcune analisi con HP-UX gdb ho visto che i problemi di memoria erano causati dal fatto che avevo usato std::vectorper archiviare alcuni tipi di informazioni da un database. std::vectorrichiede che i suoi dati debbano essere conservati in un blocco. Ho avuto alcuni contenitori basati su std::vector. Questi contenitori sono stati regolarmente ricreati. Ci sono state spesso situazioni in cui sono stati aggiunti nuovi record al database e successivamente sono stati ricreati i contenitori. E poiché i contenitori ricreati erano più grandi, non si adattavano ai blocchi disponibili di memoria libera e il runtime richiedeva un nuovo blocco più grande dal sistema operativo. Di conseguenza, sebbene non vi siano perdite di memoria, il consumo di memoria del processo è aumentato. Ho migliorato la situazione quando ho cambiato i contenitori. Invece di std::vectoriniziare a usarestd::deque che ha un modo diverso di allocare memoria per i dati.

So che uno dei modi per evitare la frammentazione della memoria su HP-UX è usare Small Block Allocator o usare MallocNextGen. Su RedHat Linux l'allocatore predefinito sembra gestire abbastanza bene l'allocazione di molti piccoli blocchi. Su Windows c'è Low-fragmentation Heape risolve il problema di un gran numero di piccole allocazioni.

La mia comprensione è che in un'applicazione pesante STL devi prima identificare i problemi. Gli allocatori di memoria (come in libc) in realtà gestiscono il problema di molte piccole allocazioni, il che è tipico per std::string(ad esempio nella mia applicazione server ci sono molte stringhe STL ma, come vedo, info heapnon stanno causando alcun problema). La mia impressione è che è necessario evitare frequenti allocazioni di grandi dimensioni. Sfortunatamente ci sono situazioni in cui non puoi evitarle e devi cambiare il tuo codice. Come ho detto nel mio caso, ho migliorato la situazione quando sono passati a std::deque. Se identifichi la tua frammentazione della memoria, potrebbe essere possibile parlarne in modo più preciso.

È molto probabile che si verifichi la frammentazione della memoria quando si allocano e si deallocano molti oggetti di dimensioni variabili. Supponiamo di avere il seguente layout in memoria:

obj1 (10kb) | obj2(20kb) | obj3(5kb) | unused space (100kb)

Ora, quando obj2viene rilasciato, hai 120 kb di memoria inutilizzata, ma non puoi allocare un blocco completo di 120 kb, perché la memoria è frammentata.

Tecniche comuni per evitare tale effetto includono ring buffer e pool di oggetti . Nel contesto della STL, metodi come std::vector::reserve()possono aiutare.

Una risposta molto dettagliata sulla frammentazione della memoria è disponibile qui.

http://library.softwareverify.com/memory-fragmentation-your-worst-nightmare/

Questo è il culmine di 11 anni di risposte sulla frammentazione della memoria che ho fornito alle persone che mi ponevano domande sulla frammentazione della memoria su softwareverify.com

Cos'è la frammentazione della memoria?

Quando l'app utilizza la memoria dinamica, alloca e libera pezzi di memoria. All'inizio, l'intero spazio di memoria della tua app è un blocco contiguo di memoria libera. Tuttavia, quando si allocano e si liberano blocchi di dimensioni diverse, la memoria inizia a essere frammentata , ovvero invece di un grande blocco libero contiguo e un numero di blocchi allocati contigui, ci saranno un blocco di blocchi allocati e liberi. Poiché i blocchi liberi hanno dimensioni limitate, è difficile riutilizzarli. Ad esempio potresti avere 1000 byte di memoria libera, ma non puoi allocare memoria per un blocco di 100 byte, perché tutti i blocchi liberi sono lunghi al massimo 50 byte.

Un'altra fonte inevitabile, ma meno problematica, di frammentazione è che nella maggior parte delle architetture, gli indirizzi di memoria devono essere allineati a 2, 4, 8 ecc. Limiti di byte (ovvero gli indirizzi devono essere multipli di 2, 4, 8 ecc.) Ciò significa che anche se hai ad esempio una struttura contenente 3 charcampi, la tua struttura può avere una dimensione di 12 anziché 3, a causa del fatto che ogni campo è allineato a un limite di 4 byte.

Come posso sapere se la frammentazione della memoria è un problema per la mia applicazione? Che tipo di programma ha maggiori probabilità di soffrire?

La risposta ovvia è che si ottiene un'eccezione di memoria insufficiente.

Apparentemente non esiste un buon modo portatile per rilevare la frammentazione della memoria nelle app C ++. Vedi questa risposta per maggiori dettagli.

Quali sono i buoni modi comuni per gestire la frammentazione della memoria?

È difficile in C ++, poiché si utilizzano indirizzi di memoria diretti nei puntatori e non si ha il controllo su chi fa riferimento a un indirizzo di memoria specifico. Quindi riorganizzare i blocchi di memoria allocati (come fa il garbage collector di Java) non è un'opzione.

Un allocatore personalizzato può aiutare gestendo l'allocazione di piccoli oggetti in un blocco di memoria più grande e riutilizzando gli slot liberi all'interno di quel blocco.

Questa è una versione super semplificata per i manichini.

Man mano che gli oggetti vengono creati in memoria, vengono aggiunti alla fine della porzione utilizzata in memoria.

Se un oggetto che non si trova alla fine della porzione di memoria utilizzata viene eliminato, il che significa che questo oggetto si trovava tra altri 2 oggetti, creerà un "buco".

Questo è ciò che si chiama frammentazione.

Quando si desidera aggiungere un elemento nell'heap, ciò che accade è che il computer deve effettuare una ricerca dello spazio per adattarlo a tale elemento. Ecco perché le allocazioni dinamiche quando non vengono eseguite su un pool di memoria o con un allocatore in pool possono "rallentare" le cose. Per un'applicazione STL pesante se stai eseguendo il multi-threading c'è l' allocatore Hoard o la versione Intel TBB .

Ora, quando la memoria è frammentata, possono accadere due cose:

1. Dovranno esserci più ricerche per trovare un buon spazio per attaccare oggetti "grandi". Cioè, con molti piccoli oggetti sparsi per trovare un bel pezzo di memoria contiguo in determinate condizioni potrebbe essere difficile (questi sono estremi).
2. La memoria non è un'entità facilmente leggibile. I processori sono limitati a quanto possono contenere e dove. Lo fanno scambiando pagine se un elemento di cui hanno bisogno è un posto ma gli indirizzi correnti sono un altro. Se devi costantemente scambiare pagine, l'elaborazione può rallentare (di nuovo, scenari estremi in cui ciò influisce sulle prestazioni). Vedi questo post nella memoria virtuale .

La frammentazione della memoria si verifica perché sono richiesti blocchi di memoria di dimensioni diverse. Si consideri un buffer di 100 byte. Si richiedono due caratteri, quindi un numero intero. Ora liberate i due caratteri, quindi richiedete un nuovo numero intero, ma quel numero intero non può rientrare nello spazio dei due caratteri. Quella memoria non può essere riutilizzata perché non si trova in un blocco contiguo abbastanza grande da riassegnare. Inoltre, hai invocato molte spese generali di allocazione per i tuoi caratteri.

Fondamentalmente, la memoria arriva solo in blocchi di una certa dimensione sulla maggior parte dei sistemi. Una volta divisi questi blocchi, non possono essere riuniti fino a quando l'intero blocco non viene liberato. Questo può portare a interi blocchi in uso quando in realtà solo una piccola parte del blocco è in uso.

Il modo principale per ridurre la frammentazione dell'heap è quello di effettuare allocazioni più grandi e meno frequenti. In estrema misura, è possibile utilizzare un heap gestito in grado di spostare oggetti, almeno, all'interno del proprio codice. Questo elimina completamente il problema - dal punto di vista della memoria, comunque. Ovviamente oggetti in movimento e simili hanno un costo. In realtà, hai davvero un problema solo se stai allocando quantità molto piccole dall'heap spesso. L'uso di contenitori contigui (vettore, stringa, ecc.) E l'allocazione nello stack il più umanamente possibile (sempre una buona idea per le prestazioni) è il modo migliore per ridurlo. Ciò aumenta anche la coerenza della cache, rendendo l'applicazione più veloce.

Quello che dovresti ricordare è che su un sistema desktop x86 a 32 bit, hai un intero 2GB di memoria, che è diviso in "pagine" 4KB (abbastanza sicuro che la dimensione della pagina è la stessa su tutti i sistemi x86). Dovrai invocare qualche frammentazione di omgwtfbbq per avere un problema. La frammentazione è davvero un problema del passato, dal momento che i cumuli moderni sono eccessivamente grandi per la stragrande maggioranza delle applicazioni e c'è una prevalenza di sistemi che sono in grado di resistere, come i cumuli gestiti.

Che tipo di programma ha maggiori probabilità di soffrire?

Un bell'esempio (= orribile) per i problemi associati alla frammentazione della memoria è stato lo sviluppo e il rilascio di "Elemental: War of Magic" , un gioco per computer di Stardock .

Il gioco è stato creato per la memoria a 32 bit / 2 GB e ha dovuto fare molta ottimizzazione nella gestione della memoria per far funzionare il gioco all'interno di quei 2 GB di memoria. Poiché l '"ottimizzazione" porta a una costante allocazione e disallocazione, nel tempo si è verificata una frammentazione della memoria dell'heap che ha causato il crash del gioco ogni volta .

C'è un'intervista "storia di guerra" su YouTube.