Что такое RSS и VSZ в управлении памятью Linux

Что такое RSS и VSZ в управлении памятью Linux? В многопоточной среде, как можно управлять и отслеживать обе эти функции?

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

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

Таким образом, если процесс A имеет двоичный файл размером 500 КБ и связан с 2500 КБ совместно используемых библиотек, имеет 200 КБ выделенных стеков / кучи, из которых 100 КБ фактически находится в памяти (остальная часть поменялась местами или не используется), и он фактически загрузил только 1000 КБ совместно используемых библиотек. и 400K своего двоичного файла:

RSS: 400K + 1000K + 100K = 1500K
VSZ: 500K + 2500K + 200K = 3200K

Поскольку часть памяти является общей, многие процессы могут использовать ее, поэтому, если вы сложите все значения RSS, вы легко сможете получить больше места, чем в вашей системе.

Память, которая выделяется, также может отсутствовать в RSS, пока она не будет фактически использована программой. Поэтому, если ваша программа выделяет кучу памяти заранее, а затем использует ее со временем, вы можете увидеть, что RSS растет, а VSZ остается прежним.

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

PSS: 400K + (1000K/2) + 100K = 400K + 500K + 100K = 1000K

Все потоки имеют одинаковое адресное пространство, поэтому RSS, VSZ и PSS для каждого потока идентичны всем другим потокам в процессе. Используйте ps или top для просмотра этой информации в linux / unix.

Существует гораздо больше, чем это, чтобы узнать больше, проверьте следующие ссылки:

• http://manpages.ubuntu.com/manpages/en/man1/ps.1.html
• https://web.archive.org/web/20120520221529/http://emilics.com/blog/article/mconsumption.html

Также см:

• Способ определить "реальное" использование памяти процессом, то есть частное грязное RSS?

RSS - это размер резидентного набора (физически резидентная память - в настоящее время она занимает место в физической памяти машины), а VSZ - размер виртуальной памяти (выделенное адресное пространство - у него есть адреса, выделенные в карте памяти процесса, но это не обязательно фактическая память за этим все прямо сейчас).

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

Минимальный исполняемый пример

Чтобы это имело смысл, вы должны понимать основы подкачки: как работает подкачка x86? и, в частности, что ОС может выделять виртуальную память через таблицы страниц / свою внутреннюю память (виртуальная память VSZ), прежде чем она фактически получит резервное хранилище в ОЗУ или на диске (резидентная память RSS).

Теперь, чтобы увидеть это в действии, давайте создадим программу, которая:

• выделяет больше оперативной памяти, чем наша физическая память с mmap
• записывает один байт на каждую страницу, чтобы гарантировать, что каждая из этих страниц переходит из виртуальной только памяти (VSZ) в фактически используемую память (RSS)
• проверяет использование памяти процессом одним из методов, упомянутых в: Использование памяти текущего процесса в C

main.c

#define _GNU_SOURCE
#include <assert.h>
#include <inttypes.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <unistd.h>

typedef struct {
    unsigned long size,resident,share,text,lib,data,dt;
} ProcStatm;

/* /programming/1558402/memory-usage-of-current-process-in-c/7212248#7212248 */
void ProcStat_init(ProcStatm *result) {
    const char* statm_path = "/proc/self/statm";
    FILE *f = fopen(statm_path, "r");
    if(!f) {
        perror(statm_path);
        abort();
    }
    if(7 != fscanf(
        f,
        "%lu %lu %lu %lu %lu %lu %lu",
        &(result->size),
        &(result->resident),
        &(result->share),
        &(result->text),
        &(result->lib),
        &(result->data),
        &(result->dt)
    )) {
        perror(statm_path);
        abort();
    }
    fclose(f);
}

