Warum frisst dieser Speicherfresser nicht wirklich Speicher?

Ich möchte ein Programm erstellen, das eine Out-of-Memory-Situation (OOM) auf einem Unix-Server simuliert. Ich habe diesen supereinfachen Speicherfresser erstellt:

#include <stdio.h>
#include <stdlib.h>

unsigned long long memory_to_eat = 1024 * 50000;
size_t eaten_memory = 0;
void *memory = NULL;

int eat_kilobyte()
{
    memory = realloc(memory, (eaten_memory * 1024) + 1024);
    if (memory == NULL)
    {
        // realloc failed here - we probably can't allocate more memory for whatever reason
        return 1;
    }
    else
    {
        eaten_memory++;
        return 0;
    }
}

int main(int argc, char **argv)
{
    printf("I will try to eat %i kb of ram\n", memory_to_eat);
    int megabyte = 0;
    while (memory_to_eat > 0)
    {
        memory_to_eat--;
        if (eat_kilobyte())
        {
            printf("Failed to allocate more memory! Stucked at %i kb :(\n", eaten_memory);
            return 200;
        }
        if (megabyte++ >= 1024)
        {
            printf("Eaten 1 MB of ram\n");
            megabyte = 0;
        }
    }
    printf("Successfully eaten requested memory!\n");
    free(memory);
    return 0;
}

Es frisst so viel Speicher wie in definiert memory_to_eat das sind jetzt genau 50 GB RAM. Es weist Speicher um 1 MB zu und druckt genau den Punkt, an dem es nicht mehr zuordnen kann, damit ich weiß, welchen maximalen Wert es essen konnte.

Das Problem ist, dass es funktioniert. Selbst auf einem System mit 1 GB physischem Speicher.

Wenn ich nach oben schaue, sehe ich, dass der Prozess 50 GB virtuellen Speicher und nur weniger als 1 MB residenten Speicher verbraucht. Gibt es eine Möglichkeit, einen Speicherfresser zu erstellen, der ihn wirklich verbraucht?

Systemspezifikationen: Linux-Kernel 3.16 (Debian) höchstwahrscheinlich mit aktiviertem Overcommit (nicht sicher, wie man es auscheckt), ohne Swap und virtualisiert.

Wenn dein malloc() -Implementierung fordert Speicher vom Systemkern an (über eine sbrk() oder mmap() Systemaufruf), merkt sich der Kernel nur, dass Sie den Speicher angefordert haben und wo er in Ihrem Adressraum platziert werden soll. Es bildet diese Seiten noch nicht ab.

Wenn der Prozess anschließend auf Speicher innerhalb der neuen Region zugreift, erkennt die Hardware einen Segmentierungsfehler und macht den Kernel auf den Zustand aufmerksam. Der Kernel sucht dann die Seite in seinen eigenen Datenstrukturen und stellt fest, dass Sie dort eine Nullseite haben sollten, also ordnet er eine Nullseite zu (womöglich zuerst eine Seite aus dem Seitencache entfernen) und kehrt vom Interrupt zurück. Ihr Prozess erkennt nicht, dass irgendetwas davon passiert ist, die Kernel-Operation ist vollkommen transparent (mit Ausnahme der kurzen Verzögerung, während der Kernel seine Arbeit erledigt).

Diese Optimierung ermöglicht es, dass der Systemaufruf sehr schnell zurückkehrt, und, was am wichtigsten ist, es vermeidet, dass irgendwelche Ressourcen Ihrem Prozess zugewiesen werden, wenn das Mapping durchgeführt wird. Dadurch können Prozesse ziemlich große Puffer reservieren, die sie unter normalen Umständen nie benötigen, ohne befürchten zu müssen, zu viel Speicher zu verschlingen.

Wenn Sie also einen Speicherfresser programmieren möchten, müssen Sie unbedingt etwas mit dem zugewiesenen Speicher tun. Dazu müssen Sie Ihrem Code nur eine einzige Zeile hinzufügen:

int eat_kilobyte()
{
    if (memory == NULL)
        memory = malloc(1024);
    else
        memory = realloc(memory, (eaten_memory * 1024) + 1024);
    if (memory == NULL)
    {
        return 1;
    }
    else
    {
        //Force the kernel to map the containing memory page.
        ((char*)memory)[1024*eaten_memory] = 42;

        eaten_memory++;
        return 0;
    }
}

