그림으로 배우는 리눅스 구조 4장. 메모리 관리 시스템

출처: 그림으로 배우는 리눅스 구조

그림으로 배우는 리눅스 구조 - 예스24

선배가 옆에서 하나하나 알려주듯 친절히 설명해주는실습과 그림으로 배우는 리눅스 지식의 모든 것 * Go 언어와 Python, Bash 스크립트 실습 코드 제공* 이 도서는 『실습과 그림으로 배우는 리눅스 구조』의 개정판입니다.리눅스 커널 책의 두께와 깊이에 ...

https://www.yes24.com/Product/Goods/122109062

메모리 관련 정보 수집하기

used

buff/cache

sar 명령어로 메모리 관련 정보 수집하기

메모리 재활용 처리

프로세스 삭제와 메모리 강제 해제

가상 메모리

가상 메모리가 없을 때 생기는 문제점

메모리 단편화

멀티 프로세스 구현이 어려움

비정상적인 메모리 접근

가상 메모리 기능

페이지 테이블

가상 메모리로 문제 해결하기

메모리 단편화

멀티 프로세스 구현이 어려움

비정상적인 메모리 접근

프로세스에 새로운 메모리 할당하기

메모리 영역 할당: mmap() 시스템 콜

Meltdown 취약점의 공포 p.128

메모리 할당: Demand paging

시스템 전체 메모리 사용량 변화를 확인하기

시스템 전체 페이지 폴트 발생 상황을 확인하기

프로그래밍 언어 번역기와 메모리 관리

페이지 테이블 계층화

Huge Page

Transparent Huge Page(THP)

메모리 관련 정보 수집하기

free : 시스템에 설치된 메모리 용량과 사용 중인 메모리 용량 확인

used

= 프로세스 사용 메모리 + 커널 사용 메모리

used 값은 프로세스 메모리 사용량에 따라 늘어난다.

• memuse.py

  #!/usr/bin/python3
  
  import subprocess
  
  # 적당한 양의 데이터를 작성해서 메모리를 사용
  # 메모리 용량이 작은 시스템이라면 메모리 부족으로 실패할 가능성이 있으므로
  # size값을 줄여서 다시 실행
  size = 10000000
  
  print("메모리 사용 전의 전체 시스템 메모리 사용량을 표시합니다.")
  subprocess.run("free")
  
  array = [0]*size
  
  print("메모리 사용 후의 전체 시스템 메모리 남은 용량을 표시합니다.")
  subprocess.run("free")

1. 메모리를 사용해 used 값이 늘어난 걸 확인할 수 있고

2. memuse.py 실행 직후에 free 실행 시 used값이 이전과 거의 같음을 확인할 수 있음

   → 프로세스가 종료하면 커널은 해당 프로세스의 메모리를 모두 해제함.

buff/cache

= 페이지 캐시와 버퍼 캐시가 사용하는 메모리 용량

→ 디스크에 있는 걸 메모리에 저장해서 접근 속도 빠르게

디스크에 있는 데이터 읽어와서 메모리에 데이터 캐시.

• buff-cache.sh

  #!/bin/bash
  
  echo "파일 작성 전의 시스템 전체 메모리 사용량을 표시합니다."
  free
  
  echo "1GB 파일을 새로 작성합니다. 커널은 메모리에 1GB 페이지 캐시 영역을 사용합니다."
  dd if=/dev/zero of=testfile bs=1M count=1K
  
  echo "페이지 캐시 사용 후의 시스템 전체 메모리 사용량을 표시합니다."
  free
  
  echo "파일 삭제 후, 즉 페이지 캐시 삭제 후의 시스템 전체 메모리 사용량을 표시합니다."
  rm testfile
  free

파일 작성 전후로 buff/cache 값이 약 1GiB 정도 늘어났고, 파일을 삭제하니 값이 원래대로 돌아옴

• GB/GiB 차이

  

sar 명령어로 메모리 관련 정보 수집하기

sar -r 1 5 : 5초동안 1초 간격으로 메모리 정보를 출력한다.

sar은 free와 다르게 한 줄에 정보가 다 담겨이어서 계속해서 정보 수집 시 편리

메모리 재활용 처리

• ㅇ

  

시스템 부하가 높아지면 free 메모리가 줄어듦