int main(int argc, char **argv) {
    ProcStatm proc_statm;
    char *base, *p;
    char system_cmd[1024];
    long page_size;
    size_t i, nbytes, print_interval, bytes_since_last_print;
    int snprintf_return;

    /* Decide how many ints to allocate. */
    if (argc < 2) {
        nbytes = 0x10000;
    } else {
        nbytes = strtoull(argv[1], NULL, 0);
    }
    if (argc < 3) {
        print_interval = 0x1000;
    } else {
        print_interval = strtoull(argv[2], NULL, 0);
    }
    page_size = sysconf(_SC_PAGESIZE);

    /* Allocate the memory. */
    base = mmap(
        NULL,
        nbytes,
        PROT_READ | PROT_WRITE,
        MAP_SHARED | MAP_ANONYMOUS,
        -1,
        0
    );
    if (base == MAP_FAILED) {
        perror("mmap");
        exit(EXIT_FAILURE);
    }

    /* Write to all the allocated pages. */
    i = 0;
    p = base;
    bytes_since_last_print = 0;
    /* Produce the ps command that lists only our VSZ and RSS. */
    snprintf_return = snprintf(
        system_cmd,
        sizeof(system_cmd),
        "ps -o pid,vsz,rss | awk '{if (NR == 1 || $1 == \"%ju\") print}'",
        (uintmax_t)getpid()
    );
    assert(snprintf_return >= 0);
    assert((size_t)snprintf_return < sizeof(system_cmd));
    bytes_since_last_print = print_interval;
    do {
        /* Modify a byte in the page. */
        *p = i;
        p += page_size;
        bytes_since_last_print += page_size;
        /* Print process memory usage every print_interval bytes.
         * We count memory using a few techniques from:
         * /programming/1558402/memory-usage-of-current-process-in-c */
        if (bytes_since_last_print > print_interval) {
            bytes_since_last_print -= print_interval;
            printf("extra_memory_committed %lu KiB\n", (i * page_size) / 1024);
            ProcStat_init(&proc_statm);
            /* Check /proc/self/statm */
            printf(
                "/proc/self/statm size resident %lu %lu KiB\n",
                (proc_statm.size * page_size) / 1024,
                (proc_statm.resident * page_size) / 1024
            );
            /* Check ps. */
            puts(system_cmd);
            system(system_cmd);
            puts("");
        }
        i++;
    } while (p < base + nbytes);

    /* Cleanup. */
    munmap(base, nbytes);
    return EXIT_SUCCESS;
}

GitHub вверх по течению .

Скомпилируйте и запустите:

gcc -ggdb3 -O0 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
echo 1 | sudo tee /proc/sys/vm/overcommit_memory
sudo dmesg -c
./main.out 0x1000000000 0x200000000
echo $?
sudo dmesg

где:

• 0x1000000000 == 64 ГБ: 2x физической памяти моего компьютера 32 ГБ
• 0x200000000 == 8 ГБ: печатать память каждые 8 ​​ГБ, поэтому мы должны получить 4 отпечатка до сбоя около 32 ГБ
• echo 1 | sudo tee /proc/sys/vm/overcommit_memory: требуется для Linux, чтобы мы могли сделать вызов mmap больше физической ОЗУ: максимальный объем памяти, который может выделить malloc

Выход программы:

extra_memory_committed 0 KiB
/proc/self/statm size resident 67111332 768 KiB
ps -o pid,vsz,rss | awk '{if (NR == 1 || $1 == "29827") print}'
  PID    VSZ   RSS
29827 67111332 1648

extra_memory_committed 8388608 KiB
/proc/self/statm size resident 67111332 8390244 KiB
ps -o pid,vsz,rss | awk '{if (NR == 1 || $1 == "29827") print}'
  PID    VSZ   RSS
29827 67111332 8390256

extra_memory_committed 16777216 KiB
/proc/self/statm size resident 67111332 16778852 KiB
ps -o pid,vsz,rss | awk '{if (NR == 1 || $1 == "29827") print}'
  PID    VSZ   RSS
29827 67111332 16778864

extra_memory_committed 25165824 KiB
/proc/self/statm size resident 67111332 25167460 KiB
ps -o pid,vsz,rss | awk '{if (NR == 1 || $1 == "29827") print}'
  PID    VSZ   RSS
29827 67111332 25167472

Killed

Статус выхода:

137

что по правилу 128 + номер сигнала означает, что мы получили номер сигнала 9, который man 7 signalговорит , что это SIGKILL , который посылает убийца нехватки памяти Linux .

Выходная интерпретация:

• Виртуальная память VSZ остается постоянной printf '0x%X\n' 0x40009A4 KiB ~= 64GiB( psзначения в КиБ) после mmap.
• RSS «реальное использование памяти» увеличивается лениво только при касании страниц. Например:
  • на первом отпечатке мы имеем extra_memory_committed 0, что означает, что мы еще не коснулись ни одной страницы. RSS - это небольшой файл, 1648 KiBкоторый был выделен для обычного запуска программы, такого как текстовая область, глобальные переменные и т. Д.
  • на втором отпечатке мы написали к 8388608 KiB == 8GiBстоимости страниц. В результате RSS увеличился ровно на 8GIB до8390256 KiB == 8388608 KiB + 1648 KiB
  • RSS продолжает расти с шагом 8 ГБ. Последний отпечаток показывает около 24 ГиБ памяти, и до того, как можно было напечатать 32 ГиБ, убийца OOM убил процесс

