하나의 기사로 Linux 메모리 할당 전략 이해

Linux 프로세스의 메모리 분포는 어떻게 되나요?

Linux 운영 체제에서 가상 주소 공간의 내부는 커널 공간과 사용자 공간의 두 부분으로 나뉩니다. 예를 들어 가장 일반적인 32비트 및 64비트 시스템은 다음과 같습니다.

여기에서 볼 수 있습니다:

• 32비트 시스템의 커널 공간은 맨 위에 있는 1G를 차지하고 나머지 3G는 사용자 공간입니다. 64비트 시스템의 커널 공간과 사용자 공간은 모두 128T로 전체 메모리 공간 중 가장 높은 부분과 가장 낮은 부분을 차지하고 나머지 중간 부분은 정의되지 않습니다.
커널 공간과 사용자 공간의 차이점에 대해 이야기해 보겠습니다.

프로세스가 사용자 모드에 있으면 사용자 공간 메모리에만 접근할 수 있습니다.

커널 상태에 들어간 후에만 커널 공간의 메모리에 액세스할 수 있습니다.
• 각 프로세스에는 독립적인 가상 메모리가 있지만
각 가상 메모리의 커널 주소는 실제로 동일한 물리적 메모리와 연결되어 있습니다
• . 이러한 방식으로 프로세스가 커널 상태로 전환된 후 커널 공간 메모리에 쉽게 액세스할 수 있습니다.

다음으로 가상 공간의 구분에 대해 좀 더 알아보겠습니다. 사용자 공간과 커널 공간은 서로 다른 방식으로 구분됩니다. 커널 공간의 분배에 대해서는 많이 언급하지 않겠습니다.

사용자 공간의 분포를 살펴보겠습니다. 32비트 시스템을 예로 들어 이들의 관계를 보여주기 위해 그림을 그렸습니다.

이 사진을 보면 사용자 공간 메모리가 낮음에서 높음

까지 6개의 서로 다른 메모리 세그먼트로 나누어져 있음을 알 수 있습니다.

바이너리 실행 코드를 포함한 프로그램 파일 세그먼트

정적 상수를 포함한 초기화된 데이터 세그먼트

• 초기화되지 않은 정적 변수를 포함한 초기화되지 않은 데이터 세그먼트
• 동적으로 할당된 메모리를 포함하는 힙 세그먼트는 낮은 주소에서 시작하여 위쪽으로 증가합니다. 동적 라이브러리, 공유 메모리 등을 포함한 파일 매핑 세그먼트는 낮은 주소에서 시작하여 위로 증가합니다(하드웨어 및 커널 버전에 따라 다름).
지역 변수, 함수 호출 컨텍스트 등을 포함한 스택 세그먼트 스택 크기는 일반적으로 8MB로 고정되어 있습니다. 물론 시스템은 크기를 맞춤 설정할 수 있도록 매개변수도 제공합니다.
• 이 6개의 메모리 세그먼트 중에서 힙 및 파일 매핑 세그먼트의 메모리가 동적으로 할당됩니다. 예를 들어, C 표준 라이브러리의 malloc() 또는 mmap()을 사용하면 힙 및 파일 매핑 세그먼트에 각각 동적으로 메모리를 할당할 수 있습니다.
• malloc은 어떻게 메모리를 할당하나요?
• 사실 malloc()은 시스템 호출이 아니라 동적으로 메모리를 할당하는 데 사용되는 C 라이브러리의 함수입니다.
• malloc이 메모리를 적용할 때 운영체제에서 힙 메모리를 적용하는 방법은 두 가지가 있습니다.

방법 1: brk() 시스템 호출을 통해 힙에서 메모리 할당

방법 2: mmap() 시스템 호출을 통해 파일 매핑 영역에 메모리를 할당합니다. 방법 1의 구현은 매우 간단합니다. 즉, brk() 함수를 사용하여 "힙 상단" 포인터를 상위 주소로 이동하여 새 메모리 공간을 얻는 것입니다. 아래와 같이:

방법 2는 mmap() 시스템 호출에서 "비공개 익명 매핑" 메서드를 사용하여 파일 매핑 영역에 메모리 조각을 할당합니다. 이는 파일 매핑 영역에서 메모리 조각을 "훔치는 것"입니다. 아래와 같이:

“

어떤 상황에서 malloc()이 brk()를 통해 메모리를 할당하나요? mmap()을 통해 메모리가 할당되는 시나리오는 무엇입니까?

”

malloc()에는 소스 코드에 기본적으로 정의된 임계값이 있습니다.

