리눅스 memory fault - linugseu memory fault

10 More Discussions You Might Find Interesting

1. Solaris

M4000 Memory Fault

Hi Guys and Gals, Does anyone know how to track down a faulty DIMM on the memory board of an M4000? showhardconf tells me which board it is, but was wondering if there was a way to track it down to a DIMM? Thanks in advance Martin (5 Replies)

Discussion started by: callmebob

2. Homework & Coursework Questions

Memory fault(coredump)

I am writing a program that copies a program and prints the program with a line count. this is the program I wrote: #include <stdio.h> main() { int c; int nl_cnt = 0; while((c = getchar()) != EOF){ if(c = '\n'){ nl_cnt++;... (3 Replies)

Discussion started by: heywoodfloyd

3. UNIX for Dummies Questions & Answers

Page Fault + Memory

I am not sure where to post this so i will put it in the newbie section. I have set up a bog standard debain 6, LAMP environment in the cloud. The specs 1 core at 2GH 2.5gb Memory running Jommla, with about 1.6K visitors a day. I am using AppFirst (appfirst.com) to monitor the... (2 Replies)

Discussion started by: waseem

4. Linux

Help with memory fault

We have migrated our application from HP UX to linux. The code is in 4gl and after migration it has started giving Memory fault while running a batch job. The trace shows segmentation fault after a series of recvfrom and sendto(DB read) sigsegv segmentation fault @ 0 0 killed by SIGSEGV The... (2 Replies)

Discussion started by: aimee

5. UNIX for Advanced & Expert Users

Setui(0) memory fault

Hi i have this code that used to wrok fine in unix mp-ras. After the migration to linux suse i recompiled the script and now when it is executed i get a Memory fault (coredump) message. Does anybody knows why' what should I change? tks SCRIPT #include <stdio.h> #include <sys/types.h>... (1 Reply)

Discussion started by: mrodrig

6. UNIX for Dummies Questions & Answers

mysql memory fault

I (think I) installed MYSQL on a Red Hat box. When I try to start mysql I get a memory fault error. Any ideas on how to fix this? Here is some info that might help: My distro info $ cat /proc/version Linux version 2.4.21-40.ELsmp (bhcompile@hs20-bc1-7 .build.redhat.com) (gcc version 3.2.3... (0 Replies)

Discussion started by: wsetchell

7. Ubuntu

Memory fault(coredump)

Hey guys, I am new to the Linux world and have a question to post. When I ssh from a HP-UX machine to a ubuntu machine I get the following error message Memory fault(coredump) i.e. ssh 192.168.1.3 I get this message as shown below Memory fault(coredump) Can someone please explain... (2 Replies)

Discussion started by: fkaba81

8. UNIX for Advanced & Expert Users

Memory fault in ql session

Hi, Am getting memory fault when i start ql session in SCO unix server. Can any one suggest the way to solve this issue. Thanks (0 Replies)

Discussion started by: param_it

9. Programming

memory fault

When I excute a program . It seems to generate an error : memory fault (core dump ) So how can i (1 Reply)

Discussion started by: iwbasts

10. Programming

Memory fault(coredump)

Dear All, I made a program which do some simple jobs like reading data from other process's shared memory and writing messages to the queues of other process. what happens is my program works fine and do all the task as expected but then then program ends it give Memory fault(coredump). I... (0 Replies)

Discussion started by: ralo

이 글은 다음의 영상을 참고하여 다시 정리한 것입니다 :)

개인적으로 공부를 위해 정리한 글입니다. 글보다는 영상을 보실 것을 추천드립니다!!!

[10분 테코톡]현구막의 리눅스 메모리 관리

리눅스 memory fault - linugseu memory fault

메모리가 관리되는 방법

메모리 -> 주소로 인덱싱을 하는 커다란 배열.

컴퓨터가 부팅되면 운영체제 같은 프로그램이 메모리에 차곡차곡 쌓이면서 CPU 점유 기다립니다.

운영체제도 하나의 프로그램입니다. 즉 운영체제도 메모리에 올라갑니다.

