CPU Bound - I/O Bound

CPU Burst - I/O Burst

애플리케이션은 이용자에게 다양한 기능을 제공하지만
Process의 생애만 놓고 보면 CPU 실행과 I/O Wait 두가지 사이클을 가집니다.

• CPU burst는 단어의 느낌으로 알 수 있듯이 연산을 실행하는 작업이고
• I/O burst는 I/O 시스템으로부터 데이터가 전송이 끝나기를 기다리는 것입니다.

CPU burst와 함께 프로세스가 실행해서 CPU burst와 I/O Burst가 계속 번갈아 동작하다가 terminate 요청(이때도 CPU burst)과 함께 프로세스가 종료됩니다.

그리고 CPU burst duration은 컴퓨터 그리고 프로세스에 따라 다르지만 대체로 위와 같은 분포를 보인다고 합니다. CPU burst가 짧은 경우가 많고 긴 경우는 적습니다. 일반적인 I/O-bound 프로그램이 전자에 해당할 것입니다.

CPU Bound - I/O Bound

앞서 프로세스의 생애에 두가지 사이클이 있다고 했습니다.
CPU Bound 프로그램
CPU Burst한 실행을 하는 프로그램으로 생애동안 CPU 실행 시간이 I/O Wait하는 시간보다 많은 프로그램입니다.
많은 연산을 필요로하는 작업들 영상, 이미지 처리나 기계학습이 예입니다.
I/O Bound 프로그램
I/O Bound 프로그램은 그 반대가 되겠죠. DB, Network request/response가 많은 것, 보통의 백엔드 서버를 떠올릴 수 있습니다.

코어가 2개인 싱글 프로세서에서 cpu bound 작업할 때 적절한 스레드 수는 ? core수 + 1개 (일반적으로 CPU 독점을 막기 위해서 preemtive process/thread를 채택합니다. 이 점과 context switch overhead를 고려하면 스레드 수가 많은 것은 오히려 독이 된다는 것을 알 수 있습니다.)
그러면 i/o bound 작업에서는? 시스템 환경을 고려해서 적절한 수를 찾아가는 최적화 작업이 필요합니다!

CPU 1 cycle을 1초라고 했을 때 다른 작업들의 소요 시간을 환산한 것입니다. 보이는 바와 같이 I/O 작업은 CPU 연산 속도에 비교하면 수천 수만 이상의 시간이 소요됩니다.

일반적인 백엔드 서버는 Network I/O 뿐만 아니라 응답을 하기 위해서 DB read 등 I/O bound한 작업을 합니다. 만약 서버가 싱글 프로세서 싱글 스레드 환경에서 동작한다면, request를 응답하는 동안 cpu는 idle 상태로 아무 것도 하지 않고 놀 것입니다. CPU 효율성을 떠나 요청을 처리하는 동안 다른 요청을 받을 수도 없어 제대로 된 서비스가 불가능할 것입니다.

이전 포스팅까지의 내용은 이런 문제를 해결하기 위한 배경 지식에 해당합니다.
멀티 프로세싱/멀티 스레딩 그리고 비동기처리를 잘 쓰면 이런 문제를 잘 대응할 수 있습니다.