Может ли Linux «исчерпать ОЗУ»?

Я видел несколько сообщений в Интернете, в которых люди, по-видимому, жалуются на то, что VPS-сервер неожиданно убивает процессы, поскольку они используют слишком много оперативной памяти.

Как это возможно? Я думал, что все современные ОС предоставляют «бесконечную оперативную память», просто используя замену диска для всего, что выходит за пределы физической памяти. Это верно?

Что может произойти, если процесс "убит из-за нехватки оперативной памяти"?

Что может произойти, если процесс "убит из-за нехватки оперативной памяти"?

Иногда говорят, что linux по умолчанию никогда не отклоняет запросы дополнительной памяти из кода приложения - например malloc(). ¹ На самом деле это не так; по умолчанию используется эвристика, посредством которой

Очевидные нарушения адресного пространства отклоняются. Используется для типичной системы. Это обеспечивает серьезное сбои при распределении, позволяя при избыточном коммите сократить использование подкачки.

От [linux_src]/Documentation/vm/overcommit-accounting(все цитаты из дерева 3.11). Точно то, что считается «серьезно диким распределением», не указывается явно, поэтому нам нужно было бы просмотреть источник, чтобы определить детали. Мы также могли бы использовать экспериментальный метод в сноске 2 (ниже), чтобы попытаться получить некоторое отражение эвристики - исходя из этого, мое первоначальное эмпирическое наблюдение состоит в том, что при идеальных обстоятельствах (== система бездействует), если вы не Если у вас нет свопа, вам будет позволено выделить около половины вашей оперативной памяти, а если у вас есть своп, вы получите около половины вашей оперативной памяти плюс весь своп. Это более или менее на процесс (но обратите внимание, что этот предел является динамическим и может изменяться в зависимости от состояния, см. Некоторые наблюдения в сноске 5).

Половина вашей оперативной памяти плюс подкачка явно является значением по умолчанию для поля «CommitLimit» в /proc/meminfo. Вот что это означает - и обратите внимание, что на самом деле это не имеет ничего общего с только что обсужденным пределом (из [src]/Documentation/filesystems/proc.txt):

CommitLimit: На основе коэффициента сверхкоммитирования ('vm.overcommit_ratio') это общий объем памяти, доступной в настоящее время для выделения в системе. Это ограничение соблюдается только в том случае, если включен строгий учет overcommit (режим 2 в vm.overcommit_memory). CommitLimit рассчитывается по формуле CommitLimit 7.3G.

В ранее цитируемом документе о оверкомит-бухгалтерии указано, что по умолчанию установлено значение vm.overcommit_ratio50. Так что если вы sysctl vm.overcommit_memory=2, то можете настроить vm.covercommit_ratio (с sysctl) и увидеть последствия. ³ Режим по умолчанию, когда CommitLimitон не применяется и только «очевидные превышения адресного пространства отклоняются», это когда vm.overcommit_memory=0.

В то время как стратегия по умолчанию имеет эвристический лимит для каждого процесса, предотвращающий «серьезно дикое распределение», она оставляет систему в целом свободной, чтобы получить серьезно дикое, мудрое распределение. ⁴ Это означает, что в какой-то момент он может исчерпать память и должен объявить о банкротстве некоторых процессов через убийцу OOM .

Что убивает убийца ООМ? Не обязательно процесс, который запрашивал память, когда его не было, поскольку это не обязательно действительно виновный процесс, и, что более важно, не обязательно тот, который быстрее всего поможет системе справиться с проблемой, в которой она находится.

Это цитируется здесь, который, вероятно, ссылается на источник 2.6.x:

/*
 * oom_badness - calculate a numeric value for how bad this task has been
 *
 * The formula used is relatively simple and documented inline in the
 * function. The main rationale is that we want to select a good task
 * to kill when we run out of memory.
 *
 * Good in this context means that:
 * 1) we lose the minimum amount of work done
 * 2) we recover a large amount of memory
 * 3) we don't kill anything innocent of eating tons of memory
 * 4) we want to kill the minimum amount of processes (one)
 * 5) we try to kill the process the user expects us to kill, this
 *    algorithm has been meticulously tuned to meet the principle
 *    of least surprise ... (be careful when you change it)
 */

