다른 사람들이 올바르게 지적했듯이 프로세스가 사용하는 실제 메모리, 공유 영역 및 mmap 파일 및 기타 등등을 처리하는 것은 어렵습니다.
실험자라면 valgrind 및 massif를 실행할 수 있습니다 . 일반 사용자에게는 약간 무거울 수 있지만 시간이 지남에 따라 응용 프로그램의 메모리 동작에 대한 아이디어를 얻을 수 있습니다. 응용 프로그램 malloc ()이 정확히 필요한 것이라면 프로세스의 실제 동적 메모리 사용량을 잘 표현할 수 있습니다. 그러나이 실험은 "중독"될 수 있습니다.
문제를 복잡하게하기 위해 Linux에서는 메모리 를 과다 커밋 할 수 있습니다 . malloc () 메모리를 사용하면 메모리를 소비하려는 의사가 있습니다. 그러나 할당 된 "RAM"의 새 페이지에 바이트를 쓸 때까지 할당이 실제로 발생하지 않습니다. 다음과 같이 작은 C 프로그램을 작성하고 실행하여이를 스스로 증명할 수 있습니다.
// test.c
#include <malloc.h>
#include <stdio.h>
#include <unistd.h>
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 $!
16GB 미만의 RAM이 장착 된 시스템에서이 기능을 실행하면 16GB의 메모리 만 확보 할 수 있습니다! (아니 정말).
의 공지 사항 top당신은 16.004G로 "VIRT"를 볼 수 있지만 %의 MEM은 0.0입니다
valgrind로 이것을 다시 실행하십시오.
# Shell:
valgrind --tool=massif ./test &
sleep 36
ms_print massif.out.$! | head -n 30
그리고 massif는 "모든 allocs () = 16GB의 합"이라고 말합니다. 별로 흥미롭지 않습니다.
그러나 제정신 프로세스 에서 실행하는 경우 :
# 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
그리고 여기서 우리는 컴파일러가 77KB의 힙을 할당했다는 것을 경험적으로 매우 확신합니다.
힙 사용량을 얻기 위해 왜 그렇게 노력합니까? 프로세스가 사용하는 모든 공유 객체와 텍스트 섹션 (이 예제에서는 컴파일러)이별로 흥미롭지 않기 때문입니다. 프로세스에 대한 지속적인 오버 헤드입니다. 실제로, 프로세스의 후속 호출은 거의 "무료"입니다.
또한 다음을 비교하고 대조하십시오.
MMAP ()는 1GB 파일입니다. VMSize는 1 + GB입니다. 그러나 상주 세트 크기는 해당 지역에 대한 포인터를 역 참조하여 페이징 된 파일의 일부일뿐입니다. 그리고 전체 파일을 "읽으면"끝날 때까지 커널이 이미 시작을 페이징 아웃했을 수 있습니다 (커널이 역 참조 된 경우 해당 페이지를 교체하는 방법 / 위치를 커널이 정확히 알고 있기 때문에 수행하기 쉽습니다) ). 두 경우 모두 VMSize 나 RSS가 메모리 "사용"을 나타내는 좋은 지표는 아닙니다. 실제로 malloc ()은 아무것도하지 않았습니다.
반대로 Malloc () 및 메모리의 LOTS를 터치하면 메모리가 디스크로 스왑 될 때까지. 따라서 할당 된 메모리가 이제 RSS를 초과합니다. 여기서 VMSize는 무언가를 알려주기 시작할 수 있습니다 (프로세스는 실제로 RAM에있는 것보다 많은 메모리를 소유합니다). 그러나 여전히 공유 페이지 인 VM과 스왑 된 데이터 인 VM을 구별하기는 여전히 어렵습니다.
valgrind / massif가 흥미로운 곳입니다. 페이지 상태에 관계없이 의도적으로 할당 한 내용이 표시 됩니다.
htop가 있으며 다른 날에 한 비슷한 질문 에 대한 저자 의 답변을 공유해야한다고 생각 합니다 ... / proc / meminfo에서 메모리 사용량을 계산하는 방법 (예 : htop)