• 사용자가 할당한 메모리가 128KB 미만인 경우 brk()를 통해 메모리를 신청하세요. 사용자가 할당한 메모리가 128KB보다 큰 경우 mmap()을 통해 메모리를 신청하세요.
• 다른 glibc 버전은 다른 임계값을 정의합니다.
malloc()은 물리적 메모리를 할당하나요?

아니요,

malloc()은 가상 메모리

를 할당합니다.

할당된 가상 메모리에 접근하지 않으면 가상 메모리는 물리 메모리에 매핑되지 않으므로 물리 메모리를 차지하지 않습니다. 할당된 가상 주소 공간에 액세스할 때만 운영 체제는 페이지 테이블을 조회하여 가상 메모리에 해당하는 페이지가 물리적 메모리에 없음을 발견하고 페이지 오류 인터럽트를 트리거한 다음 운영 체제는 가상 메모리와 물리적 메모리 사이의 매핑 관계를 설정합니다.

malloc(1)은 얼마나 많은 가상 메모리를 할당합니까?

malloc()이 메모리를 할당할 때 사용자가 기대하는 바이트 수에 따라 메모리 공간을 할당하지 않고 더 큰 공간을 메모리 풀로 미리 할당합니다.

사전 할당될 구체적인 공간은 malloc에서 사용하는 메모리 관리자와 관련이 있으며, 우리는 malloc의 기본 메모리 관리자(Ptmalloc2)를 사용하여 분석할 것입니다. 다음으로, malloc을 통해 1바이트의 메모리를 적용할 때 운영 체제에서 실제로 얼마나 많은 메모리 공간을 할당하는지 실험을 통해 다음 코드를 사용해 보겠습니다.

으아아아

코드 실행 (

미리 설명드리자면 제가 사용하는 glibc 라이브러리 버전은 2.17

입니다):

/proc//maps 파일을 통해 프로세스의 메모리 분포를 볼 수 있습니다. 이 1바이트 메모리 시작 주소를 기준으로 지도 파일의 메모리 주소 범위를 필터링합니다. 으아아아

이 예시에서 할당된 메모리는 128KB 미만이므로 brk() 시스템 호출을 통해 메모리를 힙 공간에 적용하므로 맨 오른쪽에 [heap] 표시가 보입니다.

힙 공간의 메모리 주소 범위는 00d73000-00d94000이고 이 범위의 크기는 132KB인 것을 볼 수 있습니다. 이는

malloc(1)이 실제로 132K 바이트의 메모리

를 미리 할당한다는 것을 의미합니다.

일부 학생들은 프로그램에 인쇄된 메모리의 시작 주소가 d73010인 반면, 지도 파일에는 힙 메모리 공간의 시작 주소가 d73000으로 표시되는 것을 알 수 있습니다. 왜 추가로 0x10(16바이트)이 있나요? 이 질문은 일단 제쳐두고 나중에 이야기하겠습니다. #free 해제된 메모리는 운영 체제로 반환되나요?

free() 함수를 통해 메모리를 해제한 후에도 힙 메모리가 남아 있는지 위의 과정을 실행해 볼까요?

아래 그림에서 볼 수 있듯이 메모리를 해제한 후에도 힙 메모리가 여전히 존재하며 운영체제로 반환되지 않습니다.

이 1바이트를 운영체제에 풀어주는 것보다 캐시해서 malloc의 메모리 풀에 넣어두는 것이 프로세스가 다시 1바이트 메모리를 적용할 때 바로 재사용할 수 있기 때문이다. 훨씬 빠릅니다.

물론, 프로세스가 종료되면 운영 체제는 프로세스의 모든 리소스를 회수합니다.

위에서 언급한 free 메모리 이후에도 힙 메모리는 여전히 존재합니다. 이는 brk()를 통해 malloc이 적용된 메모리에 대한 것입니다.

mmap을 통해 malloc이 메모리를 적용하면 free가 메모리를 해제한 후 운영체제로 반환됩니다.

malloc을 통해 128KB의 메모리를 적용하여 malloc이 mmap을 통해 메모리를 할당하는지 실험해 보겠습니다.

으아아아

실행 코드:

프로세스의 메모리 분포를 보면 맨 오른쪽에 [head] 표시가 없는 것을 확인할 수 있는데, 이는 익명 매핑을 통해 mmap을 통해 파일 매핑 영역에서 익명 메모리를 할당했음을 나타냅니다.

그럼 이 메모리를 해제하고 살펴보겠습니다.

128KB 메모리의 시작 주소를 다시 확인하여 더 이상 존재하지 않는 것을 발견하면 운영 체제로 반환되었음을 나타냅니다.