Что кажется приличным обоснованием. Тем не менее, без криминалистической экспертизы, # 5 (который является избыточным # 1) кажется разумной реализацией, а # 3 является избыточным # 2. Так что может иметь смысл рассмотреть это урезанное до # 2/3 и # 4.

Я пролистал недавний источник (3.11) и заметил, что этот комментарий за это время изменился:

/**
 * oom_badness - heuristic function to determine which candidate task to kill
 *
 * The heuristic for determining which task to kill is made to be as simple and
 * predictable as possible.  The goal is to return the highest value for the
 * task consuming the most memory to avoid subsequent oom failures.
 */

Это немного более явно о # 2: «Цель состоит в том, чтобы [убить] задачу, потребляющую наибольшее количество памяти, чтобы избежать последующих сбоев oom», и, как следствие, # 4 ( «мы хотим убить минимальное количество процессов ( один )» ) .

Если вы хотите увидеть убийцу OOM в действии, см. Сноску 5.

¹ Бред, от которого Жиль, к счастью, избавился, см. Комментарии.

² Вот простой фрагмент кода C, который запрашивает все большие и большие куски памяти, чтобы определить, когда запрос на больше не будет работать:

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

#define MB 1 << 20

int main (void) {
    uint64_t bytes = MB;
    void *p = malloc(bytes);
    while (p) {
        fprintf (stderr,
            "%lu kB allocated.\n",
            bytes / 1024
        );
        free(p);
        bytes += MB;
        p = malloc(bytes);
    }
    fprintf (stderr,
        "Failed at %lu kB.\n",
        bytes / 1024
    );
    return 0;
}            

Если вы не знаете, C, вы можете скомпилировать это gcc virtlimitcheck.c -o virtlimitcheck, а затем запустить ./virtlimitcheck. Он абсолютно безвреден, так как процесс не использует пространство, которое он запрашивает, т. Е. Он никогда не использует ОЗУ.

В системе 3.11 x86_64 с системой 4 ГБ и 6 ГБ подкачки произошел сбой при ~ 7400000 кБ; число колеблется, поэтому, возможно, состояние является фактором. По совпадению это близко к CommitLimitin /proc/meminfo, но изменение через via vm.overcommit_ratioне имеет никакого значения. Однако на 3.6.11 32-битной системе ARM 448 МБ с 64 МБ подкачки у меня не получается ~ 230 МБ. Это интересно, поскольку в первом случае объем почти вдвое превышает объем ОЗУ, тогда как во втором он составляет около 1/4, что является сильным следствием того, что объем подкачки является фактором. Это было подтверждено отключением свопинга в первой системе, когда порог отказа снизился до ~ 1,95 ГБ, что очень похоже на маленькую коробку ARM.

Но так ли это на процесс? Похоже, что Нижеприведенная короткая программа запрашивает определенный пользователем кусок памяти, и, если это удается, ждет, когда вы нажмете return - таким образом, вы можете попробовать несколько одновременных экземпляров:

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

#define MB 1 << 20

int main (int argc, const char *argv[]) {
    unsigned long int megabytes = strtoul(argv[1], NULL, 10);
    void *p = malloc(megabytes * MB);
    fprintf(stderr,"Allocating %lu MB...", megabytes);
    if (!p) fprintf(stderr,"fail.");
    else {
        fprintf(stderr,"success.");
        getchar();
        free(p);
    }
    return 0;
}

Однако помните, что речь идет не только об объеме оперативной памяти и обменивании независимо от использования - см. Сноску 5 для наблюдений о влиянии состояния системы.

³ CommitLimit относится к количеству адресного пространства, разрешенного для системы, когда vm.overcommit_memory = 2. Предположительно, тогда сумма, которую вы можете выделить, должна быть за вычетом того, что уже зафиксировано, что, очевидно, является Committed_ASполем.

Потенциально интересный эксперимент, демонстрирующий это, заключается в добавлении #include <unistd.h>к вершине virtlimitcheck.c (см. Сноску 2) и fork()непосредственно перед while()циклом. Это не гарантирует работу, как описано здесь, без некоторой утомительной синхронизации, но есть немалый шанс, YMMV:

> sysctl vm.overcommit_memory=2
vm.overcommit_memory = 2
> cat /proc/meminfo | grep Commit
CommitLimit:     9231660 kB
Committed_AS:    3141440 kB
> ./virtlimitcheck 2&> tmp.txt
> cat tmp.txt | grep Failed
Failed at 3051520 kB.
Failed at 6099968 kB.

