y-log

Elasticsearch를 처음 설치하다 보면 항상 보는 에러들이 몇 가지 있습니다.

 1) root 계정으로 실행할 수 없으며

 2) openfiles, max process 값을 수정해야하고

 3) swappiness 값 설정 변경 요청도 있습니다.

Elasticsearch 실행 시 발생한 Max user processes Error

그 중에 elasticsearch는 openfiles와 max process는 최소 65535로 설정하라며, 커널에서 해주는 기본 설정보다 큰 값을 요구하는데요,

오늘은 해당 파라미터가 정확히 어떤 것을 가르키는지 그리고 설정된 값 이상이 되면 어떤 일이 일어나는지 알아보겠습니다.

1. Max user processes

Max user processes의 의미는 하나의 계정에서 최대로 실행할 수 있는 process의 개수를 말합니다. OS에서의 확인은

# ulimit -a (sofe ulimit)

# ulimit -aH (hard ulimit)

위 명령으로 확인 가능합니다. (현재 제 서버의 설정 값은 아래와 같습니다.)

max user processes

그럼 아래 테스트 코드를 통해 설정된 max user processes의 값을 넘기면 어떻게 되는지 확인해보겠습니다.

4000개 Thread 생성 후 유지

대략적인 코드의 내용은 HTTP 요청이 오면 비동기로 4천개의 Thread를 동시에 생성하고 20분간 유지하는 코드입니다.

그리고 실제로 Thread를 늘려보면,

Thread 생성 중 OOM 발생

그림처럼 ulimit -a 명령의 max user processes 결과와 같이 ec2-user 계정은 1024개까지 스레드를 생성한 후, OOM 에러 메세지를 발생하며 멈춰버리게 됩니다. (이 경우 ec2-user 계정에서는 쉘 명령어 입력 등 어떤 작업도 동작하지 않습니다.)

<리눅스에서는 스레드와 프로세스를 동일하게 봅니다.>

2. Open files

다음은 Open files입니다. 이 값은 프로세스가 가질 수 있는 최대 파일의 개수를 의미합니다.

리눅스는 모든 프로세스나 세션(소켓)들을 파일로 관리하기 때문에 이 값의 설정은 서버에서의 Connection연결 작업에 매우 중요한 내용이 됩니다.

(설정 값을 넘어가게 되면 리눅스에서 파일을 열 수 없어 프로세스 실행이나 Connection 연결이 안되기 때문!)

그럼 소켓을 open files 값 보다 많이 만들어 테스트를 해보겠습니다.

(1) Java 환경 TEST

 - RestTemplate로 소켓 생성 요청을 보내고, 요청을 받은 서버에서 20분간 응답을 대기 시킵니다.

 - 요청을 동시에 1100개를 보내 open files가 1024로 제한인 서버에 에러가 발생하면 테스트 성공입니다.

   (기본적으로 java, spring 관련 file이 몇 개 오픈됩니다.)

아래는 테스트 코드 일부입니다.

connection 소켓 생성 후 응답 대기 Code

그리고 동시에 요청을 보낼 API 요청 스크립트를 작성합니다.

API 요청 쉘

쉘을 실행하여 테스트를 진행하면…

openfiles 개수가 1024 값을 넘어 1516개 까지 열림!

위 그림처럼 소켓이 1024개가 넘어도 에러 메시지 없이 동작하는 것을 볼 수 있습니다. 그럼 한번 더 스크립트를 실행해보겠습니다.

2048개 까지 생성된 모습

이제 에러가 발생했습니다. 파일은 딱 2048개 까지만 열린 것을 확인할 수 있는데요, openfiles의 값은 soft로 설정된 값이 아닌

그림처럼 Hard 옵션 값까지 file이 생성된다는 것을 알 수 있습니다.

그런데…! 알고 보니 java 환경에서는 hard 값을 따라가는게 맞지만 Python에서는 아니라고 합니다…

(2) Python 환경 TEST

빨간 박스 : 1024개의 열린 파일 생성 / 파란 박스 : 1024개 이후 파일을 하나 더 열어본다

위 처럼 파이썬 스크립트로 file을 임의로 열어봅니다. 1021개 까지는 파일이 문제없이 열리지만(stdin, stdout, stderr 표준 입/출력 3개 제외)

이후로 여는 파일에서는 Too many open files 에러가 발생합니다!

(3) Java와 Python 환경의 차이?

테스트 결과 Java는 hard 옵션까지 파일이 오픈되고 Python은 soft 값까지 오픈됨을 알 수 있었습니다. 그 이유를 찾기 위해 strace 명령을 통해 java 프로세스 동작을 추적해보면

kernel 5.15ver에서 테스트 (이전 버전은 prlimit64 함수 대신 getrlimit, setrlimt 함수 사용)

위 그림처럼 java 프로세스가 시작됨과 동시에 prlimit64라는 함수가 rlim_cur=1024값을 rlim_max=2*1024(hard limit) 값까지 업데이트하는 로그가 찍혀있는 것을 볼 수 있었습니다.

JDK에서 MaxFDLimit 옵션 활성화 (기본값)

그 이유는 설치된 JVM에서 MaxFDLimit 옵션을 통해 limit을 올려주었기 때문이라고 합니다! (기본적으로 활성화된 옵션)

즉, 리눅스 OS에서는 JDK 실행 시 커널에서 prlimit64 함수를 통해 자동으로 limit 사이즈를 증가시켜준다는 것을 알 수 있었습니다.

3. 정리

 - (Linux 환경) JAVA에서 동시에 생성 가능한 쓰레드 수는 Max user processes를 따라간다.

 - (Linux 환경) JAVA에서 소켓 통신(API나 모든 Connection)은 open files 옵션을 따라간다.

  -> JAVA에서는 JDK 코드에서 자동으로 soft limit값은 hard limit값까지 업데이트 됨

  -> Python은 soft limit 값에서 제한이 걸림

나의 개발 환경에 맞게, Max user processes와 open files의 적절한 값을 찾아 설정하는 것이 중요하겠습니다!

<공동저자>

https://giraffe-lee.tistory.com/7

<참조>

https://techblog.woowahan.com/2569/

IPC란?

프로세스는 독립적으로 실행된다.
이처럼 독립적인 공간을 가진 프로세스 간 통신에 사용되는 기법이 IPC 통신이다.
프로세스는 커널이 제공하는 IPC 설비를 이용해 프로세스 간의 통신을 할 수 있게 된다.

• IPC = Inter-Process Communication
• 프로세스들 사이에 서로 데이터를 주고받는 행위