우리가 사용하는 문자들(코드들)은 CPU가 이해하지 못하므로 CPU가 이해할 수 있는 숫자로 바꿔줘야 합니다.

사람이 이해할 수 있는 코드를 CPU가 이해할 수 있는 숫자로 바꿔주는 것이 바로 컴파일러 입니다.

String a;

String b;

위에서 a,b 와 같은것을 심볼릭 주소(Symbolic Address)

그리고 00, 01, 02 같이 CPU가 이해할 수 있는 숫자로 바꾼 주소를 논리 주소(Logical Address)라고 합니다.

그렇다면 각각의 프로그램을 실행했을때 부여되는 논리 주소는 중복이 발생할 수 있습니다.

A 프로그램이 00 ~ 19 라는 논리 주소를 가졌다면

B 프로그램도 00 ~ 19 라는 논리 주소를 가질 수 있습니다.

-> 각각 프로그램마다 중복되는 논리 주소를 가지고 있습니다. 그래서 논리 주소 == 가상 주소 라고도 부릅니다.

그렇다면 중복되는 논리 주소들이 쏟아져 나오는데 메모리에서 어떻게 구별하는 걸까요?

  • 메모리에 하나의 주소값을 더합니다.
  • 각 프로그램의 독립된 주소는 이때 생깁니다.
  • 이렇게 생성된 독립적인 주소를 물리 주소 라고 합니다.
심볼릭 주소를 바로 물리적 주소로 사용하면 되는데 굳이 물리 주소를 한번 더 더하는 이유는 무엇일까요?
CPU는 논리 주소만 읽습니다. CPU는 현재 활동중인 프로세스 내부의 주소만 알면 되지 어떤 프로세스인지는 알 수 없을뿐만 아니라 알 필요도 없습니다.

MMU

CPU는 논리 주소만으로 물리 메모리에 올라가 있는 프로세스 내부의 정보를 읽을 수 있습니다. 어떻게 가능할까요?

'운영체제가 해주는것이 아닐까?' 라고 생각할 수 있지만 운영체제도 메모리에 올려져서 CPU를 할당받아 동작하는 프로세스 중 하나입니다. 즉, CPU가 프로세스의 정보를 읽는 것에 소프트웨어는 도움을 줄 수가 없습니다.

결국 CPU는 MMU(Memory Menagement Unit)라는 하드웨어의 도움을 받아서 프로세스 내부의 정보를 읽어옵니다.

MMU는 다음과 같은 요소를 가집니다.

  • 프로그램의 시작주소를 가진 Base Register
  • 프로그램의 마지막 주소를 가진 Limit Register
  • 간단한 산술 연산기

프로세스가 요청하는 논리 주소에 Base Register에 들어있는 시작주소를 붙여서  물리주소로 변홥시킵니다.

ex. 프로세스가 요청하는 논리 주소 16 + Base Register 시작 주소 0200 = 0216(물리주소)

이렇게 완성된 물리 주소로 메모리에서 프로세스가 가진 정보를 정확하게 찾아서 읽어올 수 있습니다.

Base Register가 동작하여 물리주소로 변환하기 전에는 선행 동작이 필요합니다.

바로 Limit Register에 들어있는 마지막 주소로 프로세스가 요청하는 논리 주소가 올바른지 확인합니다.

만약 악의적인 프로그램이 본인의 마지막 주소가 219인데도 불구하고 325번의 번호를 달라고 요청하면 325번을 차지하고 있던 다른 프로그램의 정보를 읽어옵니다.

Limit Register는 다른 프로그램의 정보를 읽어오는 것을 방지합니다.

  1. Limit Register에 들어있는 마지막 주소로 체크합니다.
  2. 마지막 주소 이상의 주소라면 해당 프로세스를 멈춥니다. (정상적인 주소라면 요청을 처리합니다.)
  3. CPU의 권한을 운영체제에게 넘깁니다.
  4. 깨어난 운영체제는 프로세스가 왜 멈췄는지 확인하고 악의적인 이유라면 요청을 중지시킵니다.