Это имеет смысл - детально изучая tmp.txt, вы можете видеть, как процессы чередуют свое все большее и большее распределение (это проще, если вы добавляете pid в вывод), пока один, очевидно, не потребует достаточно, чтобы другой отказал. Тогда победитель может забрать все до CommitLimitминус Committed_AS.

⁴ Стоит отметить, что на данном этапе, если вы еще не понимаете виртуальную адресацию и разбиение на страницы по требованию, то, что делает возможным в первую очередь перерасход, это то, что ядро ​​выделяет процессам пользовательского пространства вообще не физическую память - это виртуальное адресное пространство . Например, если процесс резервирует 10 МБ для чего-либо, это представляется как последовательность (виртуальных) адресов, но эти адреса еще не соответствуют физической памяти. При обращении к такому адресу это приводит к ошибке страницыа затем ядро ​​пытается отобразить его в реальную память, чтобы оно могло хранить реальное значение. Процессы обычно резервируют гораздо больше виртуального пространства, чем они фактически получают, что позволяет ядру наиболее эффективно использовать оперативную память. Тем не менее, физическая память по-прежнему является ограниченным ресурсом, и когда все это было сопоставлено с виртуальным адресным пространством, некоторое виртуальное адресное пространство должно быть удалено, чтобы освободить часть оперативной памяти.

⁵ Первое предупреждение : если вы попробуете это с помощью vm.overcommit_memory=0, убедитесь, что вы сначала сохранили свою работу и закрыли все критически важные приложения, потому что система зависнет на ~ 90 секунд, а некоторые процессы умрут!

Идея состоит в том, чтобы запустить бомбу-вилку, которая истекает через 90 секунд, при этом вилки распределяют пространство, и некоторые из них записывают большие объемы данных в ОЗУ, все время сообщая о них в stderr.

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/time.h>
#include <errno.h>
#include <string.h>

/* 90 second "Verbose hungry fork bomb".
Verbose -> It jabbers.
Hungry -> It grabs address space, and it tries to eat memory.

BEWARE: ON A SYSTEM WITH 'vm.overcommit_memory=0', THIS WILL FREEZE EVERYTHING
FOR THE DURATION AND CAUSE THE OOM KILLER TO BE INVOKED.  CLOSE THINGS YOU CARE
ABOUT BEFORE RUNNING THIS. */

#define STEP 1 << 30 // 1 GB
#define DURATION 90

time_t now () {
    struct timeval t;
    if (gettimeofday(&t, NULL) == -1) {
        fprintf(stderr,"gettimeofday() fail: %s\n", strerror(errno));
        return 0;
    }
    return t.tv_sec;
}

int main (void) {
    int forks = 0;
    int i;
    unsigned char *p;
    pid_t pid, self;
    time_t check;
    const time_t start = now();
    if (!start) return 1;

    while (1) {
    // Get our pid and check the elapsed time.
        self = getpid();
        check = now();
        if (!check || check - start > DURATION) return 0;
        fprintf(stderr,"%d says %d forks\n", self, forks++);
    // Fork; the child should get its correct pid.
        pid = fork();
        if (!pid) self = getpid();
    // Allocate a big chunk of space.
        p = malloc(STEP);
        if (!p) {
            fprintf(stderr, "%d Allocation failed!\n", self);
            return 0;
        }
        fprintf(stderr,"%d Allocation succeeded.\n", self);
    // The child will attempt to use the allocated space.  Using only
    // the child allows the fork bomb to proceed properly.
        if (!pid) {
            for (i = 0; i < STEP; i++) p[i] = i % 256;
            fprintf(stderr,"%d WROTE 1 GB\n", self);
        }
    }
}                        

Скомпилируйте это gcc forkbomb.c -o forkbomb. Сначала попробуйте это с sysctl vm.overcommit_memory=2- вы, вероятно, получите что-то вроде:

6520 says 0 forks
6520 Allocation succeeded.
6520 says 1 forks
6520 Allocation succeeded.
6520 says 2 forks
6521 Allocation succeeded.
6520 Allocation succeeded.
6520 says 3 forks
6520 Allocation failed!
6522 Allocation succeeded.