• 위 그림처럼 우리가 사용하는 프로세스들은 모두 유저공간(user-space, user-mode)에서 개별로 OS로부터 할당받은 독립된 공간에서 운행중에 있다
• 말한것 처럼 프로세스는 독립된 공간에서 운행하다보니 서로간에 통신이 어렵다는 문제가 있다
• 이를 해결하고자 커널 영역(kernel-space, kernel-mode)에서 IPC(Inter-Process Communication)라는 프로세스들 간에 통신을 제공하고 있다
• 이처럼 프로세스들은 커널이 제공하는 IPC 기술을 통해 프로세스간에 통신을 할 수 있다

IPC의 종류

PIPE (파이프)

• 파이프는 두 개의 프로세스를 연결하고 하나의 프로세스는 데이터를 쓰기만 하고, 다른 프로세스는 데이터를 읽기만 한다
• 부모 자식 간에 단방향 통신으로 자주 사용한다
• 한쪽 방향으로만 통신이 가능한 PIPE의 특징 때문에 Half-Duplex(반이중) 통신 이라고도 불린다
• PIPE는 반이중 통신이기에 하나의 통신선로는 읽기/쓰기 중 하나만 가능하므로 만약 읽기/쓰기, 즉 송/수신을 모두 하기 원한다면 두 개의 파이프를 만들어야 가능하다
• read()와 write()가 기본적으로 block mode로 작동되기에 프로세스가 read 대기중이라면 read가 끝나기전에는 write를 할 수 없다

장점

• PIPE는 간단하게 사용할 수 있다는 장점이 있다. 한쪽 프로세스는 단지 읽기만하고 다른 프로세스는 단지 쓰기만 하는 단순한 데이터 흐름에 적합

단점

• Full-Duplex(전이중) 통신 방식으로 활용하려면 PIPE를 두개 만들어야 하는데, 구현이 꽤나 복잡해 질 수 있다 (굳이 전이중을 활용해야한다면 PIPE말고 다른 방법을 찾는게 효율적일 수 있다)
• buffer가 상대적으로 작기때문에 overflow 될 확률이 높다 (read처리를 빨리빨리 해줘야한다)
• 부모 자식 관계의 프로세스들 사이에서 가능

Named PIPE (익명 파이프)

• Linux는 모든 것을 파일(fd)로 통하고 있다는 개념을 기억하고 보자
• Named PIPE는 통신을 할 프로세스가 명확히 알 수 있는 경우 사용
• 보통 PIPE는 부모자식간에 사용하고 Named PIPE는 전혀 모르는 상태의 프로세스들 사이에서 통신할 경우 사용
• Named PIPE는 부모프로세스와 무관하게 전혀 다른 모든 프로세스들 사이에서 통신이 가능한데, 이유는 프로세스간에 통신을 위해 이름이 있는 파일을 매개체로 사용하기 때문
• mkfifo를 통해 Named PIPE를 생성하는데, mkfifo가 성공하면 이름이 명명된 파일이 생성되고 이를 활용해서 프로세스 간에 통신이 이루어짐

장점

• 기본 PIPE와 비슷

단점

• 읽기/쓰기가 동시에 이루어지지 않음, 단방향 통신, read-only or write-only
• 기본 PIPE와 비슷

PIPE 와 Named PIPE

공통점
먼저 입력된 데이터가 먼저 전달되는 흐름을 가진다는 측면에서 동일한 데이터 흐름 메커니즘을 가진다

차이점
Named PIPE는 사용할 PIPE를 명명할 수 있다는 점
PIPE는 사용할 PIPE를 명명할 수 없다
(그렇기 때문에 PIPE는 익명 PIPE라 부른다)


추가 설명
익명 파이프(PIPE)는 데이터 통신을 할 프로세스가 명확하게 알 수 있을 때 사용
송신할 프로세스는 수신할 프로세스를 알고, 수신할 프로세스는 송신할 프로세스를 아는 경우
가장 대표적인 예가 부모프로세스와 자식프로세스간에 데이터 통신을 하고자 할 때 부모 프로세스와 자식 프로세스는 서로를 명확히 알고 있으므로 굳이 파이프에 이름을 줄 필요가 없을 것이다

반면, 자식과 부모 관계가 아닌 전혀 모르는 프로세스들 사이에서 pipe를 이용해서 통신을 해야하는 경우는 우리가 생판 모르는 사람과 대화를 하려면 이름을 알아야 하듯 pipe에 이름을 주어져야 한다, 그것이 Named PIPE를 만든 이유이다

Message Queue (메시지 큐)

• FIFO(First-In First-Out, 선입선출) 자료구조를 가지는 통신설비로 커널에서 관리
• 입출력 방식으로보면 위에 Named PIPE와 동일하다 할 수 있다
• 차이점이라면, Named PIPE는 데이터의 흐름이라면 Message Queue는 메모리 공간이라는 점
• 어디서나 물건을 꺼낼 수 있는 컨테이너 벨트와 같다 보면 된다
• Message Queue에 쓸 데이터에 번호를 붙힘으로써 다수의 프로세스가 동ㅇ시에 데이터를 쉽게 다룰 수 있다

장점

• 비동기 방식이기에 방대한 처리량이 있다면 큐에 넣은 후 나중에 처리 할 수 있다
• 다수의 프로세스들이 큐에 메시지를 보낼 수 있고 다수의 프로세스들이 큐로부터 메시지를 꺼낼 수 있다
• 분산처리 및 경쟁처리 방식에 사용할 수 있다
• (비동기, 비동조, 탄력성, 과잉, 확장성이 있는데 이건 다른 포스트 참조해도 충분할 거 같다)

단점

• 메시지가 정말 잘 전달되었는지 알 수 없다
• 큐에 데이터를 넣고 나오는 과정에서 오버헤드가 발생 할 수 있다
• 데이터가 많이 쌓일수록 추가적인 메모리 자원이 필요하다

Shared Memory (공유메모리)

• 데이터 공유 방법에는 크게 2가지가 있는데,

1. 통신을 이용해서 데이터를 주고 받는 방법 (ex. PIPE, Named PIPE, Message Queue, ...)
2. 데이터를 공유, 즉 함께 사용하는 것 (ex. Shared Memory, ...)

• • 즉, 공유메모리가 데이터 자체를 공유하도록 지원하는 설비이다
  • Shared Memory(공유 메모리)는 프로세스간 메모리 영역을 공유해서 사용할 수 있도록 허용
  • 프로세스가 공유 메모리 할당을 커널에 요청하면 커널은 해당 프로세스에 메모리 공간을 할당해 주게되고, 이후 어떤 프로세스건 해당 메모리영역에 접근 할 수 있다
  장점
  • 공유 메모리는 중개자 없이 곧바로 메모리에 접근할 수 있기 때문에 모든 IPC중에서 가장 빠르게 작동한다
  • (다시말해, 커널메모리영역에서 관리하기에 빠르게 접근 가능)
  단점
  • 메시지 전달 방식이 아니기에 데이터를 읽어야하는 시점을 알 수 없다
  • 커널 설정에 종속적이기에 사용하기전에 커널에서 허용하고 있는 공유메모리 사이즈를 확인해야 한다