이때 커널의 메모리 관리 시스템은 재활용 가능한 메모리 영역을 해제해서 free 값을 늘린다.

재활용 가능한 메모리 = 페이지 캐시(동일한 데이터가 디스크에 존재하기 때문에 해제해도 괜찮음)

💡결론 : free 메모리가 줄어들면 재활용 가능한 메모리 영역(buff/cache - 버퍼 캐시, 페이지 캐시)을 해제해서 free 값을 늘린다.

프로세스 삭제와 메모리 강제 해제

재활용 가능한 메모리를 해제해도 메모리가 부족하면 Out Of Memory(OOM) 상태가 된다.

이런 상황에 빠지면 메모리 관리 시스템이 적당히 프로세스를 골라서 강제 종료시키고 메모리 공간을 만드는 OOM Killer라는 기능이 동작한다.

dmesg 명령어로 OOM Killer 동작 여부를 확인할 수 있다.

💡어떤 프로세스가 갑자기 예고도 없이 종료되면 확인해보기

+) 메모리 용량은 충분한데 OOM Killer가 동작한다면 어떤 프로세스 또는 커널에 메모리 누수(memeory leak)가 일어나고 있을지도 모른다.

→ 프로세스 메모리 사용량을 정기적으로 모니터링해 메모리 사용량이 늘어나는 수상한 프로세스 찾기

ps aux 명령어로 간단하게 모니터링 가능

RSS : 프로세스가 사용하는 메모리 용량

가상 메모리

가상 메모리가 없을 때 생기는 문제점

• 메모리 단편화

• 멀티 프로세스 구현이 어려움

• 비정상적인 메모리 접근

메모리 단편화

위 그림에서 비어있는 메모리는 합치면 300바이트이지만 각자 따로따로 100바이트씩 3개의 영역으로 나눠져있기 때문에 100바이트보다 큰 영역을 확보하려면 실패한다.

멀티 프로세스 구현이 어려움

어떤 프로그램 A와 B가 있고 각각 동일한 메모리 영역에 매핑되도록 만들었다면 A와 B는 동시에 실행이 불가능하다.

비정상적인 메모리 접근

어떤 프로세스가 커널이나 다른 프로세스에 할당된 메모리 주소를 지정하면 자신이 사용하는 영역이 아님에도 불구하고 접근할 수 있는 문제가 생김

가상 메모리 기능

가상 메모리 : 시스템에 설치된 메모리에 직접 접근하는 대신에 가상 주소를 사용해서 간접적으로 접근하는 기능

물리 주소 : 시스템에 설치된 메모리의 실제 주소

프로세스가 주소 100에 접근하면, 실제로 메모리에서는 주소 600에 존재하는 데이터에 접근한다.

2장에 나온 readlf(-h 프로그램 시작 주소 확인) cat /proc/<pid>/maps 에 나오는 결과는 가상 주소다. 프로세스에서 실제 메모리에 직접 접근하는 방법(물리 주소)은 없음.

페이지 테이블

페이지 테이블 : 가상 주소를 물리 주소로 변환하는데 사용한다. 커널 메모리 내부에 저장되어있음.

CPU는 모든 메모리를 페이지 단위로 쪼개서 관리하는데 주소는 페이지 단위로 변환된다.

x86_64 아키텍처에서 페이지 크기는 4KiB다.

💡책에서는 설명하기 편하도록 페이지 크기를 100바이트로 정함.

페이지 테이블 엔트리 : 페이지 테이블에서 한 페이지에 대응하는 데이터

→ 가장 주소와 물리 주소 대응 정보 포함

가상 주소 0~300이 물리 주소 500~800에 매핑된 모습

페이지 테이블은 커널이 작성함.

2장에서 커널은 프로세스 생성 시 프로세스 메모리를 확보(fork())하고 확보한 메모리에 실행 파일 내용을 복사(execve())한다고 했는데 이때 동시에 프로세스용 페이지 테이블도 작성한다.

하지만 프로세스가 가장 주소에 접근할 때 물리 주소로 변환하는 건 CPU가 하는 작업이다.

주소 300~500에 프로세스가 접근하면 CPU에서 페이지 폴트라는 예외가 발생한다.

페이지 폴트 발생 시 페이지 폴트 핸들러 처리가 실행된다.