Смотрите также: /unix/35129/need-explanation-on-resident-set-size-virtual-size

Журналы убийцы ООМ

Наши dmesgкоманды показали журналы убийцы OOM.

Точная интерпретация этих вопросов была задана по адресу:

• Понимание логов Linux oom-killer, но давайте кратко рассмотрим здесь.
• /server/548736/how-to-read-oom-killer-syslog-messages

Самая первая строка журнала была:

[ 7283.479087] mongod invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0

Итак, мы видим, что интересно, что это был демон MongoDB, который всегда запускался в моем ноутбуке на фоне, который первым вызвал убийцу OOM, предположительно, когда бедняга пытался выделить немного памяти.

Однако убийца ООМ не обязательно убивает того, кто его разбудил.

После вызова ядро ​​печатает таблицу или процессы, включая oom_score:

[ 7283.479292] [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
[ 7283.479303] [    496]     0   496    16126        6   172032      484             0 systemd-journal
[ 7283.479306] [    505]     0   505     1309        0    45056       52             0 blkmapd
[ 7283.479309] [    513]     0   513    19757        0    57344       55             0 lvmetad
[ 7283.479312] [    516]     0   516     4681        1    61440      444         -1000 systemd-udevd

и далее мы видим, что наш маленький на main.outсамом деле был убит при предыдущем вызове:

[ 7283.479871] Out of memory: Kill process 15665 (main.out) score 865 or sacrifice child
[ 7283.479879] Killed process 15665 (main.out) total-vm:67111332kB, anon-rss:92kB, file-rss:4kB, shmem-rss:30080832kB
[ 7283.479951] oom_reaper: reaped process 15665 (main.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:30080832kB

В этом журнале упоминается, score 865что этот процесс имел, предположительно, самый высокий (худший) показатель убийцы OOM, как упомянуто по адресу: /unix/153585/how-does-the-oom-killer-decide-which- процесс на поражение-первых

Также интересно то, что все произошло, по-видимому, так быстро, что до того, как освободившаяся память была учтена, процесс oomснова пробудился DeadlineMonitor:

[ 7283.481043] DeadlineMonitor invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0

и на этот раз, что убило какой-то процесс Chromium, который, как правило, мой компьютер нормальная память:

[ 7283.481773] Out of memory: Kill process 11786 (chromium-browse) score 306 or sacrifice child
[ 7283.481833] Killed process 11786 (chromium-browse) total-vm:1813576kB, anon-rss:208804kB, file-rss:0kB, shmem-rss:8380kB
[ 7283.497847] oom_reaper: reaped process 11786 (chromium-browse), now anon-rss:0kB, file-rss:0kB, shmem-rss:8044kB

Протестировано в Ubuntu 19.04, ядро ​​Linux 5.0.0.

Я думаю, что уже много сказано о RSS против VSZ. С точки зрения администратора / программиста / пользователя, когда я проектирую / кодирую приложения, меня больше беспокоит RSZ (резидентная память), и когда вы продолжаете тянуть все больше и больше переменных (в кучу), вы увидите, что это значение возрастает. Попробуйте простую программу для построения распределения памяти на основе malloc в цикле и убедитесь, что вы заполняете данные в этом пространстве malloc. RSS продолжает расти. Что касается VSZ, то это в большей степени сопоставление виртуальной памяти, чем в Linux, и одна из его основных функций, вытекающих из традиционных концепций операционной системы. Управление VSZ осуществляется с помощью управления виртуальной памятью ядра, для получения дополнительной информации о VSZ см. Описание Роберта Лава в mm_struct и vm_struct, которые являются частью базовой структуры данных task_struct в ядре.

Они не управляются, но измеряются и, возможно, ограничены (см. getrlimitСистемный вызов, также в getrlimit (2) ).

RSS означает размер резидентного набора (часть вашего виртуального адресного пространства, расположенная в оперативной памяти).

Вы можете запросить виртуальное адресное пространство процесса 1234 , используя процедурный (5) с cat /proc/1234/mapsи его статус (включая потребление памяти) черезcat /proc/1234/status