Semaphore (세마포어)

• PIPE, Named PIPE, Message Queue와 같은 다른 IPC 설비들이 대부분 프로세스간 메시지 전송을 목적으로 하는데 반해,
• Semaphore는 프로세스 간 데이터를 동기화하고 보호하는데 그 목적이 있다
• 프로세스간 메시지 전송을 하거나 공유메모리를 통해 데이터를 공유하게 될 경우 발생하는 문제가 공유된 자원에 다수의 프로세스가 동시에 접근하면 안되며 단지 하나의 프로세스만 접근가능하게 해주는것이 세마포어(Semaphore) 이다
• 즉, 운영 체계 또는 프로그램 작성 내에서 공유 자원에 대한 접속을 제어하기 위해 사용되는 신호
• 한 프로세스가 사용하고 있는 동안에 세마포어를 세워서 다른 프로세스를 대기시키고 사용이 끝나면 해제시키는 방법으로 사용

(한가지 예를 들자면, 화장실에 갔을때 화장실 칸을 생각하면 된다. 화장실 한 칸에 대해 관리를 하는것이 뮤텍스이고 화장실 자체를 관리하는게 세마포어가 된다)

장점

• 많은 Thread들은 크리티컬 섹션을 허락받아야 한다. 즉, 크리티컬 섹션에서 충돌이 나지 않는다

단점

• 많은 Thread들은 block을 당한다. 즉, CPU가 가만히 waiting하는 시간 낭비가 발생할 수 있다

Memory Map (메모리 맵)

메모리 맵도 공유 메모리와 마찬가지로 메모리를 공유한다는 측면에서는 비슷하다

• • 차이점은 메모리 맵은 열린 파일을 메모리에 맵핑시켜서 공유한다는 점
  • 파일(fd)는 리눅스의 시스템의 전역적인 자원이므로 즉, 모두 공유할수 있는 자원이므로 서로 다른 프로세스들끼리 데이터를 공유하는데 문제가 없음을 예상할 수 있다
  장점
  • 데이터가 메모리에 이미 올라와있는 것처럼 간단하게 접근 할 수 있다
  • 일반적인 파일 IO에 비해 나은 성능을 보여준다
  • 비동기 IO를 사용하지만 시스템에서 처리해주기 때문에 스레드 문제를 걱정할 필요 없다
  단점
  • 일반 파일 IO에 비해 상당히 많은 메모리를 요구
  • 많은 데이터를 얼마나 오랫동안 메모리에 둘 것인지 컨트롤할 수 없다

Socket (소켓, UDS = Unix Domain Socket)

• 같은 도메인 내에서 연결 될 수 있고 프로세스들 사이의 통신을 가능하게 한다
• 서버단에서는 bind, listen, accept 진행해 소켓 연결을 위한 준비를 한다
• 클라이언트 단에서는 connect을 통해 서버에 요청하고 연결이 수립 된 후에서는 socket에 send 함으로써 데이터를 주고 받는다.
• 연결이 끝나면 반드시 close()로 clear 한다
• 즉, 네트워크를 통해 프로세스간에 통신을 진행한다

장점

• 서버/클라이언트 환경을 구축하는데 용이하다
• Internet Socket인 경우 데이터 유실이 발생할 수 있지만, Unix Domain소켓은 PIPE와 같은 형태로 이루어지고 같은 시스템에서 교환이 일어나므로 패킷이 유실되거나, 순서가 바뀌는 등 문제가 발생하지 않을거라 장담 할 수 있다
• 범용적인 IPC로써 양방향 통신이 가능하다
• 패킷 단위로 주고 받음으로 직관적으로 이해하기 쉬운 코드를 만들 수 있다

단점

• Internet UDP와는 달리 경로를 지정할 수 없다 (다중의 클라이언트를 받아들이는 서버의 경우 문제가 될 수 있다)

References.

link1 link2

시스템 콜이란?

운영 체제의 커널이 제공하는 서비스에 대해,
응용 프로그램의 요청에 따라 커널에 접근하기 위한 인터페이스이다.

보통 C나 C++과 같은 고급 언어로 작성된 프로그램들은
직접 시스템 호출을 사용할 수 없기 때문에
고급 API를 통해 시스템 호출에 접근하게 하는 방법이다.

✔ 시스템 콜은 왜 필요할까?

우리가 일반적으로 사용하는 프로그램은 '응용프로그램'이다.

유저레벨의 프로그램은 유저레벨의 함수들 만으로는 많은 기능을 구현하기 힘들기 때문에, 커널(kernel)의 도움을 반드시 받아야 한다. 이러한 작업은 응용프로그램으로 대표되는 유저 프로세스(User Process)에서 유저모드에서는 수행할 수 없다.

반드시 kernel에 관련된 것은 커널모드로 전환한 후에야, 해당 작업을 수행할 권한이 생긴다. 커널 모드를 통한 이러한 작업은 반드시 시스템 콜을 통해 수행하도록 설계되어 있습니다.

✔ 시스템 콜의 커널 모드와 사용자 모드

1. 커널 모드
프로그램 카운터가 운영체제가 존재하는 부분을 가리키고 있다면, 현재 운영체제의 코드를 수행 중이며 CPU가 커널 모드에서 수행 중이라고 한다.

2. 사용자 모드
프로그램 카운터가 사용자 프로그램이 존재하는 메모리 위치를 가리킬 경우, 사용자 프로그램을 수행 중이며 CPU가 사용자 모드에서 수행 중이라고 한다.

• 일반 명령 : 메모리에서 자료를 읽어와서 CPU에서 계산하고 결과를 메모리에 쓰는 일련의 명령들. 모든 프로그램이 수행할 수 있음. (사용자 모드)
• 특권 명령 : 보안이 필요한 명령으로 입출력 장치, 타이머 등 각종 장치를 접근하는 명령.(커널 모드)
• CPU 내에 모드 비트를 두어 두 명령을 수행한다.
• 사용자 프로그램이 디스크의 파일을 접근하거나, 화면에 결과를 출력하는 등의 작업이 필요한 경우가 있다. 하지만, 이러한 작업은 특권 명령의 수행을 필요로 한다.
• 이와 같은 경우, 사용자 프로그램은 스스로 특권 명령을 수행할 수 없으므로 운영체제에게 특권 명령의 대행을 요청한다. 이러한 서비스 요청은 시스템 콜이라고 부른다. (즉, 특권 명령의 대행을 요청하여 사용자 프로그램이 커널 영역의 기능을 수행하게 해준다.)

✔ 디스크에서 자료를 읽어오는 시스템 콜이라고 가정!