그 이후에 SIGSEGV 시그널을 프로세스에 송신한다. SIGSEGV 시그널을 받은 프로세스는 보통 강제 종료된다.

package main

import "fmt"

func main() {
	// nil은 반드시 접근에 실패해서 페이지 폴트가 발생하는 특수한 메모리 접근
	var p *int = nil
	fmt.Println("비정상 메모리 접근 전")
	*p = 0
	fmt.Println("비정상 메모리 접근 후")
}

비정상적인 주소에 접근한 직후에 SIGSEGV 시그널을 수신했는데 이 시그널에 대처하지 못해서 종료된 것을 알 수 있다.

C언어나 Go 언어처럼 메모리 주소를 직접 다루는 언어로 작성된 프로그램이라면 SIGSEGV 때문에 프로그램이 강제 종료되는 일이 종종 발생한다.(파이썬은 발생 안함. 메모리 주소 직접 안 다루기 때문.)

가상 메모리로 문제 해결하기

메모리 단편화

멀티 프로세스 구현이 어려움

가상 주소 공간은 프로세스마다 만들어진다. 따라서 멀티프로세스 환경에서 각자의 프로그
램이 다른 프로그램과 주소가 중복되는 걸 피할 수 있다.

비정상적인 메모리 접근

프로세스마다 가상 주소 공간이 있다는 말은 애초에 다른 프로세스의 메모리가 어떻게 되어있는지 알 수가 없기 때문에 접근할 수 없다는 뜻이다.

→ 다른 프로세스의 메모리로 비정상적인 접근 불가능

프로세스에 새로운 메모리 할당하기

<일반적으로 생각하는 커널이 프로세스에 메모리를 할당하는 절차>

1. 커널에 메모리 요청

2. 커널이 메모리 확보

3. 가상주소 공간에 매핑

4. 가상 주소 공간의 시작 위치 주소를 프로세스에게 돌려준다.

• detail

  

하지만 메모리를 확보한 순간 바로 사용하기보다는 조금 지난 후에 사용하는 일이 많아서 리눅스는 메모리를 확보하는 절차를 두 단계로 나눈다.

1. 메모리 영역 할당 : 가상 주소 공간에 새롭게 접근 가능한 메모리 영역을 매핑한다.

2. 메모리 할당 : 확보한 메모리 영역에 물리 메모리를 할당한다.

메모리 영역 할당: mmap() 시스템 콜

mmap() 시스템 콜 호출 시

1. 프로세스의 페이지 테이블 변경

2. 요청된 크기만큼 영역을 페이지 테이블에 추가로 매핑

3. 매핑된 영역의 시작 주소를 프로세스에 돌려준다.

Meltdown 취약점의 공포 p.128

2018년 이전까지 리눅스는 커널 메모리를 프로세스 가상 주소 공간에 매핑하는 것이 기본이었지만 이제는 취약점 때문에 더이상 매핑되지 않도록 기본값이 바뀌었다.

메모리 할당: Demand paging

: 실제로 사용 시 물리 메모리 할당

mmap() 시스템 콜을 호출한 직후라면 새로운 메모리 영역에 대응하는 물리 메모리는 아직 존재하지 않는다.

대신 각 페이지에 처음 접근할 때 물리 메모리를 할당한다.(바로 할당X, 필요시 할당O : 지연로딩)

페이지에 접근 시 아래와 같은 절차로 메모리를 할당한다.

1. 프로세스가 페이지에 접근

2. 페이지 폴트가 발생

3. 커널의 페이지 폴트 핸들러가 동작해서 페이지에 대응하는 물리 메모리를 할당

메모리 단위 : 페이지

Page In : 디스크에서 메모리로 데이터 읽어오는 것

Page Out : 메모리에서 디스크에 데이터를 쓰는 것

페이지 폴트 핸들러는

1. 페이지 테이블 엔트리가 존재하지 않는 페이지 접근 → 프로세스에 SIGSEGV 보냄.

2. 페이지 테이블 엔트리는 존재해도 대응하는 물리 메로리가 할당되지 않은 경우 → 새로운 메모리를 할당하는 처리로 분기.

