Thread가 많다고 무조건 좋지는 않다
일반적으로 1개의 요청에 1개의 Thread를 사용하는 Spring 같은 Framework를 사용한다면 Thread를 최대한 많이 할당하고 싶은 충동을 느낄 수 있습니다. 하지만 Thread는 논리적 단위라는 걸 기억해야 합니다.
- 결국 Thread가 돌아가는건 Process 위에서
- 결국 Process가 돌아가는 CPU Core 위에서
Thread를 실제로 실행하는 주체를 고려하지 않고 무작정 Thread 개수를 늘리기만 하면 Context Switching으로 인한 Overhead만 증가합니다.
Core의 개수만큼 Thread?
CPU-Bound한 작업이 대부분이라고 가정할 때, CPU 개수 만큼의 Thread를 두는게 좋습니다. 결국 Thread를 실행하는건 CPU인데, CPU-Bound한 경우 idle 시간이 적기 때문에 CPU 개수보다 많은 Thread를 두면 Overhead만 증가합니다.
하지만 항상 적용할 수 있는 규칙은 아닙니다! CPU 자원을 많이 쓰지 않고 IO 등의 작업이 많으면 Thread 개수를 많이 두는게 더 유리합니다. (idle 시간이 많으니)
Core 개수 + 1이 국룰?
근데 혹시 Thread의 개수는 Core 개수 + 1이 국룰이라는 말 들어 보시지 않으셨나요? 아무리 CPU-Bound한 작업이 대부분이라고 해도 idle한 CPU Core가 없을 수는 없으니 조금의 Context-Switching을 감수하더라도 추가적으로 1개 정도의 Thread는 더 두는게 유리하더라~ 라는 경험적 법칙입니다.
왜 굳이 +1일까? 동시에 2개, 3개가 idle 일 수도 있는데?
1개의 추가 Thread를 두는건 결국 확률의 문제입니다. 물론 동시에 2개, 3개, 나아가 N개의 Thread가 idle일 수도 있습니다. 그 시간 동안에는 Core가 놀고 있겠죠. 하지만 CPU-Bound한 작업이 대부분인 시스템에서 여러 Thread가 동시에 idle인 확률이 얼마나 될까요? 굉장히 적겠죠?
그래서 너무 많은 Thread가 있으면 CPU의 Context-Switching 비용이 증가하니 추가적으로 1개의 Thread만 더 둬서 idle 시간을 줄인 겁니다.
하지만 이 또한 절대적인 규칙은 아닙니다. CPU 개수가 많으면 많을 수록 동시에 2개, 3개의 CPU가 idle일 확률도 올라가니 그에 따라 적절하게 조정하는게 좋습니다.
결국은 지표를 봐야한다
위에서 말한 여러 법칙은 절대적인게 아닙니다! 여러 요인에 따라 적정한 Thread 개수는 달라집니다.
- CPU-Bound한 작업의 비율이 얼마나 될까?
- CPU Core가 몇 개 일까?
- 실제 통계적으로 idle 한 경우가 얼마나 될까?
- OS나 Hardware 단에서 Thread나 CPU Core의 Multi-Pipeline을 어떻게 처리할까?
결국 처음에 법칙을 참고해서 Thread의 개수를 정하되, 지표를 보며 계속 변경해 최적의 Thread 개수를 찾아야 합니다. 여기서 끝이 아닙니다! Application은 항상 변화하기 때문에 변화하는 상황에 맞춰 지속적으로 모니터링하며 Thread 개수도 변경해야 합니다.
댓글