1. 사용자 프로그램이 시스템 콜을 하게 되면 운영체제는 자신의 커널 영역에 정의된 시스템 콜 처리 코드를 수행한다.
2. CPU가 컨트롤 레지스터를 세팅해 디스크 컨트롤러에게 데이터를 읽어오라고 명령한다.
3. 디스크 컨트롤러는 디스크로부터 데이터를 읽어와서 자신의 로컬 버퍼에 저장한다.
4. 작업이 완료되면 디스크 컨트롤러가 CPU에게 인터럽트를 발생시켜 입출력 작업이 완료되었음을 통지한다.

통상적으로 시스템 콜은 여러 종류의 기능으로 나뉘어져 있다. 각 시스템 콜에는 번호가 할당되고 시스템 콜 인터페이스는 이러한 번호에 따라 인덱스되는 테이블을 유지한다. 아래 그림은 open() 시스템 콜을 호출했을 때, 운영체제에서 어떻게 처리되는지를 보여준다.

필요한 기능이나 시스템 환경에 따라 시스템 콜이 발생할 때, 좀 더 많은 정보가 필요할 수도 있다. 그러한 정보가 담긴 매개변수를 운영체제에 전달하기 위해서는 대략 3가지 정도의 방법이 있다.

1. 매개변수를 CPU 레지스터 내에 전달한다. 이 경우에 매개변수의 갯수가 CPU 내의 레지스터 갯수보다 많을 수 있다.
2. 위와 같은 경우에 매개변수를 메모리에 저장하고 메모리의 주소가 레지스터에 전달된다. (아래 그림 참고)
3. 매개변수는 프로그램에 의해 스택으로 전달될 수도 있다.\

* 2,3번은 전달되는 매개변수의 갯수나 길이에 제한이 없기 때문에 몇몇 운영체제에서 선호하는 방식이다.

✔ 시스템 콜의 유형

5가지의 범주로 나눌 수 있다.

1. 프로세스 제어 : 프로세스 특권 모드를 사용해 직접적으로 프로세스 제어가 가능
2. 파일 조작 : 파일을 생성하거나 삭제, 관리 등
3. 장치 관리 : 장치 요구 및 장치 해제, 읽기, 쓰기, 재배치 등
4. 정보 유지 : 시간과 날짜의 설정과 획득, 시스템 자료의 설정과 획득
5. 통신 : 통신 연결의 생성 및 제거, 메시지의 송수신, 상태 정보 전달 등

Reference.

link1 link2 

주변장치와 입출력 장치는 CPU나 메모리와 달리 인터럽트라는 메커니즘을 통해 관리된다.

인터럽트를 하는 이유는???
그 이유는 입출력 연산이 CPU 명령 수행속도보다 현저히 느리기 때문이다.
CPU는 비싼데 오래걸리는 입출력 연산을 기다리며 CPU가 쉬게 만들 수 없어서
연산 결과가 나올 때 까지 다른 일을 하라고 시키는 것인데,
입출력이 완료되면 다시 CPU를 불러와 해당 작업을 이어가게 한다.

이때 CPU에게 완료되었음을 알려주는 것이 인터럽트이다.

- 하드웨어 장치가 CPU에게 어떤 사실을 알려주거나 CPU의 서비스를 요청해야 할 경우, CPU 내에 있는 인터럽트 라인을 세팅하여 인터럽트를 발생시킨다. (프로그램이 명령을 수행하기 위해서는 CPU를 할당받아야 함)

- CPU는 매번 프로그램 카운터가 가리고 있는 곳의 명령을 수행한 뒤, 다음 명령을 수행하기 직전에 인터럽트 라인이 세팅되었는지 체크한다.

- 이를 통해 인터럽트가 발생했으면 CPU는 현재 수행 중이던 프로세스를 멈추고 운영 체제의 인터럽트 처리 루틴으로 이동하여 인터럽트 처리를 수행한다.

인터럽트는 크게 하드웨어 인터럽트와 소프트웨어 인터럽트로 나뉘는 경우도 있다. 

하드웨어 인터럽트

• 일반적인 인터럽트
• 하드웨어 컨트롤러가 CPU의 서비스를 요청하기 위해 발생시키는 인터럽트

하드웨어 인터럽트가 발생하는 예

1. 기계검사 인터럽트

      - 프로그램을 실행하는 도중 갑작스런 정전이나 컴퓨터 자체 내에서 기계적인 문제가 발생한 경우

2. 외부 인터럽트

      - 오퍼레이터나 타이머에 의해 의도적으로 프로그램이 중단된 경우

3. 입출력 인터럽트 

      - 입출력의 종료나 입출력의 오류에 의해 CPU의 기능이 요청되는 경우

4. 프로그램검사 인터럽트 

      - 프로그램 실행 중 보호된 기억공간 내에 접근하거나 불법적인 명령 수행과 같은 프로그램의 문제가 발생한 경우

소프트웨어 인터럽트

• 소프트웨어 인터럽트는 외부가 아닌 CPU 내부에서 자신이 실행한 명령이나 CPU의 명령 실행에 관련된 모듈이 변화하는 경우 발생
• 프로그램 실행 중 프로그램 상의 처리 불가능한 오류나 이벤트를 알리기 위한 경우 발생하는데, 이를 트랩 또는 예외라 부른다.
• 또한 프로그램 내에서 특별한 서비스를 요구하거나
• 감시를 목적으로, 의도적으로 프로그램이 발생시킨 특별한 명령어에 의해 발생되기도 한다.

1. 예외 상황(Exception)

• 프로그램이 허용되지 않은 연산을 수행하려고 할 때, 자동적으로 발생한다. 운영체제는 예외 상황이 발생했을 때, CPU의 제어권을 획득해 이 상황에 대한 조치를 취한다.
• ex) 0으로 나누는 연산, 자신의 주소 공간을 넘어서는 메모리 참조 등
• 예외 상황에 대한 처리 루틴을 자신의 코드 영역에 가지고 있음

2. 시스템 콜(System Call)

• 사용자 프로세스가 운영체제의 서비스를 요청하기 위해 커널의 함수를 호출하는 것이다.
• 사용자 프로세스가 직접 특권 명령을 수행할 수 없으므로 특권 명령을 수행하려 할 때, 시스템 콜을 사용한다.

시스템 콜이나 예외 상황은 모두 사용자 프로세스로부터 CPU의 제어권이 운영 체제에게 이양되어 처리되는데 이 과정에 인터럽트 라인을 세팅하여 인터럽트를 발생시킨 후 제어권이 넘어가게 되므로 이들도 넓은 의미에서는 인터럽트의 범주에 포함시킨다. 
단지 발생시키는 주체가 하드웨어 장치가 아닌 소프트웨어이므로 이들을 소프트웨어 인터럽트라고 부른다.

인터럽트 발생 처리 과정

