Vraag Hoe werkt vm.overcommit_memory?


Wanneer ik de standaardinstellingen gebruik:

vm.overcommit_memory = 0
vm.overcommit_ratio = 50

Ik kan deze waarden lezen van /proc/meminfo het dossier:

CommitLimit:     2609604 kB
Committed_AS:    1579976 kB

Maar als ik verander vm.overcommit_memory van 0 naar 2, Ik kan niet dezelfde reeks applicaties starten die ik vóór de wijziging kon starten, met name amarok. Ik moest veranderen vm.overcommit_ratio naar 300, dus de limiet kan worden verhoogd. Wanneer ik nu amarok start, /proc/meminfo toont het volgende:

CommitLimit:     5171884 kB
Committed_AS:    3929668 kB

Deze machine heeft slechts 1GiB aan RAM, maar amarok werkt zonder problemen wanneer vm.overcommit_memory is ingesteld op 0. Maar in het geval van het instellen op 2, amarok moet meer dan 2GiB aan geheugen toewijzen. Is het een normaal gedrag? Zo ja, kan iemand dan verklaren waarom firefox (dat 4-6x meer geheugen verbruikt dan amarok) op dezelfde manier werkt vóór en na de wijziging?


41
2018-06-18 17:27


oorsprong




antwoorden:


U kunt de documentatie vinden in man 5 proc (of op 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

Het simpele antwoord is dat het instellen van overcommit tot 1, het stadium zal instellen, zodat wanneer een programma iets als roept malloc() om een ​​geheugenblok toe te wijzen (man 3 malloc), het zal altijd lukken, ongeacht of het systeem weet dat het niet al het geheugen heeft dat gevraagd wordt.

Het onderliggende begrip om te begrijpen is het idee van virtueel geheugen. Programma's zien een virtuele adresruimte die wel of niet kan worden toegewezen aan het feitelijke fysieke geheugen. Door overcommitcontrole uit te schakelen, vertel je het besturingssysteem om er gewoon van uit te gaan dat er altijd voldoende fysiek geheugen is om een ​​back-up te maken van de virtuele ruimte.

Voorbeeld

Om te benadrukken waarom dit soms van belang kan zijn, kijk eens naar de Redis guidances over waarom vm.overcommit_memory moet hiervoor op 1 worden ingesteld.


56
2018-06-18 17:49



Maar zou niet de waarde van moeten zijn Committed_AS in beide gevallen hetzelfde zijn? - Mikhail Morfikov
@MikhailMorfikov: In theorie denk ik van wel, maar wie weet wat deze programma's doen. Zou een meer gecontroleerde omgeving willen zien met een eenvoudig programma dat slechts een gig van ram toewijst via Malloc. En voer de test uit na opnieuw opstarten tussen tests. - Kyle Brandt♦
Ok, dus ik blijf bij 0 voor nu. - Mikhail Morfikov
@MikhailMorfikov: Ja, praktisch denk ik dat 0 het meest logisch is. In mijn omgeving is de enige keer dat ik 1 inschakel voor Redis, wat dingen doet waar het is verwacht vragen om veel meer geheugen dat het gebruikt als gevolg van een vork (). Het kind zal vrijwel alle geheugenpagina's gebruiken, maar Linux weet niet dat er volgens hem veilig moet worden aangenomen dat er 2x geheugen wordt gebruikt (als je meer wilt weten: redis.io/topics/faq) - Kyle Brandt♦
zou niet de laatste verklaring in uw antwoord moeten beginnen zoals "door overcommit te activeren"? omdat het instellen op 1 betekent dat je het vraagt ​​om overcommit, toch? - asgs