• demand-paging.py

  #!/usr/bin/python3
  
  import mmap
  import time
  import datetime
  
  ALLOC_SIZE  = 100 * 1024 * 1024
  ACCESS_UNIT = 10 * 1024 * 1024
  PAGE_SIZE   = 4096
  
  def show_message(msg):
      print("{}: {}".format(datetime.datetime.now().strftime("%H:%M:%S"), msg))
  
  show_message("새로운 메모리 영역 확보 전. 엔터 키를 누르면 100메가 새로운 메모리 영역을 확보합니다: ")
  input()
  
  # mmap() 시스템 콜 호출로 100MiB 메모리 영역 확보
  memregion = mmap.mmap(-1, ALLOC_SIZE, flags=mmap.MAP_PRIVATE)
  show_message("새로운 메모리 영역을 확보했습니다. 엔터 키를 누르면 1초당 1MiB씩, 합계 100MiB 새로운 메모리 영역에 접근합니다: ")
  input()
  
  for i in range(0, ALLOC_SIZE, PAGE_SIZE):
      memregion[i] = 0
      if i%ACCESS_UNIT == 0 and i != 0:
          show_message("{} MiB 진행중".format(i//(1024*1024)))
          time.sleep(1)
  
  show_message("새롭게 확보한 메모리 영역에 모두 접근했습니다. 엔터 키를 누르면 종료합니다: ")
  input()

시스템 전체 메모리 사용량 변화를 확인하기

시스템 전체 페이지 폴트 발생 상황을 확인하기

sar -B : 시스템 전체의 페이지 폴트 발생 횟수를 확인할 수 있다.

예제에서 프로그램이 확보한 메모리 영역에 접근했을 때만 초당 페이지 폴트 횟수를 뜻하는 fault/s 필드가 늘어나는 걸 알 수 있다.

프로그래밍 언어 번역기와 메모리 관리

데이터를 정의할 때마다 mmap() 호출 ㄴㄴ

프로그래 시작 시 mmap() 시스템 콜해서 어느 정도 크기의 영역을 미리 확보한다.

페이지 테이블 계층화

프로세스가 물리 메모리를 400바이트만 사용한다면 평탄한 페이지 테이블은 아래처럼 된다.

이에 비해 계층형 페이지 테이블을 사용한다면, 4페이지가 한 단위인 2단 구조로 만들 수 있다.

이렇게하면 페이지 테이블 전체 엔트리 개수가 16개에서 8개로 줄어든다. 만약 사용하는 가상 메모리 용량이 커진다면 페이지 테이블 사용량이 늘어난다.

모든 프로세스의 페이지 테이블에 필요한 합계 메모리 용량은 평탄한 페이지 테이블보다 계층형 페이지 테이블 쪽이 작은 경우가 대부분이다.

x86_64 아키텍처라면 4단 구조 페이지 테이블을 사용한다. 계층형 페이지 테이블을 통해 페이지 테이블에 필요한 메모리 용량을 크게 줄인다.

sar -r ALL : kbpgtbl 필드에서 페이지 테이블이 사용하는 메모리 확인 가능

Huge Page

1페이지당 크기가 400바이트인 Huge Page로 변경

페이지 테이블 엔트리 개수가 20개에서 4개로 줄음. 이렇게 하면 페이지 테이블이 사용하는 메모리 사용량도 줄어든다.

게다가 fork() 함수에서 페이지 테이블을 복사하는 비용도 줄어서 fork() 함수 처리가 빨라지는 효과도 기대할 수 있다.

💡DB나 가상 머신 매니저처럼 가상 메모리를 대량으로 사용하는 SW라면 Huge Page를 사용하는 경우가 있음

+) mmap() 함수의 flags 인수에 MAP_HUGETL 플래그 지정 시 사용 가능

Transparent Huge Page(THP)

메모리 확보시 일일이 Huge Page가 필요하다고 요청해야 하므로 프로그래머 입장에서는 번거롭다.

→ 리눅스의 THP 기능으로 해결 가능

THP는 연속된 여러 4KB 페이지가 어떤 조건을 만족하면 그걸 하나로 묶어서 자동으로 Huge Page로 바꾼다.

단점 : 여러 페이지를 합쳐서 하나의 Huge Page로 만드는 데 들어가는 비용, 그리고 Huge Page를 구성하던 조건이 성립하지 않게되면 커다란 페이지를 4KB 페이지로 다시 분할하는 처리 때문에 부분적으로 성능이 떨어지는 경우가 있다.

→ 관리자가 선택적으로 결정.

Uploaded by N2T