A 프로그램이 CPU를 할당받고 명령을 수행하고 있는데 인터럽트가 발생하면 A는 현재 수행중인 명령의 위치를 저장해놓는다. 그 후, 운영 체제 내부 코드인 인터럽트 처리 루틴으로 넘어가서 인터럽트 처리를 하고 다시 돌아와 A의 이전 작업 지점부터 수행을 계속 이어나가게 된다.

그렇다면, 인터럽트가 발생했을 때 수행중이던 프로세스의 정보는 어디에 저장될까?

-> 진행 중이던 A 프로세스의 정보는 프로세스 제어 블록(PCB: Process Control Block)에 저장한다. 그리고 인터럽트 처리를 모두 마치면 프로그램 A의 PCB에 저장된 주소를 복원시켜 원래 수행하던 일을 재개하게 된다.

인터럽트 벡터 

• 여러가지 인터럽트에 대해 해당 인터럽트 발생시 처리해야 할 루틴의 주소를 보관하고 있는 테이블.
• 일종의 함수를 가리키는 포인터

인터럽트 핸들러

• 실제 인터럽트를 처리하기 위한 루틴으로 인터럽트 서비스 루틴이라고도 한다.
• 운영체제 코드 부분에는 각종 인터럽트 별로 처리해야 할 내용이 이미 프로그램되어 있으며, 이 부분을 인터럽트 서비스 루틴 또는 인터럽트 핸들러라고 한다.

PCB

• 커널의 데이터 영역에 존재하며 각각의 프로세스마다 고유의 PCB가 있다.
• 인터럽트 발생 시 프로세스의 어느 부분이 수행중이었는지를 저장한다.
  (수행중이던 memory 주소, 레지스터값, 하드웨어 상태 ...)

Reference.

link1 link2 link3 

Process Address Space
프로그램이 실행되면 메모리에 할당되는 것

프로세스는 CPU에 의해서 실행이 되고 memory에 저장이 된다.

프로그램이 실행되면 프로세스 주소 공간이 memory에 할당(생성)되는데, 할당 된 프로세스를 실행시키는 것은 CPU가 한다.

구성요소

Address Space안은 위 그림과 같이 Code, Data, Stack 부분으로 이루어져 있다.

1) Code(Text)

• 우리가 작성한 소스코드가 들어 가는 부분. 즉, 실행할 프로그램의 코드가 저장되는 영역으로 텍스트(code)영역 이라고도 부른다.
• 코드영역은 실행 파일을 구성하는 명령어들이 올라가는 메모리 영역으로 함수, 제어문, 상수 등이 여기에 지정된다.
• 컴파일 타임에 결정되고 중간에 코드를 바꿀 수 없게 Read-Only 로 지정돼있다.

2) Data

• 프로그램의 **전역 변수와 정적(static) 변수가 저장되는 영역**이다.즉, 프로그램이 구동되는 동안 항상 접근 가능한 변수가 저장되는 영역이다.
• 전역변수, static 값을 참조한 코드는 컴파일 하고 나면 Data 영역의 주소값을 가르키도록 바뀐다.
• 데이터 영역은 프로그램의 시작과 함께 할당되며, 프로그램이 종료되면 소멸한다.
• 실행 중도에 전역변수가 변경 될 수도 있으니 이 영역은 Read-Write로 지정돼있다.

(상위 그림에서는 표현되어있지 않지만,) 초기화 된 데이터는 Data 영역에 저장되고,초기화 되지 않은 데이터는 BSS(Block Stated Symbol)영역에 저장된다.

Q.data영역과 bss 영역을 구분하는 이유는 무엇인가?
초기화되지 않은 변수는 프로그램이 실행될 때 영역만 잡아주면 되고 그 값을 프로그램에 저장하고 있을 필요는 없으나 초기화가 되는 변수는 그 값도 프로그램에 저장하고 있어야 하기 때문이다. 따라서 bss 영역 변수들이 많아져도 프로그램의 실행코드 사이즈를 늘리지 않는다.

3) Stack

• 함수의 호출과 관계되는 지역 변수와 매개변수가 저장되는 영역이다.
• Stack은 함수의 호출과 함께 할당되며, 함수의 호출이 완료되면 소멸한다.
• 원시타입의 데이터가 값과 함께 할당된다.
• Heap 영역에 생성된 Object 타입의 데이터 참조값이 할당된다.
• 메모리의 높은 주소에서 낮은 주소의 방향으로 할당된다.
• 컴파일 타임에 크기가 결정되기 때문에 무한히 할당 할 수 없다. 재귀함수가 너무 깊게 호출되거나 함수가 지역변수를 너무 많이 가지고 있어 stack 영역을 초과하면 stack overflow 에러가 발생한다.

Q. 왜 Code 부분을 따로 두었나?
Program의 Code는 Program이 만들어지고(컴파일되고) 나서는 바뀔 일이 전혀 없다. (따라서 Read Only)
그렇기 때문에 같은 프로그램을 실행시켜 몇 개의 Prcess가 실행되더라도 같은 프로그램이라면 Code 부분은 다 똑같은 내용을 가지고 있게 된다.
따라서 같은 Program의 Process일 경우 Code 부분을 공유(Share)하여 메모리 사용량을 줄이는 목적입니다.

Q. 왜 Stack 부분과 Data 부분을 나누었나? 
Stack 구조는 아래의 사진과 같이 이루어져 있다. (하단 부가 막혀있고 상단 부가 뚫려있는 구조)
따라서 한 쪽으로만 데이터를 집어 넣을 수 있고 꺼낼 때는 최근에 집어넣었던 것 부터 꺼낼 수 밖에 없는 구조 C언어를 예로 들면 함수의 호출이 stack 구조로 되어있다고 볼 수 있다.
전역변수는 어떤 함수에서도 접근할 수 있기 때문에 Data로 따로 관리해준다.

<stack 구조>

main 함수부터 실행되며 

처음 printf를 수행한 뒤 함수 func1 실행

함수 func1 실행 후 main 에서 다시 printf를 실행하고 함수 func2 실행

tunc2에서 printf를 수행하고 func3실행

이러한 stack 구조로 인해 data 부분과 stack 부분을 따로 나누어 둔 것이다.
전역 변수(global variables)는 어떤 함수에서도 접근 할 수 있기 때문에 Data로 따로 관리를 해주는 것

Reference.

link1 link2 link3

Program : 어떤 작업을 위해 실행할 수 있는 파일
Process : 운영체제로부터 자원을 할당받은 작업의 단위
Thread : 프로세스가 할당받은 자원을 이용하는 실행 흐름의 단위

프로그램이란 파일이 저장장치에 저장되어 있지만 메모리에는 올라가 있지 않은 정적인 상태

프로세스 Process

