실습과 그림으로 배우는 리눅스 구조 4장 정리

프로세스 스케줄러

• 여러 개의 프로세스를 동시에 동작하도록 스케줄링 한다.
  • 하나의 논리 CPU에서는 실제로는 동시에 동작하지 않으며, 동작하는 것처럼 보이게 한다.  
• 동작 방식
  • 하나의 논리 CPU는 동시에 하나의 프로세스만 처리할 수 있다.
  • 하나의 논리 CPU에 여러 개의 프로세스를 실행하는 경우, 각 프로세스를 적절한 타임 슬라이스로 나누어 처리한다. 
• 각 프로세스들의 우선순위가 같다고 했을 때, 3개의 프로세스가 논리 CPU 1개를 사용한다면 각 프로세스는 같은 양의 시간 만큼 CPU에서 사용된다.  

 

 

컨텍스트 스위칭(context switching)

• 논리 CPU 상에서 동작하는 프로세스가 바뀌는 것
•  하나의 논리 CPU 위에서 프로세스 foo가 실행된 후, 프로세스 bar가 실행된다면 프로세스가 전환되는 타임슬라이스에 컨텍스트 스위칭이 일어난 것이다.  
•  하나의 논리 CPU 위에서 프로세스 foo가 실행된 후 프로세스 bar가 실행된다면, 프로세스가 전환되는 타임슬라이스에 컨텍스트 스위칭이 일어난 것이다.

 

 

프로세스의 상태

• 프로세스의 상태
  • 실행 상태: 현재 논리 CPU를 사용하고 있음
  • 실행 대기 상태: CPU 시간이 할당되기를 기다림
  • 슬립 상태: 이벤트 발생을 기다리고 있으며, 발생 전까지는 CPU를 사용하지 않음
    • 여기서 이벤트는 키보드 마우스 입력, 저장 장치에 읽고 쓰기의 종료, 네트워크 데이터 송수산 종료 등을 예로 들 수 있다. 
  • 좀비 상태: 프로세스가 종료한 후, 부모 프로세스가 종료 상태를 인식할때까지 기다리고 있음 

실습과 그림으로 배우는 리눅스 구조 p77

• 이외에도 다양한 상태가 있지만 이정도만 알아두자. 
• [ps] 커맨드에서 STAT 확인하기
  • R: 실행 상태 혹은 대기 상태
  • S: 슬립 상태. 실행 상태로 되돌아 오는 것
  • D: 슬립 상태. 실행 상태로 되돌아 오는 것, 저장 장치의 접근 대기
  • Z: 좀비 상태

• 프로세스들이 대부분 슬립 상태를 나타내는 이유는 이벤트를 기다리는 중이기 때문이다. 
• bash가 슬립 상태인 이유는 사용자의 입력을 기다리고 있기 때문이다.
• D 상태에 있는 프로세스는 수 밀리초가 지나면 다른 상태로 변경된다. 
  • 장시간 변경되지 않는다면 스토리지의 I/O가 종료되지 않은 상태이거나 커널 내에 문제가 있음을 의미한다. 

 

 

idle 상태

• 프로세스가 논리 CPU에서 동작하지 않는 상태(슬립 상태)일 때 idle 프로세스를 실행시킨다.
  
  • idle 프로세스는 비어 있는 프로세스라고 생각하자. 
• idle 프로세스는 CPU의 특수한 명령을 이용하여 논리 CPU를 휴식 상태로 만들어 하나 이상의 프로세스가 실행 가능한 상태가 될 때까지 소비 전력을 낮춰 대기 상태로 만든다.
• 노트북이나 스마트폰으로 아무것도 하지 않는 상태일 때 배터리가 오래가는 이유는 논리 CPU가 소비 전력이 낮은 idle 상태로 오래 있기 때문이다.
• 웹 브라우저나 텍스트 에디터는 사용자와 상호작용하는 프로세스 이므로 사용자의 입력을 기다리는 동안 슬립상태를 유지한다. 
• [sar] 커맨드를 통해서 논리 CPU의 idle 상태를 확인할 수 있다. 

 

 

프로세스 상태 변환 예시 

• 프로세스가 다음 처리를 하는 경우 어떻게 실행되는지 확인해보자
  • 사용자로부터 입력을 받는다.
  • 입력 받은 내용을 통해서 파일을 읽는다.
• 프로세스 상태 변화
  • 실행 -> [실행 상태] -> 사용자 입력 대기 -> [슬립 상태] -> 사용자가 입력 -> [실행 상태] -> 입력된 내용으로 파일 읽기  -> [슬립 상태] -> 파일 읽기 완료 -> [실행 상태] -> 종료   
• 논리 CPU 상태 변화
  • 실행 -> [프로세스 할당] -> 사용자 입력 대기 -> [idle 상태] -> 사용자가 입력 -> [프로세스 할당] -> 입력된 내용으로 파일 읽기  -> [idle 상태] -> 파일 읽기 완료 -> [프로세스 할당] -> 종료   

 

 

스루풋(Throughput)과 레이턴시(latency)

• 논리 CPU 및 저장 장치 등에서 사용하는 성능 지표로 여기서는 논리 CPU 기준으로 설명한다.  
• 스루풋
  • 단위 시간당 처리된 일의 양
  • 높을수록 좋다.
  • 완료된 프로세스 수/ 경과 시간
  • idle 상태 시간이 적어질수록 스루풋이 높아진다. 
  • idle 상태 시간이 긴 경우, 여러 프로세스를 실행시켜 스루풋을 높일 수 있다.
  • 하지만 idle 상태 시간이 0인 경우, 프로세스 수를 높여도 스루풋에는 변화가 없다. 
    • 좀 더 정확하게 말하면, 컨텍스트 스위치의 오버헤드로 인해서 스루풋이 감소한다. 
• 레이턴시
  • 처리가 시작부터 종료까지 경과된 시간
  • 짧을수록 좋다. 
  • 처리 종료 시간 - 처리 시작 시간
  • 프로세스 수를 늘리수록 레이턴시가 늘어난다(악화된다)
  • 각 프로세스의 평균 레이턴시는 비슷하다. 

 

 

논리 CPU가 여러 개일 때 스케줄링

• 로드밸런서를 통해서 여러 개의 논리 CPU에 프로세스를 공평하게 분배할 수 있다.
•  예시) CPU 0, 1과 프로세스 0, 1, 2, 3이 스케줄되어야 할 때
  • 논리 CPU0에 프로세스0, 1이 라운드 로빈 스케줄링됨
  • 논리 CPU1에 프로세스2, 3이 라운드 로빈 스케줄링됨

 

 

우선순위 변경

• nice() 시스템 콜을 사용하면 특정 프로세스에 우선순위를 부여할 수 있다. 
• 실행 우선 순위는 -19 ~ 20까지이며 0이 기본 값이다.
• -19가 가장 우선 순위가 높고, 20이 가장 낮다. 
• 우선 순위가 높을수록 평균보다 높은 시간 동안 CPU 시간을 배정 받는다. 
• [nice] 커맨드를 통해서 특정 프로그램의 우선 순위를 변경할 수 있다. 

 

 

Reference

실습과 그림으로 배우는 리눅스 구조