Berechnung des freien RAMs

[king-crash]

Hallo,

/proc/meminfo sieht bei mir wie folgt aus: 42219
MemAvailable ist nur bei 24G, was mir deutlich zu wenig vorkommt. Committed_AS ist allerdings bei 10G, was eigentlich 54G freien Speicher bedeuten sollte. Das wäre für mich auch plausibel.
Rechne ich den Speicher von Prozessen zusammen ("ps -A afu | awk '{s+=$6} END {print s}'") komme ich auf 6,7G.
Eigentlich hätte ich erwartet, dass "MemTotal - Committed_AS = MemAvailable" wenigstens näherungsweise gelten müsste. Hat jemand eine Idee, woher dieser große Unterschied kommt?

Grüße

[cosinus]

Cached: 2356068 kB

Hast du das berücksichtigt?

[king-crash]

"Cached" sind nur 2,3G. Der Unterschied ist aber um die 30G.

[king-crash]

Ein Test ergibt folgendes:
- MemAvailable zu Beginn: 33G
- 35G Speicher reservieren und beschreiben mit Testprogramm 42221, welches dann mit sleep stehen bleibt
- Während der Speicher beschrieben wird, sinkt MemAvailable auf 250M
- Nach dem Beschreiben im sleep Aufruf steht in MemAvailable plötzlich wieder 2G
- Nach beenden des Programms ist MemAvailable auf 36G angewachsen

Sind da in MemAvailable doch noch irgendwelche Caches nicht berücksichtigt? Ich dachte eigentlich das sollte da schon der Fall sein?
Overcommit ist aus (/proc/sys/vm/overcommit_memory -> 2).

[debra]

Zu 42221: Du nutzt da malloc. Das ist nur eine Funktion der glibc, die Speicher in großen Blöcken alloziert und dann stückchenweise heraus gibt. Umgekehrt behält sie den bei free() für den Fall, dass er wieder genutzt werden könnte. So spart man viele mmap/(s)brk

[king-crash]

Zu 42221: Du nutzt da malloc. Das ist nur eine Funktion der glibc, die Speicher in großen Blöcken alloziert und dann stückchenweise heraus gibt. Umgekehrt behält sie den bei free() für den Fall, dass er wieder genutzt werden könnte. So spart man viele mmap/(s)brk

Das ist falsch.
Bei einem beispielhafen Aufruf von malloc mit 1G wird genau einmal "mmap" aufgerufen. Ein anschließendes free benutzt ein einzelnes "munmap" mit genau der gleichen Größe.

[debra]

Bei einem beispielhafen

Nein der ist vermutlich alles andere als beispielhaft. Er wird vermutlich in nem Kontext von nem Programm aufgerufen worden sein, dass noch nie zuvor alloziert hat, hat eine genaue Größe von von Pages und ist garantiert so riesig, dass nicht schon ausreichend reserviert wurde.

[cosinus]

"Cached" sind nur 2,3G. Der Unterschied ist aber um die 30G.

Stimmt, sind nur um die 2 GB. Was sagen denn free und top?

[king-crash]

@debra
Ich habe ein Minimalprogramm geschrieben, das Speicher anfordert und beschreibt, um die Werte in /proc/meminfo zu verstehen. Mir ist nicht klar, was du mit deinem Eingangspost sagen willst.

@cosinus
42226

[reox]

Eigentlich hätte ich erwartet, dass "MemTotal - Committed_AS = MemAvailable" wenigstens näherungsweise gelten müsste. Hat jemand eine Idee, woher dieser große Unterschied kommt?

Eine genaue Beschreibung der Felder gibts hier: https://git.kernel.org/pub/scm/linux/ke ... da773#n757
Da steht dann:

MemAvailable: An estimate of how much memory is available for starting new
applications, without swapping. Calculated from MemFree,
SReclaimable, the size of the file LRU lists, and the low
watermarks in each zone.
The estimate takes into account that the system needs some
page cache to function well, and that not all reclaimable
slab will be reclaimable, due to items being in use. The
impact of those factors will vary from system to system.

Committed_AS: The amount of memory presently allocated on the system.
The committed memory is a sum of all of the memory which
has been allocated by processes, even if it has not been
"used" by them as of yet. A process which malloc()'s 1G
of memory, but only touches 300M of it will show up as
using 1G. This 1G is memory which has been "committed" to
by the VM and can be used at any time by the allocating
application. With strict overcommit enabled on the system
(mode 2 in 'vm.overcommit_memory'),allocations which would
exceed the CommitLimit (detailed above) will not be permitted.
This is useful if one needs to guarantee that processes will
not fail due to lack of memory once that memory has been
successfully allocated.

(Hervorhebung von mir)
Commited_AS beschreibt genau das was debra meint.

[king-crash]

Mir ist dieser Text bekannt. Demnach ist Committed_AS die Maximalmenge von Speicher, die schlimmstenfalls benötigt werden kann.
Wie kann jetzt aber MemTotal - MemAvailable wesentlich größer als Committed_AS sein?
Wieso kann ich ohne overcommit mehr als MemAvailable reservieren?
Wieso wird MemAvailable nach diesem Reservieren und wieder Freigeben größer als zuvor?

[reox]

Wie gesagt, MemAvailable ist eine Schätzung. Was genau da berechnet wird siehst du hier: https://github.com/torvalds/linux/blob/ ... .c#L32-L73
Vermutlich kannst du dir eine Funktion schreiben die genau diese Dinge tracked und dann siehst du welche der Variablen ausschlaggebend ist... Genau kann ich dir das leider auch nicht erklären.