• 메모리에 올라와 실행되고 있는 프로그램의 인스턴스 ( 독립적인 개체 )
• 운영체제로부터 시스템 자원을 할당받는 작업의 단위
• 즉, 동적인 개념으로는 실행된 프로그램을 의미한다

• 프로세스는 각각 독립된 메모리 영역(Code, Data, Stack, Heap의 구조)을 할당받는다.
• 기본적으로 프로세스당 최소 1개의 스레드(메인 스레드)를 가지고 있다.
• 각 프로세스는 별도의 주소 공간에서 실행되며, 한 프로세스는 다른 프로세스의 변수나 자료구조에 접근할 수 없다.
• 한 프로세스가 다른 프로세스의 자원에 접근하려면 프로세스 간의 통신(IPC, inter-process communication)을 사용해야 한다. ( Ex. 파이프, 파일, 소켓 등을 이용한 통신 방법 이용 )

스레드 Thread

프로그램이 복잡해지고 프로세스 하나만을 사용해서 프로그램을 실행하기에는 벅차다. 
한 프로그램을 처리하기 위해 프로세스를 여러개 만드는 것은 안정성을 위해 자신에게 할당된 메모리 내의 정보만 접근하도록 유도하는 제약때문에 불가능하다.
따라서 프로세스보다 더 작은 실행 단위의 개념이 등장한다.

• 프로세스의 실행 단위
• 프로세스의 특정한 수행 경로
• 프로세스가 할당받은 자원을 이용하는 실행의 단위

• 스레드는 프로세스 내에서 각각 Stack만 따로 할당받고 Code, Data, Heap 영역은 공유한다.
• 스레드는 한 프로세스 내에서 동작되는 여러 실행의 흐름으로, 프로세스 내의 주소 공간이나 자원들(힙 공간 등)을 같은 프로세스 내에 스레드끼리 공유하면서 실행된다.
• 같은 프로세스 안에 있는 여러 스레드들은 같은 힙 공간을 공유한다. 반면에 프로세스는 다른 프로세스의 메모리에 직접 접근할 수 없다.
• 각각의 스레드는 별도의 레지스터와 스택을 갖고 있지만, 힙 메모리는 서로 읽고 쓸 수 있다.
• 한 스레드가 프로세스 자원을 변경하면, 다른 이웃 스레드(sibling thread)도 그 변경 결과를 즉시 볼 수 있다.
  
  

프로세스와 스레드의 작동방식 차이

프로세스가 메모리에 올라갈 때 운영체제로부터 시스템 자원을 할당받는다고 언급했었다. 이 때 운영체제는 프로세스마다 각각 독립된 메모리 영역을, Code/Data/Stack/Heap의 형식으로 할당해 준다. 각각 독립된 메모리 영역을 할당해 주기 때문에 프로세스는 다른 프로세스의 변수나 자료에 접근할 수 없다.

이와 다르게 스레드는 메모리를 서로 공유할 수 있다고 언급했었다. 이에 대해 더 자세히 설명하자면, 프로세스가 할당받은 메모리 영역 내에서 Stack 형식으로 할당된 메모리 영역은 따로 할당받고, 나머지 Code/Data/Heap 형식으로 할당된 메모리 영역을 공유한다. 따라서 각각의 스레드는 별도의 스택을 가지고 있지만 힙 메모리는 서로 읽고 쓸 수 있게 된다.

여기서 프로세스와 스레드의 중요한 차이를 하나 더 알 수 있게 된다. 만약 한 프로세스를 실행하다가 오류가 발생해서 프로세스가 강제로 종료된다면, 다른 프로세스에게 어떤 영향이 있을까? 공유하고 있는 파일을 손상시키는 경우가 아니라면 아무런 영향을 주지 않는다.

그런데 스레드의 경우는 다르다. 스레드는 Code/Data/Heap 메모리 영역의 내용을 공유하기 때문에 어떤 스레드 하나에서 오류가 발생한다면 같은 프로세스 내의 다른 스레드 모두가 강제로 종료된다.

왜 이런 방식으로 메모리를 공유할까?

스레드는 "흐름의 단위"라고 말했는데, 정확히는 CPU 입장에서의 최소 작업 단위가 된다. CPU는 작업을 처리할 때 스레드를 최소 단위로 삼고 작업을 한다. 반면 운영체제는 이렇게 작은 단위까지 직접 작업하지 않기 때문에 운영체제 관점에서는 프로세스가 최소 작업 단위가 된다.
여기서 중요한 점은 하나의 프로세스는 하나 이상의 스레드를 가진다는 점이다. 따라서 운영체제 관점에서는 프로세스가 최소 작업 단위인데, 이 때문에 같은 프로세스 소속의 스레드끼리 메모리를 공유하지 않을 수 없다.

Reference.

참고

참고2

CPU 스케줄링

메모리에 올라온 프로세스들 중 어떤 프로세스를 먼저 처리할지 순서를 정하는 것
Ready Queue에 있는 프로세스들 중에 누구에게 CPU를 할당해 줄 것인지 정하는 것

왜 필요한가?

CPU는 한 번에 하나의 프로세스만을 실행시킬 수 있다. --> 특정 프로세스가 I/O 요청으로 대기할 경우, CPU는 놀게됨

시간을 생산적으로 활용하고자 CPU를 그 프로세스로부터 회수해 다른 프로세스에 할당한다.

CPU 이용률 극대화

선점 및 비선점 스케줄링

CPU 스케줄러가 작동되는 4가지 상황

비선점 nonpreemptive

: 상황 1,4와 같이 프로세스가 자발적으로 CPU를 반납하는 경우

CPU가 한 프로세스에 할당되면 프로세스가 종료되든지, 또는 대기상태로 전환해 CPU를 방출할 때까지 점유한다.

선점 preemptive

: 상황 2,3과 같이 강제적으로 CPU를 빼앗기는 경우

Windows, macOS, Linux를 포함한 거의 모든 최신 운영체제들은 선점 스케줄링 알고리즘을 사용한다.

스케줄링 기준

CPU 이용률

전체 시스템 사용 시간 중 CPU가 작업을 처리하는 시간의 비율 

처리량

단위 시간당 완료된 프로셋의 개수

총 처리 시간

프로세스가 시작해서 끝날 때까지 걸리는 시간 ( 준비 큐에서 대기 시간 + CPU 실행 시간 + I/O 시간 )

대기 시간

프로세스가 준비 큐에서 대기하며 보낸 시간의 합

응답 시간

하나의 요구를 제출한 후 첫번째 응답이 나올 때까지의 시간 ( 응답이 출력되는 시간은 포함하지 않는다 )

CPU 이용률과 처리량을 최대화하고 총 처리 시간, 대기 시간, 응답 시간을 최소화 하는 것으로~!

스케줄링 알고리즘

선입 선처리 FCFS (First Come First Served)

특징

