프로세스가 4GB에서 죽는 이유는 무엇입니까?

Question

거대한 데이터 세트에서 작동하는 프로그램을 작성했습니다. 내 CPU와 OS (우분투)는 모두 64 비트이고 4GB의 RAM을 가지고 있습니다. "top"(% Mem 필드)을 사용하여 프로세스의 메모리 사용량이 약 87 %, 즉 3.4GB 이상으로 증가한 것을 확인했습니다.

그런 다음 "uname -m"을 사용하여 프로세스가 액세스 할 수있는 메모리 양을 "무제한"으로 확인했습니다.

OS와 CPU가 모두 64 비트이고 스왑 파티션이 있기 때문에 운영 체제는 가상 메모리 즉 [> 스왑 공간에서 3.4GB + yGB]를 사용해야하며 필요한 경우에만 더 많은 기억, 그것은 죽었 음에 틀림 없다.

그래서, 다음 한 QUES :

1. 얼마나 많은 물리적 메모리 할 수있는 이론적으로 64 비트 M/C에 프로세스에 액세스 할 수 있습니다. 내 대답은 2^48 바이트입니다.
2. 실제 메모리가 2^48 바이트 미만인 경우 OS가 가상 메모리를 사용해야하며 맞습니까?
3. OS가 SWAP 공간을 사용 했어야하는 이유는 OS가 SWAP 공간을 사용해야했기 때문입니다. 우리 프로그램을 코딩하기 위해 특정 시스템 호출을 사용해야한다고 생각하지 않습니다.

좋습니다.

Answer 1

file 및 ldd으로 실행 파일이 실제로 64 비트인지 확인하십시오.

리소스 제한도 확인하십시오. 프로세스 내부에서 getrlimit 시스템 호출 (가능한 경우 setrlimit)을 사용하여 프로세스를 변경할 수 있습니다. bash 셸에서 ulimit -a을 시도하십시오. zsh 셸에서 limit을 시도해보십시오.

프로세스가 실제로 소비한다고 생각하는 메모리를 실제로 먹는지 확인하십시오. 그것의 PID가 1234라면 pmap 1234을 시도 할 수 있습니다. 프로세스 내부에서 /proc/self/maps 또는 /proc/1234/maps (터미널에서 읽을 수 있음)을 읽을 수 있습니다. 또한 당신이 믿는 메모리 (그리고 스왑 공간)을 가지고 free와 /proc/self/ ...

점검 내부의 /proc/self/smaps 또는 /proc/1234/smaps 및 /proc/self/status 또는 /proc/1234/status 및 기타 파일이 있습니다. 임시 스왑 공간을 swapon /tmp/someswapfile과 함께 추가 할 수 있습니다 (초기화하려면 mkswap을 사용하십시오).

Gnu/Linux/Debian/Sid/AMD64에서 7Gb 프로세스 (거대한 cc1 컴파일)를 실행하기 위해 몇 달 (2 년 전), 일상적으로 8Gb RAM .

그리고 작은 테스트 프로그램으로 시도해 볼 수 있습니다. malloc과 같은 다수의 메모리 청크를 할당한다. 32Mb. 내부에 몇 바이트를 쓰는 것을 잊지 마십시오 (최소한 각 메가 바이트에서).

std::map 또는 std::vector과 같은 표준 C++ 컨테이너는 일반적으로 생각하는 것보다 더 많은 메모리를 소비한다고 소문이 있습니다.

필요한 경우 더 많은 RAM을 구입하십시오. 요즘은 꽤 싸다.

Answer 2

그래픽 어댑터, OS 커널, BIOS 등을 포함하여 글자 그대로 모든 것을 해결할 수 있어야하며 해결할 수있는 양은 SWAP에서도 연장 할 수 없습니다.

또한 프로세스 자체가 64 비트 일 필요가 있다는 점에 유의할 가치가 있습니다. 그리고 일부 운영 체제는 불안정해질 수 있으므로 과도한 RAM을 사용하는 경우 프로세스가 중단 될 수 있습니다.

Answer 3

이유가 될 수있는 데이터 크기가 아닙니다. 예를 들어, ulimit -a을 수행하고 최대 스택 크기를 확인하십시오. 죽이는 이유가 있니? 코어 파일을 얻기 위해 'ulimit -c 20000'을 설정하면, gdb로 검사 할 이유를 알 수 있습니다.