리눅스 스터디 #3 프로세스 스케줄러

프로세스 스케줄러

리눅스 커널에서 프로세스에 CPU 자원할당을 담당한다.

• 하나의 논리 CPU는 동시에 하나의 프로세스만 처리한다.
• 실행 가능한 여러 프로세스가 타임슬라이스 단위로 순서대로 CPU를 사용한다.

논리 CPU
process0 동작	process1 동작	process2 동작	process0 동작..

---

경과시간 사용시간

경과시간이란? 프로세스 시작 ~ 종료까지 경과된 시간.

사용시간이란? 프로세스가 실제로 논리 CPU를 사용한 시간.

time 명령어를 통해 프로세스 경과시간, 사용시간을 알 수 있다. 아래와 같이 사용

time ./doSomething.py
real 0m2.357s
user 0m2.357s
sys 0m0.000s

 

여기서 real -> 경과 시간, user + sys 는 사용시간이다. user는 사용자 공간에서 동작한 시간, sys는 시스템 콜 호출 때문에 늘어난 커널이 동작한 시간.

위의 예제는 system call을 호출하는 코드가 없어 거의 0에 가깝다.(프로세스 시작, 종료 등 일부 call 제외)

$ time sleep 3
real 0m3.009s
user 0m0.002s
sys 0m0.000s

 

해당 예제는 3초동안 기다렸으니 경과시간은 3초가 살짝 넘고, 아마 sleep 들어가기 전/후의 잠깐이 user로 잡혔을 것임을 예측할 수 있다.

---

논리 CPU를 1개만 사용하는 케이스

프로세스의 갯수를 여러개로 늘려 위와 같이 작업을 하게 한다면?

각 프로세스의 user+sys 실제 cpu 사용시간은 비슷하지만, 전체 실행시간인 real은 늘어난다.(순서대로 CPU 자원을 할당받아 동작할 것이기 때문)

---

논리 CPU를 여러개 사용하는 케이스

논리 CPU가 2개이고, 프로세스도 2개인 상황에서 각 CPU에 할당하여 작업을 하도록 하자.

그런 경우 모든 프로세스에서 real과 user+sys 값이 거의 같다.(기다림 없이 실제 동작, CPU 사용을 했다는 것을 알 수 있음)

---

real보다 user+sys가 커지는 경우?

1. 측정 정밀도가 정확하지 않기도 함.
2. 어떤 프로세스가 자식프로세스를 생성하고 각각 다른 논리 CPU에서 동작했다면? 프로세스 및 종료된 자식 프로세스 값까지 합쳐져 더 커질수도 있다.

---

Time slice(타임 슬라이스)

process가 사용할 수 있는 CPU 시간 단위.

kernel 프로세스 스케줄링을 가시화하면 아래처럼 생각할 수 있다.

	<-목표 레이턴시->				<-목표 레이턴시->
프로세스 2개	p0		p1		p0		p1
프로세스 3개	p0	p1(실제로는 3등분)		p2	p0	p1(실제로는 3등분)		p2
프로세스 4개	p0	p1	p2	p3	p0	p1	p2	p3

 

리눅스에서는 nice 값을 통해, 프로세스 실행 우선순위를 정할 수 있는데

범위는 -20 ~ 19이고, 기본값은 0이다. -20은 최우선순위이고, 19는 가장 낮은 우선순위가 된다.

nice 값을 변경하여 nice 값이 작아진 프로세스에게는 더 많은 타임 슬라이스가 부여된다. -> 일을 빨리 많이하게 될 수 있다.

---

컨텍스트 스위치

논리 CPU에서 동작하는 프로세스가 전환되는 것을 컨텍스트 스위치라고 한다.

시간 순서에 따라 아래처럼 process가 바뀌며 CPU에서 동작하게 된다.

process0 동작

process1 동작

process2 동작

process0 동작..

 

여기서 중요한 것은, 내가 짠 프로그램이 처음부터 끝까지 한번에 실행될 것이라고 생각하면 안된다는 것이다.

예를들어, 아래와 같은 프로그램을 작성했다고 가정하자.

아래의 foo(), bar() 함수 작업들 사이에  얼마든지 다른 프로세스가 바뀌어가며 동작할 것이라고 생각해야한다.(뿐만 아니라 코드 단위로도..)

def func():
    ...
    foo();
    bar();
    ...

---

처리 성능

턴어라운드 타임: 처리(반환) 시간, 시스템에 처리를 요청했을 때부터 처리가 끝날 때까지 걸린 시간

스루풋 throughput: 처리량, 단위 시간당 처리를 끝낸 개수

 

예를 들어, 웹사이트에 어떤 요청이 점점 늘어나는 경우

CPU 부하가 높은 상태일때, 들어오는 요청에 대한 처리가 점점 늦어질테니, 턴어라운드 타임도 점점 늘어날 것 이다.

응답 성능이 중요한 시스템이라면, 스루풋이 중요한 시스템에 비해서, 각 기기의 CPU 사용률을 적게 유지하는 것이 중요하다.

throughput은 프로세스의 갯수와 논리 CPU의 갯수가 같아질때까지는 향상 되다가, 그 후에 꺾이게 된다.

• 논리 CPU가 많이 내장된 경우라도 충분한 수의 프로세스가 실행되어야 스루풋이 향상된다.
• 무조건 프로세스 개수를 늘린다고 스루풋은 개선되지 않는다.