• 먼저 온 고객을 먼저 서비스해주는 방식, 즉 먼저 온 순서대로 처리.
• 비선점형(Non-Preemptive) 스케줄링
  일단 CPU 를 잡으면 CPU burst 가 완료될 때까지 CPU 를 반환하지 않는다. 할당되었던 CPU 가 반환될 때만 스케줄링이 이루어진다.

문제점

• convoy effect
  소요시간이 긴 프로세스가 먼저 도달하여 효율성을 낮추는 현상이 발생한다.

SJF(Shortest - Job - First)

특징

• 다른 프로세스가 먼저 도착했어도 CPU burst time 이 짧은 프로세스에게 선 할당
• 비선점형(Non-Preemptive) 스케줄링

문제점

• starvation
  효율성을 추구하는게 가장 중요하지만 특정 프로세스가 지나치게 차별받으면 안되는 것이다. 이 스케줄링은 극단적으로 CPU 사용이 짧은 job 을 선호한다. 그래서 사용 시간이 긴 프로세스는 거의 영원히 CPU 를 할당받을 수 없다.

SRTF(Shortest Remaining Time First)

특징

• 새로운 프로세스가 도착할 때마다 새로운 스케줄링이 이루어진다.
• 선점형 (Preemptive) 스케줄링
  현재 수행중인 프로세스의 남은 burst time 보다 더 짧은 CPU burst time 을 가지는 새로운 프로세스가 도착하면 CPU 를 뺏긴다.

문제점

• starvation
• 새로운 프로세스가 도달할 때마다 스케줄링을 다시하기 때문에 CPU burst time(CPU 사용시간)을 측정할 수가 없다.

Priority Scheduling

특징

• 우선순위가 가장 높은 프로세스에게 CPU 를 할당하는 스케줄링이다. 우선순위란 정수로 표현하게 되고 작은 숫자가 우선순위가 높다.
• 선점형 스케줄링(Preemptive) 방식
  더 높은 우선순위의 프로세스가 도착하면 실행중인 프로세스를 멈추고 CPU 를 선점한다.
• 비선점형 스케줄링(Non-Preemptive) 방식
  더 높은 우선순위의 프로세스가 도착하면 Ready Queue 의 Head 에 넣는다.

문제점

• starvation
• 무기한 봉쇄(Indefinite blocking)
  실행 준비는 되어있으나 CPU 를 사용못하는 프로세스를 CPU 가 무기한 대기하는 상태

해결책

• aging
  아무리 우선순위가 낮은 프로세스라도 오래 기다리면 우선순위를 높여주자.

Round Robin

특징

• 현대적인 CPU 스케줄링
• 각 프로세스는 동일한 크기의 할당 시간(time quantum)을 갖게 된다.
• 할당 시간이 지나면 프로세스는 선점당하고 ready queue 의 제일 뒤에 가서 다시 줄을 선다.
• RR은 CPU 사용시간이 랜덤한 프로세스들이 섞여있을 경우에 효율적
• RR이 가능한 이유는 프로세스의 context 를 save 할 수 있기 때문이다.

장점

• Response time이 빨라진다.
  n 개의 프로세스가 ready queue 에 있고 할당시간이 q(time quantum)인 경우 각 프로세스는 q 단위로 CPU 시간의 1/n 을 얻는다. 즉, 어떤 프로세스도 (n-1)q time unit 이상 기다리지 않는다.
• 프로세스가 기다리는 시간이 CPU 를 사용할 만큼 증가한다.
  공정한 스케줄링이라고 할 수 있다.

주의할 점

설정한 time quantum이 너무 커지면 FCFS와 같아진다. 또 너무 작아지면 스케줄링 알고리즘의 목적에는 이상적이지만 잦은 context switch 로 overhead 가 발생한다. 그렇기 때문에 적당한 time quantum을 설정하는 것이 중요하다.

< 참고 >

https://velog.io/@mu1616/CPU-%EC%8A%A4%EC%BC%80%EC%A4%84%EB%A7%81

스케줄러

Ready Queue에 존재하는 프로세스들을
특정한 우선순위를 기반으로 CPU를 할당받게 하는 역할로
장기, 중기, 단기 스케줄러가 있다.

프로세스를 스케줄링하기 위한 queue의 종류
1. Job Queue : 현재 시스템 내에 있는 모든 프로세스의 집합
2. Ready Queue : 현재 메모리 내에 있으면서 CPU를 할당 받기를 기다리는 프로세스의 집합
3. Device Queue : Device I/O 작업을 대기하고 있는 프로세스 집합

장기 스케줄러 Long - Term Scheduler

수행할 job이 10개, 메모리에는 6개 밖에 올릴 수 없는 상황
job 10개 중 6개를 골라서 올려야 하는데 이때 job을 고르는 역할을 하는 것이 장기 스케줄러
따라서 잡 스케줄러라고 불리기도 한다.

ready queue에 적재하는 메모리와 디스크 사이의 스케줄링을 담당하는 스케줄러인데,  I/O bound 중심의 프로세스들과 CPU bound 프로세스들의 적절한 비율을 조절해 올린다.

* I/O bound process : 입출력 많은 프로세스 (이 비율이 높으면 놀고 있는 cpu 많아짐)

CPU bound process : CPU가 계산을 해줘야 하는 비중이 큰 프로세스 (이 비율이 높으면 사용자와 상호적이지 못해서 실시간적인 의미 없어짐)

1. 어떤 프로세스를 Ready Queue에 삽입할지 결정

2. 메모리와 디스크 사이의 스케줄링을 담당

3. 프로세스에 메모리를 할당 

4. 메모리에 동시에 올라가 있는 프로세스의 수를 조절 

5. 프로세스의 상태[new -> ready(inmemory)]

단기 스케줄러 Short - Term Scheduler

장기 스케줄러를 통해서 job을 6개를 고른 상태
CPU에서 하나를 수행완료하고 나머지 job중 에서 하나를 골라야하는데 이걸 골라주는 스케줄러
따라서 CPU 스케줄러라고 불리기도 한다.

CPU가 낭비되지 않게 A라는 프로세스가 수행되다가 사용자의 입력을 받기 위해 cpu가 대기하는 상황이 되면 바로 B 프로세스로 교체해서 수행시킨다. 그러다 사용자의 I/O가 끝나면 다시 A프로세스를 cpu로 불러온다.

최소 100밀리 세컨즈마다 수행되어 단기 스케줄러라 불린다.

장기 스케줄러와 단기 스케줄러 -> CPU 스케줄러

요즘엔 virtual memory management가 발달해서 job이 10개면 메모리로 10개가 다 올라온다. 

즉, 장기 스케줄러의 의미가 없다는 것인데, long term이 없다면 short term의 의미가 무색해지기 때문에 주로 CPU 스케줄러라고 불린다. 