В этой среде подобная вилочная бомба не очень далеко заходит. Обратите внимание, что число в «говорит N вилок» - это не общее количество процессов, а число процессов в цепочке / ветви, ведущих к этому.

Теперь попробуйте это с vm.overcommit_memory=0. Если вы перенаправляете stderr в файл, вы можете выполнить грубый анализ, например:

> cat tmp.txt | grep failed
4641 Allocation failed!
4646 Allocation failed!
4642 Allocation failed!
4647 Allocation failed!
4649 Allocation failed!
4644 Allocation failed!
4643 Allocation failed!
4648 Allocation failed!
4669 Allocation failed!
4696 Allocation failed!
4695 Allocation failed!
4716 Allocation failed!
4721 Allocation failed!

Только 15 процессов не удалось выделить 1 ГБ - демонстрации того, что эвристика для overcommit_memory = 0 будет зависит от состояния. Сколько процессов было там? Глядя на конец tmp.txt, вероятно,> 100 000. Теперь, как на самом деле можно использовать 1 ГБ?

> cat tmp.txt | grep WROTE
4646 WROTE 1 GB
4648 WROTE 1 GB
4671 WROTE 1 GB
4687 WROTE 1 GB
4694 WROTE 1 GB
4696 WROTE 1 GB
4716 WROTE 1 GB
4721 WROTE 1 GB

Восемь - что опять-таки имеет смысл, поскольку в то время у меня было ~ 3 ГБ свободной оперативной памяти и 6 ГБ подкачки.

Посмотрите ваши системные журналы после того, как вы это сделаете. Вы должны увидеть результаты отчетов убийцы OOM (среди прочего); предположительно это относится к oom_badness.

Это не случится с вами, если вы загрузите только 1G данных в память. Что делать, если вы загружаете намного больше? Например, я часто работаю с огромными файлами, содержащими миллионы вероятностей, которые необходимо загрузить в R. Это занимает около 16 ГБ ОЗУ.

Запуск вышеупомянутого процесса на моем ноутбуке приведет к тому, что он начнет меняться как сумасшедший, как только мои 8 ГБ ОЗУ будут заполнены. Это, в свою очередь, замедлит все, потому что чтение с диска намного медленнее, чем чтение из ОЗУ. Что если у меня ноутбук с 2 ГБ оперативной памяти и только 10 ГБ свободного места? Как только процесс заберет всю оперативную память, он также заполнит диск, потому что он пишет для подкачки, и у меня больше нет ОЗУ и больше места для подкачки (люди склонны ограничивать подкачку выделенным разделом, а не файл подкачки именно по этой причине). Вот тут и приходит убийца ООМ и начинает убивать.

Таким образом, система действительно может исчерпать память. Кроме того, системы с сильной заменой могут стать непригодными для использования задолго до того, как это произойдет просто из-за медленных операций ввода-вывода из-за замены. Как правило, каждый хочет избежать как можно большего обмена. Даже на высокопроизводительных серверах с быстрыми твердотельными накопителями наблюдается явное снижение производительности. На моем ноутбуке с классическим приводом 7200 об / мин любая значительная замена делает систему непригодной для использования. Чем больше это меняет, тем медленнее становится. Если я не убью процесс оскорбления быстро, все зависнет, пока не вмешается убийца OOM.

Процессы не убиваются, когда ОЗУ больше нет, они убиваются, когда их обманули таким образом:

• Ядро Linux обычно позволяет процессам выделять (т.е. резервировать) объем виртуальной памяти, который больше, чем тот, который действительно доступен (часть ОЗУ + вся область подкачки)
• пока процессы получают доступ только к подмножеству зарезервированных страниц, все работает нормально.
• если по прошествии некоторого времени процесс пытается получить доступ к странице, которой он владеет, но больше нет свободных страниц, возникает ситуация нехватки памяти
• Убийца OOM выбирает один из процессов, не обязательно тот, который запросил новую страницу, и просто уничтожает его, чтобы восстановить виртуальную память.

Это может произойти, даже если система не выполняет активную перестановку, например, если область подкачки заполнена страницами памяти спящих демонов.