Swapping 기법

이제 메모리에 프로세스들이 쌓이는것에 대해 이야기하겠습니다.

메모리에 프로세스들이 차례대로 차곡차곡 쌓인다면 좋겠지만 그렇지 않습니다.

차례차례 프로세스를 쌓을 경우 메모리에 아무도 사용하지 못하는 빈 구멍들이 생기기 시작합니다.

처음에 프로세스를 쌓을때는 차곡차곡 쌓이지만 사용도중 프로세스가 교체되는 과정에서 다른 프로세스는 필요한 공간이 작거나 크기때문에 빈 공간들이 발생합니다.

즉 아래 그림에서 B라는 프로세스의 2/3 공간을 차지하는 새로운 프로세스로 교체됐을 때 1/3은 빈공간으로 남게됩니다.

리눅스 memory fault - linugseu memory fault

메모리에 빈공간이 계속 발생하다보면 위와같이 분명 빈공간을 합치면 프로세스를 올릴 수 있음에도 올릴 수 없는 현상이 발생합니다.

메모리가 가득 찼을 때 새로운 프로세스를 메모리에 올려야 한다면 우선순위가 높지않은 프로세스를 일시적으로 메모리에서 하드디스크의 Swap 공간으로 보내는 Swapping 기법을 사용합니다.

하지만 Swapping 기법도 만능이 아닙니다. Swappin할 프로세스를 고르는것도 일입니다.

중요도에 따라 Swapping할 프로세스를 선택하려 해도 프로세스를 하나씩 검사하는 과정이 필요하기 때문에 시간이 걸립니다.

그리고 중요도 계산을 끝내고 프로세스를 옮긴다해도 하드디스크로 프로세스 전체를 옮기는 작업은 단순하게 작은 파일을 주고 받는것과 달리 많은 시간이 걸립니다. 반대로 Swap 공간에서 다시 꺼내오는 경우도 오래걸립니다.


Paging 기법

Swapping 기법의 단점을 보완하기 위해 메모리 공간에서 일정하게 잘라두고 그에 맞춰 프로그램을 조금씩 잘라서 올리는 방법을 사용합니다.

프로그램을 잘라서 올리는 것을 페이징(Paging) 기법이라고 합니다.

  • 물리적인 메모리를 동일한 크기로 자릅니다. -> Frame
  • 프로그램을 Frame과 동일한 크기로 자른 하나의 조각 -> Page

잘려진 Page들 중에 당장 실행에 필요한 최소한의 Page들만 메모리에 올리고 나머지는 Swap 공간에 저장합니다.

Page Table

페이징 기법 덕분에 메모리에 사용하지 못하고 낭비되는 구멍은 거의 없어졌습니다.

하지만 한 프로그램의 Page가 메모리 여기저기 분포하게 됐고 순서도 보장할 수 없게됐습니다. MMU의 계산또한 복잡해졌습니다.

이런 단점을 보완하기 위해 Page Table을 사용합니다.

논리주소 -> 물리주소 변환을 위한 별도의 Page Table을 사용합니다.

추가로 Page Table 때문에 MMU의 요소들 이름과 용도도 조금씩 달라집니다.

  • Base Register -> Page Table Base Register (Page Table의 시작주소를 더해줍니다.)
  • Limit Register -> Page Table Length Register (Page Table의 길이로 체크합니다.)

CPU가 MMU한테 논리적인 주소로 요청을 하게되면, 계산이 끝난 값으로 Page Table을 참조해서 찾아낸 Frame주소로 이동해 해당 Page의 정보를 읽어옵니다.

Page Table은 어디에 저장될까?

페이지 테이블의 행 개수는 해당 프로그램의 크기를 일정한 간격으로 나눈 개수입니다.

프로그램마다 전체 크기가 다르겠지만 Page Table의 행은 대다수가 100만개가 넘습니다.

Page Table은 메모리에 저장됩니다.