"malloc에서 적용하고 무료로 해제한 메모리가 운영 체제로 반환되나요?"라는 질문에 대해 요약하면 다음과 같습니다.

• brk()를 통해 malloc에 ​​적용된 메모리는 메모리를 해제할 때 메모리를 운영 체제에 반환하지 않지만 다음 사용을 위해 malloc의 메모리 풀에 캐시됩니다 ;
free가
• mmap()을 통해 malloc에서 할당한 메모리를 해제하면 는 메모리를 운영 체제로 반환하고 메모리는 실제로 해제됩니다.

왜 모두 mmap을 사용하여 메모리를 할당하지 않나요?

운영 체제에서 메모리를 적용하려면 시스템 호출이 필요하기 때문에 시스템 호출을 실행하려면 커널 상태로 진입한 후 실행 상태로 돌아가는 데 시간이 많이 걸립니다.

그래서 메모리를 적용하는 작업은 잦은 시스템 호출을 피해야 합니다. mmap을 사용하여 메모리를 할당한다면 매번 시스템 호출을 실행해야 한다는 의미입니다.

또한 mmap으로 할당한 메모리는 해제될 때마다 운영체제로 반환되기 때문에 mmap으로 할당한 가상 주소는 매번 페이지 폴트 상태가 되며, 이후 처음으로 가상 주소에 접근할 때 시간이 지나면 페이지 오류 인터럽트가 트리거됩니다.

즉,

mmap을 통해 메모리를 자주 할당하면 매번 실행 상태가 전환될 뿐만 아니라 페이지 폴트 인터럽트도 발생하여(가상 주소에 처음 액세스한 후) CPU 소모가 커집니다. .

이 두 가지 문제를 개선하기 위해 malloc은 brk() 시스템 호출을 통해 힙 공간의 메모리를 적용할 때 힙 공간이 연속적이므로 메모리가 해제될 때 더 큰 메모리를 메모리 풀로 직접 미리 할당합니다. , 메모리 풀에 캐시됩니다.

다음번에 메모리를 신청할 때 해당 메모리 블록을 메모리 풀에서 직접 꺼내기만 하면 이 메모리 블록의 가상 주소와 물리적 주소 간의 매핑 관계가 여전히 존재할 수 있습니다. 시스템 호출, 또한 페이지 폴트 인터럽트 수를 줄여 CPU 소비를 크게 줄입니다.

brk는 정말 훌륭하므로 모든 할당에 brk를 사용하는 것은 어떨까요?

앞서 brk를 통해 힙 공간에서 할당된 메모리는 운영체제로 반환되지 않는다고 언급했는데, 그런 시나리오를 생각해 보겠습니다.

메모리 10k, 20k, 30k 3개를 연속으로 신청하면 10k, 20k가 해제되어 여유 메모리 공간이 되고, 다음 번에 신청하는 메모리가 30k 미만이면 이 여유 메모리 공간을 재사용할 수 있습니다. .

그러나 다음 번에 요청한 메모리가 30k보다 클 경우 사용 가능한 여유 메모리 공간이 없어 OS에 적용해야 하며 실제 사용되는 메모리는 계속 증가합니다.

따라서 특히 작은 메모리 블록의 경우 시스템이 자주 malloc 및 해제를 수행하면 힙에 사용할 수 없는 조각이 점점 더 많이 생성되어 "메모리 누수"가 발생합니다. 이 "누출" 현상은 valgrind를 사용하여 감지할 수 없습니다.

그래서 malloc 구현에서는 brk와 mmap 동작의 차이점, 장단점을 충분히 고려하고 mmap을 사용하여 메모리 공간을 할당하기 전에 기본적으로 큰 메모리 블록(128KB)이 할당됩니다.

free() 함수는 메모리 주소만 전달합니다. 왜 해제할 메모리 양을 알 수 있나요?

앞서 malloc에 ​​의해 사용자 모드로 반환된 메모리의 시작 주소가 프로세스 힙 공간의 시작 주소보다 16바이트 더 크다고 언급한 것을 기억하시나요?

추가 16바이트에는 메모리 블록 크기 등 메모리 블록에 대한 설명 정보가 저장됩니다.

이렇게 free() 함수가 실행되면 free는 들어오는 메모리 주소를 왼쪽으로 16바이트만큼 오프셋한 다음 이 16바이트에서 현재 메모리 블록의 크기를 분석하여 자연스럽게 그 크기를 알게 됩니다. 메모리를 해제해야 합니다.

위 내용은 하나의 기사로 Linux 메모리 할당 전략 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!