Это никогда не происходит в ОС, которые не перегружают память. С ними случайный процесс не убивается, но первый процесс, запрашивающий виртуальную память, пока она исчерпана, имеет malloc (или аналогичный), возвращающийся с ошибкой. Таким образом, это дает возможность правильно справиться с ситуацией. Тем не менее, в этих ОС может также случиться так, что система исчерпает виртуальную память, в то время как есть все еще свободная RAM, которая является довольно запутанной и обычно неправильно понимаемой.

Когда доступная оперативная память исчерпана, ядро ​​начинает выгружать биты обработки на диск. На самом деле, ядро ​​начинает менять местами, когда ОЗУ почти исчерпано: оно начинает активно менять местами, когда оно находится в режиме ожидания, чтобы быть более отзывчивым, если приложение внезапно требует больше памяти.

Обратите внимание, что оперативная память используется не только для хранения памяти процессов. В типичной исправной системе только около половины ОЗУ используется процессами, а другая половина используется для дискового кэша и буферов. Это обеспечивает хороший баланс между запущенными процессами и файлами ввода / вывода.

Пространство подкачки не бесконечно. В какой-то момент, если процессы продолжают выделять все больше и больше памяти, вторичные данные из ОЗУ заполнят обмен. Когда это происходит, процессы, которые пытаются запросить больше памяти, видят, что их запрос отклонен.

По умолчанию Linux перегружает память. Это означает, что иногда он позволяет запускать процесс с памятью, которую он зарезервировал, но не использовал. Основной причиной чрезмерного выполнения работ является способ разветвления . Когда процесс запускает подпроцесс, дочерний процесс концептуально работает в реплике памяти родительского процесса - два процесса изначально имеют память с одинаковым содержимым, но этот контент будет расходиться, поскольку процессы вносят изменения каждый в своем собственном пространстве. Чтобы полностью реализовать это, ядро ​​должно было бы скопировать всю память родителя. Это замедлит процесс разветвления, поэтому ядро ​​будет выполнять копирование при записиизначально ребенок делится всей своей памятью с родителем; всякий раз, когда какой-либо процесс записывает на общую страницу, ядро ​​создает копию этой страницы, чтобы прервать совместное использование.

Часто ребенок оставляет много страниц нетронутыми. Если бы ядро ​​выделило достаточно памяти для репликации пространства памяти родителя на каждой ветке, много памяти было бы потрачено впустую в резервированиях, которые дочерние процессы никогда не будут использовать. Отсюда чрезмерная загрузка: ядро ​​резервирует только часть этой памяти, основываясь на оценке того, сколько страниц понадобится ребенку.

Если процесс пытается выделить какую-то память и не хватает памяти, процесс получает ответ об ошибке и обрабатывает его так, как считает нужным. Если процесс косвенно запрашивает память путем записи на общую страницу, которая должна быть не общей, это другая история. Невозможно сообщить об этой ситуации приложению: оно считает, что оно имеет доступные для записи данные и может даже прочитать их - просто запись требует некоторой более сложной операции под капотом. Если ядро ​​не может предоставить новую страницу памяти, все, что он может сделать, это уничтожить запрашивающий процесс или уничтожить какой-то другой процесс, чтобы заполнить память.

В этот момент вы можете подумать, что уничтожение запрашивающего процесса - очевидное решение. Но на практике это не так хорошо. Этот процесс может быть важным, поскольку сейчас ему нужен только доступ к одной из его страниц, в то время как могут выполняться другие, менее важные процессы. Таким образом, ядро ​​включает в себя сложную эвристику, чтобы выбрать, какие процессы нужно убить - (в) известный убийца OOM .

Просто чтобы добавить другую точку зрения из других ответов, многие VPS размещают несколько виртуальных машин на любом сервере. Любая отдельная виртуальная машина будет иметь определенный объем оперативной памяти для собственного использования. Многие провайдеры предлагают «оперативную память», в которой они могут использовать оперативную память сверх того объема, который им назначен. Это предназначено только для кратковременного использования, и те, кто превышает это количество в течение продолжительного периода времени, могут быть оштрафованы хостом, убивающим процессы, чтобы снизить объем используемой оперативной памяти, чтобы другие не пострадали от хост-компьютер перегружен.

Некоторое время linux занимает внешнее виртуальное пространство. Это раздел подкачки. Когда Ram заполнен, linux использует эту область подкачки для запуска процесса с низким приоритетом.