1. CPU와 메모리 사이의 스케줄링을 담당하며 CPU 스케줄러라고도함

2. Ready Queue에 존재하는 프로세스들 중 스케줄링 알고리즘에 따라 CPU를 할당할 프로세스 선택

3. 프로세스의 상태[ready -> running -> waiting -> ready]

중기 스케줄러 Medium - Term Scheduler

장기/단기 이후에 나왔다. 위에서 말했듯이 현재 개념은 가상 메모리개념이기 때문에 중기 스케줄러 또한 이용되지 않는다.

장기 스케줄러에 의해 10개 중 6개의 job을 올려서 수행중인 상태
CPU가 수행하려고 보니 감당하기엔 너무 많아 문제가 생겨 6개 중 2개를 내려보내면 상황이 해결될 것
6개 중 뭘 내려보낼지 결정하는 것이 중기 스케줄러의 역할 
Swapper라고도 불린다.

프로세스를 내릴 때 우선순위가 가장 낮은 프로세스나 일정 시간 동안 활성화되지 않았던 프로세스들을 내린다.

프로세스를 내리고 (swapping out) 다시 올려지는 (swapping in) swapping과정을 수행하기 때문에 swapper라고 불린다.

 1. 메모리에 적재된 프로세스의 수를 동적으로 조절

2. 메모리적재된 프로세스의 수가 많을 때 메모리를 통째로 디스크의 스왑 영역에 저장(Swap Out)

3. 프로세스의 상태[ready -> suspended]

<참고>

https://kmseop.tistory.com/119 https://jhnyang.tistory.com/372

Process Management 
프로세스가 여러 개 때, CPU가 CPU 스케줄링을 통해 관리하는 것
( 이때 CPU는 각 프로세스들이 누군지 알아야 관리가 가능하다. 이러한 프로세스들의 특징을 갖고 있는 것이 Process Metadata이다. )

[ Process Metadata ]

• Process ID : PID(Process Identification Number)라고도 한다. // 프로세스 고유 식별번호
• Process State : 프로세스의 현재 상태(준비, 실행, 대기)를 기억시킨다. //프로세스 상태
• Process Priority : 프로세스 우선순위 등과 같은 스케줄링 관련 정보를 기억시킨다. //스케줄링 정보
• CPU Registers : 프로세스의 레지스터 상태를 저장하는 공간으로 CPU 내 범용 레지스터, 데이터 레지스터, 세그먼트 레지스터 등이 갖고 있는 값을 기억시킨다.
• Owner : CPU 사용시간의 정보(Quantum)과 각종 스케줄러에 필요한 정보를 기억시킨다. //계정 정보
• 기억장치 관리 정보 : 프로그램이 적재될 기억 장치의 상한치, 하한치, 페이지 테이블 등의 정보를 기억시킨다.
• 입출력 정보 : 프로세스 수행 시 필요한 주변 장치, 파일들의 정보를 기억시킨다.
• 프로그램 카운터 : 다음에 실행되는 명령어의 주소를 기억시킨다. //계수기

이러한 정보들이 담긴 메타데이터는 프로세스가 생성되면 PCB라는 곳에 저장된다!

PCB (Process Controll Block)

프로세스 메타데이터들을 저장해 놓는 곳
하나의 PCB 안에는 하나의 프로세스의 정보가 담겨있다

프로그램 실행 -> 프로세스 생성 -> 프로세스 주소 공간에 (코드, 데이터, 스택) 생성 -> 이 프로세스의 메타데이터들이 PCB에 저장

PCB 상세 구조 ->

PCB가 필요한 이유 

CPU에서는 프로세스의 상태에 따라 교체 작업이 이루어진다.

이때 앞으로 다시 수행할 Block 상태의 프로세스의 상태값을 PCB에 저장해둔다. 

PCB의 관리 방식

Linked List 방식으로 관리된다. PCB list head에 PCB 생성될 때마다 붙게 된다. 연결이 이루어져있는 연결리스트 형태로 삽입, 삭제 용이

프로세스가 생성되면 해당 PCB가 생성되고 프로세스 완료시 제거가 된다.

이렇게 수행 중인 프로세스를 변경할 때, CPU의 레지스터 정보가 변경되는 것을 Context Switching이라고 한다.

Context Switching

CPU가 현재 실행하고 있는 task(process, thread)의 상태를 저장하고
다음 진행할 task의 상태 및 register 값들에 대한
정보(context)를 읽어 새로운 task의 context 정보로 교체하는 과정

* context란 : CPU가 다루는 Task(Process / Thread)에 대한 정보를 말하고, 대부분의 정보는 Register에 저장되고 pcb로 관리된다. 

인터럽트가 발생하거나, 실행 중인 CPU 사용 허가 시간을 모두 소모하거나, 

입출력을 위해 대기해야 하는 경우 Context Switching이 발생

프로세스가 Ready -> Running , Running -> Ready , Running -> Block 처럼 상태 변경 시에 발생

Context Switching 수행 과정

1. Task의 대부분 정보는 Register에 저장되고 PCB(Process Control Block)로 관리

2. 현재 실행하고 있는 Task의 PCB 정보를 저장 (Process Stack, Ready Queue)

3. 다음 실행할 Task의 PCB 정보를 읽어 Register에 적재하고 CPU가 이전에 진행했던 과정을 연속적으로 수행

Context Switching Cost

1. Cashe 초기화

2. Memory Mapping 초기화

3. 메모리의 접근을 위해서 항상 실행되어야 하는 kernel

위와 같은 Cost가 소요되기 때문에 잦은 context switching은 성능 저하를 가져온다.

* Process가 Thread보다 많이 든다. ( Thread는 stack영역을 제외한 모든 메모리를 공유하기 때문에 context switching 발생시 stack 영역만 변경하면 되기 때문)

Context Switching과 Interrupt

CPU는 하나의 프로세스 정보만을 기억한다.

여러 프로세스가 실행되는 다중 프로그래밍 환경에서는 CPU가 각각의 프로세스의 정보를 저장했다가 복귀하고 다시 저장했다가 복귀하는 일을 반복하는 것이다.

프로세스 중단과 실행시 interrupt가 발생하므로 context switching이 많이 발생한다는 것은 interrupt가 많이 발생한다는 것을 의미한다.

Context Switching과 시간 할당량

시간 할당량이 적어지면 :

문맥 교환 수, 인터럽트 횟수, 오버헤드가 증가하지만 여러 개의 프로세스가 동시에 수행되는 느낌을 갖는다.

시간 할당량이 커지면 :

문맥 교환 수, 인터럽트 횟수, 오버헤드가 감소하지만 여러 개의 프로세스가 동시에 수행되는 느낌을 갖지 못한다.

<참고>

https://m.blog.naver.com/adamdoha/222019884898 https://jhnyang.tistory.com/33