Come funziona vm.overcommit_memory?


50

Quando utilizzo le impostazioni predefinite:

vm.overcommit_memory = 0
vm.overcommit_ratio = 50

Posso leggere questi valori dal /proc/meminfofile:

CommitLimit:     2609604 kB
Committed_AS:    1579976 kB

Ma quando cambio vm.overcommit_memoryda 0a 2, non riesco ad avviare lo stesso set di applicazioni che potrei iniziare prima della modifica, specialmente amarok. Ho dovuto passare vm.overcommit_ratioa 300, quindi il limite potrebbe essere aumentato. Ora quando avvio amarok, /proc/meminfomostra quanto segue:

CommitLimit:     5171884 kB
Committed_AS:    3929668 kB

Questa macchina ha solo 1GiB di RAM, ma amarok funziona senza problemi quando vm.overcommit_memoryè impostato su 0. Ma nel caso di impostarlo su 2, amarok deve allocare oltre 2GiB di memoria. È un comportamento normale? In tal caso, qualcuno potrebbe spiegare perché, ad esempio, Firefox (che consuma 4-6 volte più memoria di Amarok) funziona allo stesso modo prima e dopo la modifica?

Risposte:


67

Puoi trovare la documentazione in man 5 proc( o su kernel.org ):

/proc/sys/vm/overcommit_memory
       This file contains the kernel virtual memory accounting mode.
       Values are:

              0: heuristic overcommit (this is the default)
              1: always overcommit, never check
              2: always check, never overcommit

       In mode 0, calls of mmap(2) with MAP_NORESERVE are not
       checked, and the default check is very weak, leading to the
       risk of getting a process "OOM-killed".

       In mode 2 (available since Linux 2.6), the total virtual
       address space that can be allocated (CommitLimit in /proc/mem‐
       info) is calculated as

           CommitLimit = (total_RAM - total_huge_TLB) *
                         overcommit_ratio / 100 + total_swap

La semplice risposta è che l'impostazione di overcommit su 1, imposterà il palcoscenico in modo che quando un programma chiama qualcosa di simile malloc()allocare un pezzo di memoria ( man 3 malloc), avrà sempre successo indipendentemente dal fatto che il sistema sappia che non avrà tutta la memoria che viene ha chiesto per.

Il concetto alla base da comprendere è l'idea della memoria virtuale . I programmi visualizzano uno spazio di indirizzi virtuale che può o non può essere mappato alla memoria fisica effettiva. Disabilitando il controllo overcommit, si dice al sistema operativo di supporre che ci sia sempre abbastanza memoria fisica per eseguire il backup dello spazio virtuale.

Esempio

Per evidenziare il motivo per cui a volte questo può importare, dai un'occhiata alle guide di Redis sul perché vm.overcommit_memorydovrebbe essere impostato su 1 per questo.


2
Ma il valore di non dovrebbe Committed_ASessere lo stesso in entrambi i casi?
Mikhail Morfikov,

@MikhailMorfikov: In teoria, credo di si, ma chissà cosa stanno facendo questi programmi. Vorrebbe vedere un ambiente più controllato con un semplice programma che alloca semplicemente dire un concerto di ram tramite Malloc. E quindi eseguire il test dopo il riavvio tra i test.
Kyle Brandt,

Ok, quindi rimarrò con 0per ora.
Mikhail Morfikov,

2
@MikhailMorfikov: Sì, praticamente penso che 0 abbia più senso. Nel mio ambiente, l'unica volta che abilito 1 è per Redis, che fa cose dove si aspetta che richieda molta più memoria che sta usando a causa di un fork (). Il bambino userà praticamente tutte le stesse pagine di memoria, ma Linux non sa che per sicurezza è necessario supporre che venga utilizzata la memoria 2x (se vuoi saperne di più: redis.io/topics/faq )
Kyle Brandt,

l'ultima affermazione nella tua risposta non dovrebbe iniziare come "abilitando il sovraccarico"? perché impostandolo su 1 significa che stai chiedendo di overcommit, giusto?
as
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.