메모리 공간을 알차게 사용하자고 페이징 기법을 적용했는데 Page Table이 공간을 차지해버렸습니다. Page Table의 크기도 작지않습니다. Page Table은 물리 메모리에 있는지 하드디스크에 있는지 빠르게 검사하기 위해 Valid 라는 bit 요소를 가지고 있습니다.

Shared page

Page Table이 메모리를 차지했으므로 그만큼 공간을 줄여줘야 합니다. 그래서 적용시킨것이 자주 쓰는 라이브러리들을 모든 메모리에 1개씩만 올리고 공통적으로 사용하는 프로세스들이 나눠쓰게 만든것입니다.

이것을 Shared Page(공용으로 사용하는 페이지)라고 합니다.

  • Shared Page의 정보는 절대 바뀌면 안되므로 Read-Only 옵션을 가집니다.
  • 각각의 프로그램들이 쉽게쉽게 찾을 수 있도록 서로 동일한 논리주소에 위치해야합니다.
  • 위 두 조건 중 하나라도 만족하지 않으면 shared page 로써 사용될 수 없습니다.
  • Page Table에 Page의 read / write 같은 권한을 표시하기위해 권한에 대한 bit 요소가 추가됩니다.
CPU에 Page Table 저장?
100만개가 넘는 행을 가진 Page Table이 프로세스마다 1개씩 존재하는데 이걸 CPU에 저장하는건 부담이 너무 큽니다.

하드디스크에 Page Table 저장?
메모리 주소에 접근하기 위해서 Page Table을 사용하는데 하드디스크에 Page Table을 넣을바엔 하드디스크에 넣어서 프로그램을 돌리는게 더욱 빠를것입니다.


TLB

이제 Page Table로 인한 공간 증가에 대해 Shared Page를 사용해서 공간을 줄였습니다.

하지만 속도에 문제가 발생합니다.

Page Table은 메모리에 위치합니다. Page또한 메모리에 위치하고 있습니다.

즉, CPU는 메모리에 요청해서 Page Table에 있는 Page의 주소를 받아서 메모리에 또 한번 요청을 보내야 프로세스 내부의 정보를 가져올 수 있습니다. Page Table로 인해 명령 수행 시간이 2배가 됐습니다.

  1. CPU -> 메모리에 있는 Page Table에게 Page 주소 조회 (Page 주소 좀 알려줘~)
  2. CPU -> 메모리에 있는 Page 조회

이런 상황을 TLB(Translation look-aside buffers)라는 하드웨어의 지원을 받아 해결합니다.

TLB는 Page Table을 보기전 캐시된 정보를 찾아보는 캐시 메모리입니다.

TLB는 병렬적으로 자신이 가진 정보를 조회하여 속도 향상을 위해 존재합니다.

CPU가 논리 주소로 요청하면 Page Table에 접근하기 전, 우선 TLB부터 확인합니다.

TLB에 매칭되는 주소가 있으면 TLB에 있는 Frame 주소로 바로 변환을 해서 메인 메모리에서 정보를 가져옵니다.

TLB에 매칭되는 주소가 있어 바로 정보를 가져오는 것을 HIT 라고 합니다.

TLB에 주소가 없으면 Page Table을 참고해서 주소변환 진행합니다. 이때는 어쩔 수 없이 메모리에 2번 접근합니다. (이때 TLB에 해당 정보를 캐시합니다.)

'2번 접근하는거면 수행 속도에 별 차이가 없는것 아닌가?' 라고 생각할 수 있지만 대부분 프로세스는 한번 참조했던 곳을 다시 참조할 가능성이 굉장히 높습니다. 즉 TLB의 HIT 확률이 높습니다.


정리

  • 현대 메모리는 Paging을 베이스로 한 기법을 채택
  • 하드디스크는 Swap area로 활용합니다.
  • MMU, TLB 같은 하드웨어들의 지원을 받아 PageTable을 확인하고 메모리를 참조합니다.

리눅스 (운영체제)는 어디서 메모리 관리에 기여하고 있을까요?