Beachten Sie, dass es völlig ausreichend ist, auf ein einzelnes Byte innerhalb jeder Seite zu schreiben (das auf X86 4096 Bytes enthält). Das liegt daran, dass die gesamte Speicherzuweisung vom Kernel zu einem Prozess mit Speicherseitengranularität erfolgt, was wiederum an der Hardware liegt, die Paging mit kleineren Granularitäten nicht zulässt.

Alle virtuellen Seiten beginnen mit Copy-on-Write, die auf dieselbe genullte physische Seite abgebildet werden. Um physische Seiten zu verbrauchen, können Sie sie verschmutzen, indem Sie etwas auf jede virtuelle Seite schreiben.

Wenn Sie als Root ausgeführt werden, können Sie verwenden mlock(2) oder mlockall(2) um den Kernel die Seiten verkabeln zu lassen, wenn sie zugewiesen sind, ohne sie verschmutzen zu müssen. (Normale Nicht-Root-Benutzer haben eine ulimit -l von nur 64 KB.)

Wie viele andere angedeutet haben, scheint der Linux-Kernel den Speicher nicht wirklich zuzuweisen, es sei denn, Sie schreiben darauf

Eine verbesserte Version des Codes, die das tut, was das OP wollte:

Dies behebt auch die Nichtübereinstimmungen der Zeichenfolgen im printf-Format mit den Typen memory_to_eat und eaten_memory, using %zi zu drucken size_t ganze Zahlen. Die zu fressende Speichergröße in KiB kann optional als Befehlszeilenargument angegeben werden.

Das chaotische Design, das globale Variablen verwendet und um 1.000 statt 4.000 Seiten wächst, bleibt unverändert.

#include <stdio.h>
#include <stdlib.h>

size_t memory_to_eat = 1024 * 50000;
size_t eaten_memory = 0;
char *memory = NULL;

void write_kilobyte(char *pointer, size_t offset)
{
    int size = 0;
    while (size < 1024)
    {   // writing one byte per page is enough, this is overkill
        pointer[offset + (size_t) size++] = 1;
    }
}

int eat_kilobyte()
{
    if (memory == NULL)
    {
        memory = malloc(1024);
    } else
    {
        memory = realloc(memory, (eaten_memory * 1024) + 1024);
    }
    if (memory == NULL)
    {
        return 1;
    }
    else
    {
        write_kilobyte(memory, eaten_memory * 1024);
        eaten_memory++;
        return 0;
    }
}

int main(int argc, char **argv)
{
    if (argc >= 2)
        memory_to_eat = atoll(argv[1]);

    printf("I will try to eat %zi kb of ram\n", memory_to_eat);
    int megabyte = 0;
    int megabytes = 0;
    while (memory_to_eat-- > 0)
    {
        if (eat_kilobyte())
        {
            printf("Failed to allocate more memory at %zi kb :(\n", eaten_memory);
            return 200;
        }
        if (megabyte++ >= 1024)
        {
            megabytes++;
            printf("Eaten %i  MB of ram\n", megabytes);
            megabyte = 0;
        }
    }
    printf("Successfully eaten requested memory!\n");
    free(memory);
    return 0;
}

Hier wird eine sinnvolle Optimierung vorgenommen. Die Laufzeit eigentlich nicht erwerben den Speicher, bis Sie ihn verwenden.

Eine einfache memcpy ausreichen, um diese Optimierung zu umgehen. (Vielleicht finden Sie das calloc optimiert immer noch die Speicherzuweisung bis zum Verwendungspunkt.)

Ich bin mir nicht sicher, aber die einzige Erklärung, die ich mir vorstellen kann, ist, dass Linux ein Copy-on-Write-Betriebssystem ist. Wenn einer anruft fork die beiden Prozesse zeigen auf denselben physikalischen Speicher. Der Speicher wird nur kopiert, sobald ein Prozess tatsächlich in den Speicher SCHREIBT.

Ich denke, hier wird der eigentliche physikalische Speicher nur zugewiesen, wenn man versucht, etwas darauf zu schreiben. Berufung sbrk oder mmap möglicherweise nur die Speicherbuchhaltung des Kernels aktualisieren. Der tatsächliche Arbeitsspeicher wird möglicherweise nur zugewiesen, wenn wir tatsächlich versuchen, auf den Speicher zuzugreifen.

