Как полностью заблокировать загрузку торрента?

Как правильно указали другие, трудно получить доступ к реальной памяти, используемой процессом, в том числе с общими регионами, файлами с mmap'ами и еще много чего.

Если вы экспериментатор, вы можете запустить valgrind и massif . Для обычного пользователя это может показаться сложным, но вы получите представление о поведении памяти приложения с течением времени. Если приложение malloc () именно то, что ему нужно, это даст вам хорошее представление о реальном использовании динамической памяти процессом. Но этот эксперимент можно «отравить».

Чтобы усложнить ситуацию, Linux позволяет вам чрезмерно использовать вашу память. Когда вы используете malloc () memory, вы заявляете о своем намерении использовать память. Но на самом деле выделения не происходит, пока вы не запишете байт на новую страницу выделенной «RAM». Вы можете доказать это себе, написав и запустив небольшую программу на C, например:

// test.c
#include 
#include 
#include 
int main() {
    void *p;
    sleep(5)
    p = malloc(16ULL*1024*1024*1024);
    printf("p = %p\n", p);
    sleep(30);
    return 0;
}

# Shell:
cc test.c -o test && ./test &
top -p $!

Запустите ее на машине с менее чем 16 ГБ оперативной памяти и, вуаля !, вы только что получили 16 ГБ памяти! (нет, не совсем).

Обратите внимание, что в вверху вы видите "VIRT" как 16.004G, но% MEM равно 0.0

Запустите это еще раз с помощью valgrind:

# Shell:
valgrind --tool=massif ./test &
sleep 36
ms_print massif.out.$! | head -n 30

И в массиве указано "сумма всех аллок () = 16 ГБ" . Так что это не очень интересно.

НО, если вы запустите его на нормальном процессе:

# Shell:
rm test test.o
valgrind --tool=massif cc test.c -o test &
sleep 3
ms_print massif.out.$! | head -n 30

--------------------------------------------------------------------------------
Command:            cc test.c -o test
Massif arguments:   (none)
ms_print arguments: massif.out.23988
--------------------------------------------------------------------------------


    KB
77.33^                                                                       :
     |                                                                      #:
     |                                                                :@::@:#:
     |                                                           :::::@@::@:#:
     |                                                         @:: :::@@::@:#:
     |                                                     ::::@:: :::@@::@:#:
     |                                             ::@:::@:::::@:: :::@@::@:#:
     |                                            @::@:::@:::::@:: :::@@::@:#:
     |                                            @::@:::@:::::@:: :::@@::@:#:
     |                      :@@@@@@@@@@@@@@@@@@@@:@::@:::@:::::@:: :::@@::@:#:
     |                      :@@                  :@::@:::@:::::@:: :::@@::@:#:
     |                    :@:@@                  :@::@:::@:::::@:: :::@@::@:#:
     |                    :@:@@                  :@::@:::@:::::@:: :::@@::@:#:
     |                   :@@:@@                  :@::@:::@:::::@:: :::@@::@:#:
     |                   :@@:@@                  :@::@:::@:::::@:: :::@@::@:#:
     |              :@::::@@:@@                  :@::@:::@:::::@:: :::@@::@:#:
     |          :::::@::::@@:@@                  :@::@:::@:::::@:: :::@@::@:#:
     |        :::::::@::::@@:@@                  :@::@:::@:::::@:: :::@@::@:#:
     |       ::::::::@::::@@:@@                  :@::@:::@:::::@:: :::@@::@:#:
     |       ::::::::@::::@@:@@                  :@::@:::@:::::@:: :::@@::@:#:
   0 +----------------------------------------------------------------------->Mi
     0                                                                   1.140

И здесь мы видим (очень эмпирически и с очень высокой степенью уверенности), что компилятор выделил 77 КБ кучи.

Зачем так стараться использовать только кучу? Потому что все общие объекты и текстовые разделы, которые использует процесс (в данном примере компилятор), не очень интересны.Это постоянные накладные расходы для процесса. Фактически, последующие вызовы процесса почти бесплатны.

Также сравните и сопоставьте следующее:

MMAP () файл размером 1 ГБ. Ваш VMSize будет 1 + ГБ. Но ваш резидентный размер будет только частью файла, который вы вызвали для подкачки (путем разыменования указателя на эту область). И если вы "прочитаете" весь файл, то к тому времени, когда вы дойдете до конца, ядро, возможно, уже выгрузило начало страницы (это легко сделать, потому что ядро ​​точно знает, как / где заменить эти страницы, если разыменование снова будет разыменовано). ). В любом случае ни VMSize, ни RSS не являются хорошим индикатором «использования» вашей памяти. На самом деле вы ничего не сделали с malloc ().

Напротив, Malloc () и касание LOTS памяти - пока ваша память не будет заменена на диск. Итак, ваша выделенная память теперь превышает ваш RSS. Здесь ваш VMSize может начать вам что-то сообщать (вашему процессу принадлежит больше памяти, чем то, что на самом деле находится в вашей оперативной памяти). Но по-прежнему трудно отличить виртуальную машину с общими страницами от виртуальной машины с данными подкачки.

Именно здесь valgrind / massif становится интересным. Он показывает вам, что вы намеренно выделили (независимо от состояния ваших страниц).