크게 두가지가 있습니다.

  1. 가상 메모리로 사용자 프로세스 속이기
  2. I/O 장치 관리

CPU를 점유중인 프로세스는 자신이 커다랗고 온전한 메모리에 올라가있다고 생각합니다.

하지만 실제로는 현재 동작에 필요한 부분만 물리 메모리에 존재하고 나머지는 Swap 영역에 존재합니다.

이렇게 물리 메모리 공간과 Swap 공간을 합쳐서 만들어낸 가짜 메모리를 가상 메모리(Virtual Memory) 라고 합니다.

페이징 기법 중 CPU를 통해 요구하던 논리 주소가 바로 이 가상 메모리상의 주소, 가상 주소입니다.

주소를 변환하고 메모리에서 Page를 찾아내는건 사용자 프로세스와 하드웨어(MMU, TLB)에서 진행하지만, 하드디스크같은 입출력 장치를 건드리는 것은 운영체제의 관할입니다.

즉, Swap 공간에서 Page를 꺼내려면 운영체제의 도움이 필요합니다.

Page Fault

Page Fault는 요구하는 페이지가 메모리에 없고 Swap 영역에 있어서 Swap 영역에 있는 페이지를 가져와야하는 경우를 의미합니다.

프로세스가 CPU를 점유하고 한참 작업을 이어가던 중 TLB와 메모리에 없는 페이지를 요구하면 메모리에 없다는걸 눈치챈 MMU가 프로세스를 일시정지하고 운영체제에게 CPU 권한을 넘깁니다.

운영체제는 프로세스가 왜 멈췄는지 체크하고 만약 이상한 주소로의 요청이라면 요청을 중지합니다.

정상적인 요청이라면 운영체제가 하드디스크의 Swap공간에서 페이지를 메모리로 가져오고 TLB에 주소를 등록 + Page Table에도 Valid bit와 함께 업데이트합니다.

그 후 운영체제는 CPU를 다시 넘기고 휴식에 들어갑니다. MMU에 의해 프로세스가 멈춘 직후부터 Swap 공간에서 페이지를 가져오기까지 시간이 길어서 도중에 CPU가 다른 프로세스에게 넘어갈 수 있습니다. 이럴 때 기존 프로세스는 대기 큐에 들어가서 다시 자기 차례를 기다립니다.

그렇지 않은 경우 다시 기존 프로세스에게 CPU가 넘어가고 명령 수행을 실패한 지점부터 동작을 수행하게 됩니다.

Page fault 가 발생하면 CPU가 다른 프로세스로 넘어갈 만큼 굉장히 많은 시간이 소모됩니다. (Page fault는 성능에 큰 영향이 있습니다.)

하지만 컴퓨터 프로그램의 특성상 중복된 내용의 참조가 많아서 fault 확률은 낮습니다. 대부분 TLB를 참조하면서 굉장히 빠르게 작업이 진행됩니다.

CPU가 계속 작업을 하면서 Page Fault 때문에 Swap공간에서 Page를 계속 가져오다가 물리 메모리의 Frame이 가득 차게되면 어떻게 될까요?

  • 다음 Page Fault때 Swap공간에서 Page를 가져오기 위해 기존 메모리의 Frame을 차지한 Page중 하나를 Swap공간으로 보내야합니다.
  • 이런 행위를 Page Replacement라고 합니다. 어떤 Page를 Replacement할지는 운영체제가 담당합니다.

Clock Algorithm

Page Replacement를 위해 Frame을 차지한 Page중 하나를 선택해야하는데 가장 참조가 오래된 페이지를 찾아내는 LRU 알고리즘이 있습니다. 하지만 운영체제는 이미 물리 메모리에 있었으면서 Page Fault를 회피한 Page들에 대한 정보는 알 수 없고 Page Fault때 관리했던 Page들에 대한 상황만 알 수 있습니다. 즉, LRU에 필요한 페이지들의 참조 시점 정보를 반만 알고있게 됩니다.

LRU는 사용할 수 없습니다.