Grundlegende Antwort

Wie von anderen erwähnt, belegt die Zuweisung von Speicher bis zur Verwendung nicht immer den erforderlichen RAM. Dies passiert, wenn Sie einen Puffer zuweisen, der größer als eine Seite ist (normalerweise 4 KB unter Linux).

Eine einfache Antwort wäre, dass Ihre “Eat Memory”-Funktion immer 1 KB anstelle von immer größeren Blöcken zuweist. Dies liegt daran, dass jeder zugewiesene Block mit einem Header (einer Größe für zugewiesene Blöcke) beginnt. Wenn Sie also einen Puffer mit einer Größe kleiner oder gleich einer Seite zuweisen, werden immer alle diese Seiten festgeschrieben.

Nach Ihrer Idee

Um Ihren Code so weit wie möglich zu optimieren, möchten Sie Speicherblöcke zuweisen, die auf die Größe einer Seite ausgerichtet sind.

Soweit ich in Ihrem Code sehen kann, verwenden Sie 1024. Ich würde vorschlagen, dass Sie Folgendes verwenden:

int size;

size = getpagesize();

block_size = size - sizeof(void *) * 2;

Was ist das für ein Voodoo-Zauber sizeof(void *) * 2?! Bei Verwendung der standardmäßigen Speicherzuweisungsbibliothek (z nicht SAN, fence, valgrin, …), befindet sich kurz vor dem zurückgegebenen Zeiger ein kleiner Header malloc() die einen Zeiger auf den nächsten Block und eine Größe enthält.

struct mem_header { void * next_block; intptr_t size; };

Jetzt mit block_sizeall dein malloc() sollte an der zuvor ermittelten Seitengröße ausgerichtet sein.

Wenn Sie alles richtig ausrichten möchten, muss die erste Zuordnung eine ausgerichtete Zuordnung verwenden:

char *p = NULL;
int posix_memalign(&p, size, block_size);

Weitere Zuweisungen (vorausgesetzt, Ihr Tool macht das nur) können verwendet werden malloc(). Sie werden ausgerichtet.

p = malloc(block_size);

Hinweis: Bitte überprüfen Sie, ob es tatsächlich auf Ihrem System ausgerichtet ist … es funktioniert auf meinem.

Als Ergebnis können Sie Ihre Schleife vereinfachen mit:

for(;;)
{
    p = malloc(block_size);
    *p = 1;
}

Bis Sie einen Thread erstellen, die malloc() verwendet keine Mutexe. Es muss aber noch nach einem freien Speicherblock suchen. In Ihrem Fall wird es jedoch nacheinander sein und es wird keine Löcher im zugewiesenen Speicher geben, also wird es ziemlich schnell sein.

Kann es schneller sein?

Weitere Anmerkung zur allgemeinen Speicherallokation in einem Unix-System:

• das malloc() Funktion und verwandte Funktionen weisen einen Block in Ihrem Heap zu; was am Anfang ziemlich klein ist (vielleicht 2 MB)

• wenn der vorhandene Haufen ist voll es wird mit dem angebaut sbrk() Funktion; Was Ihren Prozess betrifft, erhöht sich die Speicheradresse immer, das ist was sbrk() tut (im Gegensatz zu MS-Windows, das überall Blöcke zuweist)

• verwenden sbrk() einmal und dann den Speicher alle “Seitengröße” Bytes zu treffen, wäre schneller als die Verwendung malloc()

  char * p = malloc(size); // get current "highest address"
  
  p += size;
  p = (char*)((intptr_t)p & -size);  // clear bits (alignment)
  
  int total_mem(50 * 1024 * 1024 * 1024); // 50Gb
  void * start(sbrk(total_mem));
  
  char * end((char *)start + total_mem);
  for(; p < end; p += size)
  {
      *p = 1;
  }
  

  Notiere dass der malloc() oben kann Ihnen die “falsche” Startadresse geben. Aber Ihr Prozess macht wirklich nicht viel, also denke ich, dass Sie immer sicher sein werden. Dass for() Schleife wird jedoch so schnell wie möglich sein. Wie von anderen erwähnt, erhalten Sie die total_mem des virtuellen Speichers, der “sofort” zugewiesen wird, und dann der RSS-Speicher, der bei jedem Schreiben zugewiesen wird *p.

WARNUNG: Code nicht getestet, Nutzung auf eigene Gefahr.