그래서 사용하는것이 Clock Algorithm 입니다.

리눅스 memory fault - linugseu memory fault

모든 페이지마다 1개의 reference bit를 갖게하고 초기에는 모두 0이다가 CPU를 점유중인 프로세스로부터 참조하면 1이 됩니다.

replacement가 발생하면 시계방향으로 돌면서 1bit를 만나면 0bit로 만들고 0bit를 만나면 replacement 대상 Page로 지정합니다.

  • Reference Bit 는 Page Table에 추가되어 관리합니다.
  • Clock Algorithm은 운영체제가 하드웨어의 도움을 받는 알고리즘입니다.

이렇게 replacement를 통해 Page를 쫒아낼 때는 변경사항이 있는지 체크를 하고 변경사항이 있다면 하드디스크에 해당 변경된 내용을 반영해줘야 합니다. 따라서 변경사항을 알아내기위해 Dirty Bit이 Page Table에 추가됩니다.

Page Table은 아래와 같이 구성됩니다.

Page Frame Valid Auth Ref Dirty
Game 1 v R/W 0 0

Trashing

하드웨어에 변경사항을 반영하고 Page Table에 기록하는 것은 모두 운영체제가 수행합니다.

메모리에 프로세스가 많아질 수록 프로세스당 물리 메모리에서 사용할 수 있는 frame의 양이 줄어듭니다.

메모리에 프로세스는 많이 올라왔지만 frmae의 양이 줄어드므로 CPU가 사용될 기회가 줄어듭니다.

CPU의 점유율이 낮으면 운영체제는 더 많은 프로세스를 메모리에 올리는데 이것은 위에서 얘기한것과 악순환이 됩니다.

이런 현상을 Trashing 이라고 합니다.

Trashing 을 해소하기 위해 Working-set 알고리즘과 Page Fault Frequency 알고리즘을 사용합니다.


Working-Set 알고리즘

Working-set 알고리즘은 대부분의 프로세스가 일정한 페이지만 집중적으로 참조한다는 성격을 이용해서 특정 시간동안 참조되는 페이지의 개수를 파악하고, 그 페이지의 개수만큼 Frame이 확보되면 그 때 Page들을 메모리에 올리는 알고리즘입니다.

만약 Page가 3개 필요한데 메모리에서 Frame을 2개밖에 못준다면 운영체제는 굳이 Page를 3개 중 2개만 올리지 않고 Swap 공간에서 기다립니다. Frame이 3개가 확보되면 그때 메모리에 올립니다.

Frame이 가득차면 이때 Replacement가 동작하는데 이때도 Working-Set 단위로 Page를 Swap공간으로 보냅니다.


Page Fault Frequency 알고리즘

Page Fault 퍼센트에 상한과 하한을 줍니다.

상한선을 넘으면 지급하는 Frame 개수를 늘리고

하한선을 넘으면 Frame의 개수를 줄입니다.

Page Fault Frequency 알고리즘도 남는 frame이 없으면 프로세스 단위로 page들을 통째로 쫒아내게 됩니다.


메모리 고갈 상황과 CPU 사용률을 체크하는 이유

1. 메모리가 고갈되면 어떤 상황이 발생하는가?

프로세스들의 Swap이 활발해지면서 CPU 사용률이 하락합니다. 운영체제가 프로세스를 추가하면서 Trashing이 발생합니다.

Trashing이 해소되지 않을 경우 Out of Memory 상태로 판단합니다.

중요도가 낮은 프로세스를 찾아 강제 종료시킵니다.

2. CPU 사용률을 계속해서 체크하는 이유

특정 시점만 체크한 경우 CPU 사용률이 높아보일 수 있습니다.

계속해서 CPU 사용률을 관찰하면 사용률이 급격하게 떨어지는 구간이 발생할 수 있습니다.

메모리 적재량을 함께 체크하면서 쓰레싱 유무를 확인합니다.

이를 해소하기 위해 추가적인 서버자원을 배치하는 등 해결 방안을 마련해야합니다.