request : thread 를 1:1 로 매칭하면 좋겠지만, 메모리등의 자원은 한정적이니... 스래드 풀을 만들어서 들어 오는 요청을 처리하면 효율적인데 이때 요청 큐의 사이즈를 확인해서 적절한 제어를 해줘야 한다...너무 많이 큐에 대기하면 또한 메모리 부족으로 인해 시스템에 문제가 생길 수 도있음 스레드풀의 사이즈는 i/o bound(i/o의 특성에 따라 두배로 할지 그이상으로 할지를 결정), cpu bound(코어의 수 보다 약간 많은 정도)에 따라 스래드를 조정 왜 쓰는지를 알았으니 세부적인 구현등은 차차 채워 넣으면 되겠지요 오늘도 감사합니다.
강의 잘들었습니다~ 강의를 듣던중 또다시 궁금증이 생겨 질문합니다! 요청마다 스레드를 생성하는 경우에, 처리속도보다 더 빠르게 요청이 늘어나면 스레드가 계속 생성되고, 이로 인해서 컨텍스트 스위칭이 더 자주 발생한다고 하셨었는데요. 1. 컨텍스트 스위칭이 자주 일어날수록 오버헤드가 증가한다는 것은 자명한 사실이지만, 어떤 요인이 컨텍스트 스위칭을 자주 일으키는 것인가요? 제가 생각했을 때는 만약에 스레드의 종류를 크게 요청을 처리하는 코드를 수행하는 스레드(1)와 커널단에서 스레드를 생성하는 코드를 수행하는 커널 스레드(2)(os커널의 역할을 수행하는 스레드) 이렇게 2개로 분류하면, 요청을 처리하는 와중에 스레드를 생성하기 위해서 컨텍스트 스위칭이 일어나고, 스레드를 생성하고 다시 요청을 처리하는 스레드로의 컨텍스트 스위칭이 일어나는 이런 현상이 반복될 것 같은데, 이걸 주요 요인으로 볼 수 있을까요? 요청이 증가할때마다 스레드를 생성하는 경우에, 처리속도보다 더 빠르게 요청이 늘어나면 스레드가 계속 생성되어 스레드 수가 증가하게 되고, 결과적으로 메모리가 점점 고갈되어가는 상황이 생길 수 있다고 하셨는데요. 2. 스레드가 생성될 때, 어떤 부분이 있어서 메모리를 점유하게 되는 건지 궁금합니다.(가령 스레드를 관리하기위한 TCB같은 데이터가 있어야해서 그런건가요?)
넵 답변 드리게습니다~ 1. 오 맞습니다~! 말씀하신 부분도 분명 영향이 있을 것 같고요~ 제가 영상에서 더 자주 발생한다고 했을 때의 의도는, 우선 영상에서 말한 컨텍스트 스위칭의 의미는 OS 스레드들 사이에서의 컨텍스트 스위칭을 의미한 것이었고요, 극단적인 예를 들면, 코어 수가 네 개인 CPU에서 스레드 네 개를 돌린다면 (이 스레드들이 코어에 하나씩 할당되는 형국이기 때문에) 이 스레드들 사이에서 컨텍스트 스위칭이 일어날 가능성은 거의 없습니다. (스레드들이 I/O 작업을 한다해도 다른 스레드로 컨텍스트 스위칭될 가능성이 낮죠) 하지만 스레드가 늘어나면 늘어날수록 한 스레드에서 I/O 작업이 발생할 때, 혹은 락을 쥐기 위해 block될 때, 이외 여러 이유들로 block될 때, 다른 스레드로 컨텍스트 스위칭될 가능성이 점점 커지게 될 겁니다~ 그런 의미에서 더 자주 발생한다는 의미로 영상 찍을 당시에 설명을 했어요 (아랫 단락은 원래 처음엔 다르게 썼었는데, 계속 구글링 하면서 발견한 부분이 있어서 수정한 버전입니다) 그런데 아무리 생각해도 time slice 관련해서 좀 미심쩍은 부분이 있었어요. 스레드 수나 프로세스 수가 많아지면 응답성 향상을 위해 time slice를 OS가 더 짧게 조정해야 할 것 같았거든요~ 그전에는 레퍼런스를 찾지 못했어서 그냥 넘어갔는데, 이번에 세승님 댓글에 답변드리면서 다시 구글링을 계속 해보니 뭔가를 찾았고, time slice가 고정값이 아닌 것 같습니다. 만약 상황에 따라 time slice가 더 줄어든다면 그렇다면 스레드가 많아질수록 time slice가 짧아짐으로 인해서 context switching이 더 자주 발생할 수도 있기 때문에 이 부분은 제가 조금 더 확인하고 따로 댓글을 달아드릴게요~ 2. 스레드는 각 스레드 마다 고유의 스택 영역을 가지기 때문에 이 스택 영역 때문에 메모리를 차지하게 되는데요, OS마다 그리고 OS 버전마다 다르겠지만, 구글링을 해보니 1MB ~ 10MB 정도로 스레드 하나당 메모리를 차지한다고 합니다
@@ez. 아하! 단순히 os 스레드 간의 컨텍스트 스위칭을 말씀하시는거였군요. 확실히 스레드 수나 프로세스 수가 많아지면 time slice를 줄여서 응답성을 향상 시켜야할 것 같은데, 그에 따라서 context swithching이 늘어나서 오버에드가 증가하는 trade-off가 있겠네요. 이 부분은 댓글을 기다려 보겠습니다 ㅎㅎ 아, 그리고 추가적으로 os 스레드를 생성하는 작업은 이전 역할에서 설명하셨던 kernel thread가 하는 것이 맞나요?(os커널의 역할을 수행하는 스레드) 질문을 적을때는 당연히 맞겠지? 라는 생각으로 적었었는데, 다시 생각해보니 생성 매커니즘을 정확하게 모르는데 제가 추측한게 조금 위험해보여서요 ㅋㅋㅋㅋ! 친절한 답변 항상 감사드립니다.
@@세승-v4s 자료를 찾아봤구요, 리눅스에서는 CFS(completely fair scheduler)가 디폴트 스케줄러인데요, 이 스케줄러는 CPU time slice를 고정으로 쓰는 것이 아니라 프로세스나 스레드수에 따라 동적으로 time slice를 할당합니다 ! 다른 OS는 확인 안해봐서 모르겠지만, 보통 백엔드 서버는 리눅스를 많이 쓰기 때문에, 리눅스에서 스레드를 많이 만들게 되면 아무래도 스레드에 할당되는 CPU time slice가 조금씩 줄어들어서 컨텍스트 스위칭이 더 많이 일어나게 됩니다 :) (이건 제 개인적인 생각입니다) OS 스레드 생성하는 작업은 보통 시스템콜(주로 clone)로 진행되기 때문에 kernel thread가 따로 개입하진 않을 것 같아요~
오랜만에 다시 영상을 보다가 궁금한 점이 생겨서 댓글 달게 되었습니다. 쓰레드를 매 요청마다 생성하지 않고 쓰레드 풀을 이용하여 미리 쓰레드를 생성해놓고 가져다 쓰는 부분에는 확실한 성능상의 이점이 있다고 생각합니다. 그런데 궁금한 점이 생겼던 것은, 쓰레드를 매 요청마다 생성하던, 미리 쓰레드 풀에 생성해놓은 쓰레드를 가져다 쓰던, 쓰레드의 컨텍스트 스위칭 비용 자체는 동일한가? 입니다. 쓰레드 풀을 사용한다고해서 쓰레드가 컨텍스트 스위칭 되는데 드는 비용이 매 요청마다 쓰레드를 생성해서 사용할 때의 컨텍스트 스위칭 비용보다 적은 것은 아니지 않나요? 만약 요청이 100개 들어온다고 가정했을 때, 1. 매 요청마다 쓰레드를 생성하는 경우와, 2. 쓰레드 풀의 크기를 100개로 설정하여 사용하는 경우가 있다고 한다면, 순수하게 쓰레드를 새로 생성하고, 해제하는 비용을 제외한다면, 쓰레드 간의 컨텍스트 스위칭을 하는데 드는 비용은 1번과 2번이 동일한지 궁금합니다. 질문 읽어주셔서 감사합니다 :)
오랜만이에요~ 잘 지내셨죠? :) 질문에 답변드리자면, (모두 같은 프로세스 소속이라고 가정할 때) 하나의 스레드에서 다른 스레드로 컨텍스트 스위칭하는 비용 자체는 스레드풀을 쓰는지 여부와는 관계 없이 동일하다고 생각합니다 (스레드 수가 많아지면 스케줄링 비용이 조금 더 늘어날 가능성도 있는데 구체적인 것은 구현에 따라 다를 것 같습니다, 개인적으로는 거의 차이가 없고 동일할거라고 생각합니다) 하지만 전체적으로 누적된 비용을 계산해 보면, 스레드 수가 많아질수록 컨텍스트 스위칭은 더 자주 발생하기 때문에 그만큼 '단위 시간 당 CPU에서 컨텍스트 스위칭으로 사용된 비용'은 더 커질 것이라는 것을 예상할 수 있습니다 그런 측면에서 보면 1000개의 요청이 동시에 밀려올 때 100개의 스레드풀로 그 요청을 처리하면 100개의 스레드만으로 처리하게 되지만 따로 스레드풀을 쓰지 않고 요청마다 스레드를 만들게 되면 1000개의 스레드로 처리를 하게 돼서 100개의 스레드에 비해 1000개의 스레드로 처리할 때 컨텍스트 스위칭이 더 자주 발생하기 때문에 그만큼 '단위 시간 당 CPU에서 컨텍스트 스위칭으로 사용된 비용'이 더 커지게 됩니다
@@ez. 역시 항상 명쾌하고 친절한 답변 감사합니다 👍 예시로 들어주신 내용에 대해서 생각해보니, 1000개의 요청이 들어왔을때, 스레드를 매번 만드는 경우에는 요청당 1개씩 총 1000개의 스레드가 생성될 것이고, 그에 따라 1000개의 스레드가 정해진 time slice 씩 cpu를 사용하게 될텐데, 그때는 1000개의 스레드가 컨텍스트 스위칭 되는 동안 생기는 비용이 발생하겠네요. 반면에, 스레드풀을 이용해 스레드를 100개 만들어놓고 이를 사용하여 요청을 처리하는 경우에는, 100개의 스레드간 컨텍스트 스위칭되는 비용이 발생할 것 같습니다. 스레드풀을 사용하는 경우에 선택되지 못한 900개의 요청이 선택된 100개의 요청이 완료되기를 대기하는 비용보다 1000개의 스레드를 만들어서 모든 요청을 스레드에 할당함으로써 생기는 컨텍스트 스위칭 비용이 더 크기 때문에 스레드풀을 사용하는게 성능적으로 더 좋을 것 같다는 생각이 들었습니다. 제가 생각한게 맞을까요??
네, 맞습니다 어느 정도 스레드 수 제한을 두는 것이 오히려 더 안정적으로 사용할 수 있고, 스레드풀이 그 기능도 수행할 수 있기 때문이죠~ 그리고 참고로 (block 상태가 아닌) CPU에서 실행될 수 있는 스레드 수가 많아질수록 CPU time slice는 조금씩 더 줄어듭니다 (적어도 리눅스 상에서는 그렇게 동작해요) 그래서 평균적으로 보면 스레드 수가 많아질수록 CPU time slice도 더 작아질 가능성이 크고 그만큼 컨텍스트 스위칭도 더 자주 일어나고, 그래서 단위 시간 당 오버헤드도 더 많이 누적되고 그렇게 되는 거죠 CPU time slice와 관련된 내용은 티스토리 블로그에 정리를 한 게 있어서 링크를 남겨둘게요 :) easy-code-yo.tistory.com/43
이번 영상도 재밌게 잘봤습니다~ 한가지 질문이 있는데요. 스레드를 계속 생성해서 스레드가 증가하면 그만큼 컨텍스트 스위칭이 더 자주 발생해서 오버헤드가 발생한다고 하셨는데. 여기서 컨텍스트 스위칭을 더 자주 발생시키는 요인을 I/O 시스템콜이라고 이해하면 될까요? 그렇다면 I/O 시스템콜이 전혀 없는 cpu 연산만 실행하는 코드일때는 스레드수가 계속 증가해도 컨텍스트 스위칭의 빈도수는 그대로 인가요? (정해진 cpu 이용시간이 지나면 컨텍스트 스위칭 되는 빈도는 스레드 수가 증가해도 변함이 없으니)
열심히 공부하시는 모습 멋지십니다 :) 이번에도 중요한 질문을 해주셨어요~ 덕분에 저도 다시 한번 찾아보고 검색하면서 더 성장하게 됐어요 감사합니다~! >> "여기서 컨텍스트 스위칭을 더 자주 발생시키는 요인을 I/O 시스템콜이라고 이해하면 될까요?" 일반적으로 컨텍스트 스위칭을 발생시키는 요인은 I/O 작업일 수도 있고, 그 스레드가 CPU에서 실행 중에 주어진 time slice를 다 썼을 때 일 수도 있고(multitasking), critical section에 들어가기 위해 lock을 기다려야 하는 상황일 수도 있고, OS의 다양한 스케줄링 정책에 따라 발생할 수도 있고 (가령 우선순위가 높은 스레드를 먼저 실행 시켜준다던지), 여러 상황이 존재합니다. >> "그렇다면 I/O 시스템콜이 전혀 없는 cpu 연산만 실행하는 코드일때는 스레드수가 계속 증가해도 컨텍스트 스위칭의 빈도수는 그대로 인가요?" 질문주신 의도를 반영해서 질문을 살짝 수정/보충해보면, 아래와 같은 내용의 질문이지 않았을까 싶어요~ '만약 오직 CPU만 사용하는 코드일 때, 그리고 time slice를 제외하곤 컨텍스트 스위칭을 일으킬만한 그 어떤 요인도 없는 상황이며, 게다가 time slice의 크기가 언제나 항상 고정이라면 스레드 수가 증가해도 컨텍스트 스위칭의 빈도수는 그대로인가요?' 그리고 이에 대한 제 생각은, '네~ 그렇습니다' .... 사실 OS가 종류도 많고 각 종류마다 정책이 조금씩 달라서 간결하게 '딱 이렇습니다' 라고 말하기가 어려울 때가 있습니다 ㅠ 그래서 OS 관련 지식은 큰 틀 안에서 개념을 잡고, 그 안에서 필요하다면 그때그때 주로 쓰는 OS의 특징을 디테일하게 알아가는게 좋은 것 같아요~
안녕하세요~ 우선 일전에 제가 잘못된 정보를 드렸어서 죄송하다고 말씀드리고 싶고요, 제가 예전에 답변 단 부분에서 정정해야할 부분이 생겨서 댓글을 남기게 됐습니다 답변드릴 당시에는 저도 몰랐던 부분인데 이후에 새롭게 알게된 부분이에요 리눅스에서는 스레드 수가 많아질수록 time slice는 줄어들게 되고요, 그렇기 때문에 스레드 수가 많아질수록 context switching이 더 자주 발생하게 됩니다 자세한 내용은 쉬운코드 블로그에 정리했으니 참고 부탁드려요~ easy-code-yo.tistory.com/43
@@ez. 안녕하세요~ 오래전 댓글인데 또 한가지 질문이 생겨서 여쭤봐요. 만약에 웹 서비스처럼 굉장히 I/O bounded한 서비스라면 쓰레드수가 많아지더라도 이 쓰레드들은 모두 블로킹되어 웨이팅 큐에 들어갈텐데 그렇게 된다면 타임 슬라이스가 줄어들 필요가 없지 않을까요? 따라서 쓰레드수가 많더라도 컨텍스트 스위칭 빈도는 변함이 없을것이라고 생각합니다.
반갑습니다~ 우선 관심과 피드백 정말 감사드려요 :) 의견 주신 것에 저는 조금 달리 생각하는 부분이 있어요~ 저는 이 부분을 오히려 강조하는게 좋다고 생각합니다 무한대로 스레드가 생성이 되는 것을 막는 것은 스레드 수를 제한하면 매우 간단하게 해결되지만, 해결책이 간단하다고 스레드 수를 제한하지 않았을 때에 일어날 일 또한 간단한 것만은 아니라고 생각해요 현업에서 개발하면서, 스레드풀의 스레드 수에 제한을 두지 않거나 혹은 적절하지 않은 값으로 셋팅을 해서 트래픽이 순간적으로 몰렸을 때 서비스 장애로 이어지는 경우를 종종 봤었고, 이런 의미에서 스레드풀을 사용할 때 장점이나 중요한 특징 중 하나는 스레드 개수를 제한할 수 있다는 점이며, 잘 제한하는 것 또한 중요하기 때문에 저는 이 부분을 강조하고 싶었습니다~ 생각을 나눠주셔서 감사해요 :) 의견을 주고 받을 수 있어서 좋았습니다 👍
@@zackgreinke2382 아하 그러셨군요~ 핵심이 '스레드풀만의 특징이 아닌데 굳이 얘기할 필요가 있었는가' 였군요 부연 설명 감사합니다 :) 저는 개념을 설명할 때, 그 개념만의 유일한 특징이 아니더라도 중요하고 의미가 있는 특징이면 같이 설명하는게 좋겠더라구요 예를 들어 이진탐색트리의 단점을 해결한 것이 AVL트리인데, 사실 AVL트리 말고도 red-black 트리도 같은 단점을 해결하고, 그외에도 다양하죠. 그럼에도 중요한 특징이니까 AVL트리를 설명할 때 같이 얘기하고 있구요 끝으로 저도 다시 한번 관심과 피드백 감사드려요 😀 의견 교환은 제가 생각지 못한 부분에 대한 시각을 얻을 수 있는 중요한 통로여서 저에게 큰 도움이 됩니다 👍 그럼 오늘도 좋은 하루 되세요~!
@@zackgreinke2382 개인적으로 저는 설명하는 것이 좋다고 생각합니다 이게 왜 나왔는지에 대해 좀더 깊게 보고 싶은 사람들한테는 더없이 좋은 영상입니다 대부분 인터넷에 보면 쓰리핸드나 포핸드 관리포인트때문이라고만 나와있으니까요 님의 말이 틀리다는게 아니고 다르게 생각하는 사람도 있다는 걸 알아주셨으면해서 답글 달았어요
리눅스에서는 스레드 수가 많아질수록 컨텍스트 스위칭이 더 자주 일어납니다
자세한 내용은 아래 쉬운코드 블로그에 정리해 두었어요~ 👍
easy-code-yo.tistory.com/43
최근에 본 개발 관련 영상중에 정말 손에 꼽을정도로 좋네요 !!
크 ㅠㅠ 노력한 보람이 있는 것 같아서 많이 뿌듯합니다!! 뿌듯한 댓글 남겨 주셔서 감사합니다 :)
오늘도 출근길 최고의 선택.
예에~~~ 👍👍👍👍👍
매 영상 하나하나가 명쾌합니다. 딥한 부분을 이렇게 쉽게 설명하시다니 대단하십니다. 감사합니다
크 ㅠㅠ 좋게 봐주셔서 감사합니다 👍 계속해서 좋은 영상으로 인사드릴게요 :)
설명 참 잘 해주셔서 항상 잘 보고 있습니다.
크 좋게 봐주셔서 감사합니다 :)
꾸준히 좋은 영상으로 인사드릴게요~!
정말 잘보고 갑니담
항상 최고입니다.
정말 잘 보고있습니다!
늘 애청해 주셔서 감사합니다 :) 👍
이형 영상이 이해가 젤 쉬움
좋은 강의 감사합니다 !
와 이 집 잘하네.. 초보자인데 이해가 잘돼요 !!
분명 준비 열심히 하셨을 텐데 그만큼 결과물이 너무 좋네요
고생 많으셨습니다.
맛집 자주 들러주세요 :)
좋게 봐주셔서 감사합니다 😍
와 파이썬 공부하다가 스레드풀 개념에서 막혔는데 쉬운 설명 감사합니다!!! 항상 답답했던 개념들만 콕 찝어서 속시원하게 설명해주시네요😭 최고이십니다ㅎㅎ
우오오!! 댓글 감사합니다~!! 도움이 됐다니 저도 뿌듯하네요 :) 앞으로도 좋은 영상으로 찾아뵐게요~!ㅎㅎ
@@ez. 저도 파이썬 공부하다가 thread pool 개념에서 막혀서 구글링도 하고, 유튜브 검색했는데도 마땅한 자료가 안나왔다가, 여기서 풀렸습니다. 그냥 개념 부셨네요. 구독 갑니다.
@@김제하-q6w 크~~!! 도움됐다니 저도 너무 좋네요~! 앞으로도 부수는 영상으로 많이 찾아뵐게요~!! ㅎㅎ
9년차 개발자입니다. 잘보고 갑니다.
우와 감사합니다!! 실무에서 중요한 역할을 하고 계실 연차시네요 응원합니다!!
좋은 영상 감사합니다!!!
굿입니다
감사함다!!
와 설명 미쳤다...
헤헤 😉
request : thread 를 1:1 로 매칭하면 좋겠지만,
메모리등의 자원은 한정적이니... 스래드 풀을 만들어서 들어 오는 요청을 처리하면 효율적인데
이때 요청 큐의 사이즈를 확인해서 적절한 제어를 해줘야 한다...너무 많이 큐에 대기하면 또한 메모리 부족으로 인해 시스템에 문제가 생길 수 도있음
스레드풀의 사이즈는 i/o bound(i/o의 특성에 따라 두배로 할지 그이상으로 할지를 결정), cpu bound(코어의 수 보다 약간 많은 정도)에 따라 스래드를 조정
왜 쓰는지를 알았으니
세부적인 구현등은 차차 채워 넣으면 되겠지요
오늘도 감사합니다.
크 정리 요약 최고십니다!!
꾸준히 하시는 모습이 너무 귀감이 되고 저에게도 좋은 자극이 됩니다
갈가마구님 최고!! 👍
구독자 1만명되면 스타 뜨시져!!! ㅋㅋㅋㅋㅋ
오 좋죠 좋죠!!!ㅋㅋㅋㅋ 재밌겠네요!
엌 캐리어 ㅋㅋㅋㅋㅋㅋ 저도 영상 보면서 캐리어가 바로 떠올랐는데 뒤에 나오네요 ㅋㅋㅋ
옼ㅋㅋㅋ 저랑 똑같네요 ㅋㅋㅋ 제가 또 프로토스를 좋아하져 ㅋㅋㅋ
스레드풀을 여러개 만들엇다면 여러 요청이 올때 각 스레드풀에서 랜덤한 방식으로 스래드풀의 큐에 쌓이게 되나요??
쉬운 코드님, 톰캣에도 쓰레드 설정(maxThreads)이 있는데, 톰캣과 소스상에 모두 설정하면 어느 설정을 따르게 될까요?
강의 잘들었습니다~
강의를 듣던중 또다시 궁금증이 생겨 질문합니다!
요청마다 스레드를 생성하는 경우에, 처리속도보다 더 빠르게 요청이 늘어나면 스레드가 계속 생성되고, 이로 인해서 컨텍스트 스위칭이 더 자주 발생한다고 하셨었는데요.
1. 컨텍스트 스위칭이 자주 일어날수록 오버헤드가 증가한다는 것은 자명한 사실이지만, 어떤 요인이 컨텍스트 스위칭을 자주 일으키는 것인가요?
제가 생각했을 때는 만약에 스레드의 종류를 크게 요청을 처리하는 코드를 수행하는 스레드(1)와 커널단에서 스레드를 생성하는 코드를 수행하는 커널 스레드(2)(os커널의 역할을 수행하는 스레드) 이렇게 2개로 분류하면, 요청을 처리하는 와중에 스레드를 생성하기 위해서 컨텍스트 스위칭이 일어나고, 스레드를 생성하고 다시 요청을 처리하는 스레드로의 컨텍스트 스위칭이 일어나는 이런 현상이 반복될 것 같은데, 이걸 주요 요인으로 볼 수 있을까요?
요청이 증가할때마다 스레드를 생성하는 경우에, 처리속도보다 더 빠르게 요청이 늘어나면 스레드가 계속 생성되어 스레드 수가 증가하게 되고, 결과적으로 메모리가 점점 고갈되어가는 상황이 생길 수 있다고 하셨는데요.
2. 스레드가 생성될 때, 어떤 부분이 있어서 메모리를 점유하게 되는 건지 궁금합니다.(가령 스레드를 관리하기위한 TCB같은 데이터가 있어야해서 그런건가요?)
넵 답변 드리게습니다~
1. 오 맞습니다~! 말씀하신 부분도 분명 영향이 있을 것 같고요~
제가 영상에서 더 자주 발생한다고 했을 때의 의도는, 우선 영상에서 말한 컨텍스트 스위칭의 의미는 OS 스레드들 사이에서의 컨텍스트 스위칭을 의미한 것이었고요,
극단적인 예를 들면, 코어 수가 네 개인 CPU에서 스레드 네 개를 돌린다면 (이 스레드들이 코어에 하나씩 할당되는 형국이기 때문에) 이 스레드들 사이에서 컨텍스트 스위칭이 일어날 가능성은 거의 없습니다. (스레드들이 I/O 작업을 한다해도 다른 스레드로 컨텍스트 스위칭될 가능성이 낮죠)
하지만 스레드가 늘어나면 늘어날수록 한 스레드에서 I/O 작업이 발생할 때, 혹은 락을 쥐기 위해 block될 때, 이외 여러 이유들로 block될 때, 다른 스레드로 컨텍스트 스위칭될 가능성이 점점 커지게 될 겁니다~ 그런 의미에서 더 자주 발생한다는 의미로 영상 찍을 당시에 설명을 했어요
(아랫 단락은 원래 처음엔 다르게 썼었는데, 계속 구글링 하면서 발견한 부분이 있어서 수정한 버전입니다)
그런데 아무리 생각해도 time slice 관련해서 좀 미심쩍은 부분이 있었어요. 스레드 수나 프로세스 수가 많아지면 응답성 향상을 위해 time slice를 OS가 더 짧게 조정해야 할 것 같았거든요~ 그전에는 레퍼런스를 찾지 못했어서 그냥 넘어갔는데, 이번에 세승님 댓글에 답변드리면서 다시 구글링을 계속 해보니 뭔가를 찾았고, time slice가 고정값이 아닌 것 같습니다. 만약 상황에 따라 time slice가 더 줄어든다면 그렇다면 스레드가 많아질수록 time slice가 짧아짐으로 인해서 context switching이 더 자주 발생할 수도 있기 때문에 이 부분은 제가 조금 더 확인하고 따로 댓글을 달아드릴게요~
2. 스레드는 각 스레드 마다 고유의 스택 영역을 가지기 때문에 이 스택 영역 때문에 메모리를 차지하게 되는데요,
OS마다 그리고 OS 버전마다 다르겠지만, 구글링을 해보니 1MB ~ 10MB 정도로 스레드 하나당 메모리를 차지한다고 합니다
@@ez. 아하! 단순히 os 스레드 간의 컨텍스트 스위칭을 말씀하시는거였군요.
확실히 스레드 수나 프로세스 수가 많아지면 time slice를 줄여서 응답성을 향상 시켜야할 것 같은데, 그에 따라서 context swithching이 늘어나서 오버에드가 증가하는 trade-off가 있겠네요.
이 부분은 댓글을 기다려 보겠습니다 ㅎㅎ
아, 그리고 추가적으로 os 스레드를 생성하는 작업은 이전 역할에서 설명하셨던 kernel thread가 하는 것이 맞나요?(os커널의 역할을 수행하는 스레드) 질문을 적을때는 당연히 맞겠지? 라는 생각으로 적었었는데, 다시 생각해보니 생성 매커니즘을 정확하게 모르는데 제가 추측한게 조금 위험해보여서요 ㅋㅋㅋㅋ!
친절한 답변 항상 감사드립니다.
@@세승-v4s
자료를 찾아봤구요, 리눅스에서는 CFS(completely fair scheduler)가 디폴트 스케줄러인데요, 이 스케줄러는 CPU time slice를 고정으로 쓰는 것이 아니라 프로세스나 스레드수에 따라 동적으로 time slice를 할당합니다 !
다른 OS는 확인 안해봐서 모르겠지만, 보통 백엔드 서버는 리눅스를 많이 쓰기 때문에, 리눅스에서 스레드를 많이 만들게 되면 아무래도 스레드에 할당되는 CPU time slice가 조금씩 줄어들어서 컨텍스트 스위칭이 더 많이 일어나게 됩니다 :)
(이건 제 개인적인 생각입니다) OS 스레드 생성하는 작업은 보통 시스템콜(주로 clone)로 진행되기 때문에 kernel thread가 따로 개입하진 않을 것 같아요~
@@ez. 답변 감사드립니다 역시 최고에요!
@@세승-v4s 세승님도요! 👍
오랜만에 다시 영상을 보다가 궁금한 점이 생겨서 댓글 달게 되었습니다.
쓰레드를 매 요청마다 생성하지 않고 쓰레드 풀을 이용하여 미리 쓰레드를 생성해놓고 가져다 쓰는 부분에는 확실한 성능상의 이점이 있다고 생각합니다.
그런데 궁금한 점이 생겼던 것은, 쓰레드를 매 요청마다 생성하던, 미리 쓰레드 풀에 생성해놓은 쓰레드를 가져다 쓰던, 쓰레드의 컨텍스트 스위칭 비용 자체는 동일한가? 입니다.
쓰레드 풀을 사용한다고해서 쓰레드가 컨텍스트 스위칭 되는데 드는 비용이 매 요청마다 쓰레드를 생성해서 사용할 때의 컨텍스트 스위칭 비용보다 적은 것은 아니지 않나요?
만약 요청이 100개 들어온다고 가정했을 때,
1. 매 요청마다 쓰레드를 생성하는 경우와, 2. 쓰레드 풀의 크기를 100개로 설정하여 사용하는 경우가 있다고 한다면,
순수하게 쓰레드를 새로 생성하고, 해제하는 비용을 제외한다면, 쓰레드 간의 컨텍스트 스위칭을 하는데 드는 비용은 1번과 2번이 동일한지 궁금합니다.
질문 읽어주셔서 감사합니다 :)
오랜만이에요~ 잘 지내셨죠? :)
질문에 답변드리자면,
(모두 같은 프로세스 소속이라고 가정할 때) 하나의 스레드에서 다른 스레드로 컨텍스트 스위칭하는 비용 자체는 스레드풀을 쓰는지 여부와는 관계 없이 동일하다고 생각합니다 (스레드 수가 많아지면 스케줄링 비용이 조금 더 늘어날 가능성도 있는데 구체적인 것은 구현에 따라 다를 것 같습니다, 개인적으로는 거의 차이가 없고 동일할거라고 생각합니다)
하지만 전체적으로 누적된 비용을 계산해 보면,
스레드 수가 많아질수록 컨텍스트 스위칭은 더 자주 발생하기 때문에
그만큼 '단위 시간 당 CPU에서 컨텍스트 스위칭으로 사용된 비용'은 더 커질 것이라는 것을 예상할 수 있습니다
그런 측면에서 보면 1000개의 요청이 동시에 밀려올 때
100개의 스레드풀로 그 요청을 처리하면 100개의 스레드만으로 처리하게 되지만
따로 스레드풀을 쓰지 않고 요청마다 스레드를 만들게 되면 1000개의 스레드로 처리를 하게 돼서
100개의 스레드에 비해 1000개의 스레드로 처리할 때 컨텍스트 스위칭이 더 자주 발생하기 때문에
그만큼 '단위 시간 당 CPU에서 컨텍스트 스위칭으로 사용된 비용'이 더 커지게 됩니다
@@ez. 역시 항상 명쾌하고 친절한 답변 감사합니다 👍
예시로 들어주신 내용에 대해서 생각해보니,
1000개의 요청이 들어왔을때,
스레드를 매번 만드는 경우에는 요청당 1개씩 총 1000개의 스레드가 생성될 것이고, 그에 따라 1000개의 스레드가 정해진 time slice 씩 cpu를 사용하게 될텐데, 그때는 1000개의 스레드가 컨텍스트 스위칭 되는 동안 생기는 비용이 발생하겠네요.
반면에, 스레드풀을 이용해 스레드를 100개 만들어놓고 이를 사용하여 요청을 처리하는 경우에는, 100개의 스레드간 컨텍스트 스위칭되는 비용이 발생할 것 같습니다.
스레드풀을 사용하는 경우에 선택되지 못한 900개의 요청이 선택된 100개의 요청이 완료되기를 대기하는 비용보다 1000개의 스레드를 만들어서 모든 요청을 스레드에 할당함으로써 생기는 컨텍스트 스위칭 비용이 더 크기 때문에 스레드풀을 사용하는게 성능적으로 더 좋을 것 같다는 생각이 들었습니다. 제가 생각한게 맞을까요??
네, 맞습니다 어느 정도 스레드 수 제한을 두는 것이 오히려 더 안정적으로 사용할 수 있고, 스레드풀이 그 기능도 수행할 수 있기 때문이죠~
그리고 참고로 (block 상태가 아닌) CPU에서 실행될 수 있는 스레드 수가 많아질수록 CPU time slice는 조금씩 더 줄어듭니다 (적어도 리눅스 상에서는 그렇게 동작해요)
그래서 평균적으로 보면 스레드 수가 많아질수록 CPU time slice도 더 작아질 가능성이 크고 그만큼 컨텍스트 스위칭도 더 자주 일어나고, 그래서 단위 시간 당 오버헤드도 더 많이 누적되고 그렇게 되는 거죠
CPU time slice와 관련된 내용은 티스토리 블로그에 정리를 한 게 있어서 링크를 남겨둘게요 :)
easy-code-yo.tistory.com/43
이번 영상도 재밌게 잘봤습니다~
한가지 질문이 있는데요.
스레드를 계속 생성해서 스레드가 증가하면 그만큼 컨텍스트 스위칭이 더 자주 발생해서 오버헤드가 발생한다고 하셨는데. 여기서 컨텍스트 스위칭을 더 자주 발생시키는 요인을 I/O 시스템콜이라고 이해하면 될까요?
그렇다면 I/O 시스템콜이 전혀 없는 cpu 연산만 실행하는 코드일때는 스레드수가 계속 증가해도 컨텍스트 스위칭의 빈도수는 그대로 인가요? (정해진 cpu 이용시간이 지나면 컨텍스트 스위칭 되는 빈도는 스레드 수가 증가해도 변함이 없으니)
열심히 공부하시는 모습 멋지십니다 :) 이번에도 중요한 질문을 해주셨어요~ 덕분에 저도 다시 한번 찾아보고 검색하면서 더 성장하게 됐어요 감사합니다~!
>> "여기서 컨텍스트 스위칭을 더 자주 발생시키는 요인을 I/O 시스템콜이라고 이해하면 될까요?"
일반적으로 컨텍스트 스위칭을 발생시키는 요인은 I/O 작업일 수도 있고, 그 스레드가 CPU에서 실행 중에 주어진 time slice를 다 썼을 때 일 수도 있고(multitasking), critical section에 들어가기 위해 lock을 기다려야 하는 상황일 수도 있고, OS의 다양한 스케줄링 정책에 따라 발생할 수도 있고 (가령 우선순위가 높은 스레드를 먼저 실행 시켜준다던지), 여러 상황이 존재합니다.
>> "그렇다면 I/O 시스템콜이 전혀 없는 cpu 연산만 실행하는 코드일때는 스레드수가 계속 증가해도 컨텍스트 스위칭의 빈도수는 그대로 인가요?"
질문주신 의도를 반영해서 질문을 살짝 수정/보충해보면, 아래와 같은 내용의 질문이지 않았을까 싶어요~
'만약 오직 CPU만 사용하는 코드일 때, 그리고 time slice를 제외하곤 컨텍스트 스위칭을 일으킬만한 그 어떤 요인도 없는 상황이며, 게다가 time slice의 크기가 언제나 항상 고정이라면 스레드 수가 증가해도 컨텍스트 스위칭의 빈도수는 그대로인가요?'
그리고 이에 대한 제 생각은,
'네~ 그렇습니다'
....
사실 OS가 종류도 많고 각 종류마다 정책이 조금씩 달라서 간결하게 '딱 이렇습니다' 라고 말하기가 어려울 때가 있습니다 ㅠ
그래서 OS 관련 지식은 큰 틀 안에서 개념을 잡고, 그 안에서 필요하다면 그때그때 주로 쓰는 OS의 특징을 디테일하게 알아가는게 좋은 것 같아요~
안녕하세요~
우선 일전에 제가 잘못된 정보를 드렸어서 죄송하다고 말씀드리고 싶고요,
제가 예전에 답변 단 부분에서 정정해야할 부분이 생겨서 댓글을 남기게 됐습니다
답변드릴 당시에는 저도 몰랐던 부분인데 이후에 새롭게 알게된 부분이에요
리눅스에서는 스레드 수가 많아질수록 time slice는 줄어들게 되고요,
그렇기 때문에 스레드 수가 많아질수록 context switching이 더 자주 발생하게 됩니다
자세한 내용은 쉬운코드 블로그에 정리했으니 참고 부탁드려요~
easy-code-yo.tistory.com/43
@@ez.
안녕하세요~
오래전 댓글인데 또 한가지 질문이 생겨서 여쭤봐요.
만약에 웹 서비스처럼 굉장히 I/O bounded한 서비스라면 쓰레드수가 많아지더라도 이 쓰레드들은 모두 블로킹되어 웨이팅 큐에 들어갈텐데
그렇게 된다면 타임 슬라이스가 줄어들 필요가 없지 않을까요? 따라서 쓰레드수가 많더라도 컨텍스트 스위칭 빈도는 변함이 없을것이라고 생각합니다.
틀린 말은 아닌데 스레드풀 미사용으로 무한대로 스레드 생성이 되어 단점이란건 굳이 빼도 될듯해요 그것도 그냥 제한하면 그만이 내용이데..
반갑습니다~ 우선 관심과 피드백 정말 감사드려요 :)
의견 주신 것에 저는 조금 달리 생각하는 부분이 있어요~
저는 이 부분을 오히려 강조하는게 좋다고 생각합니다
무한대로 스레드가 생성이 되는 것을 막는 것은 스레드 수를 제한하면 매우 간단하게 해결되지만, 해결책이 간단하다고 스레드 수를 제한하지 않았을 때에 일어날 일 또한 간단한 것만은 아니라고 생각해요
현업에서 개발하면서, 스레드풀의 스레드 수에 제한을 두지 않거나 혹은 적절하지 않은 값으로 셋팅을 해서 트래픽이 순간적으로 몰렸을 때 서비스 장애로 이어지는 경우를 종종 봤었고,
이런 의미에서 스레드풀을 사용할 때 장점이나 중요한 특징 중 하나는 스레드 개수를 제한할 수 있다는 점이며, 잘 제한하는 것 또한 중요하기 때문에 저는 이 부분을 강조하고 싶었습니다~
생각을 나눠주셔서 감사해요 :)
의견을 주고 받을 수 있어서 좋았습니다 👍
@@ez. 아..그게 아니라 스레드풀 쓰지 않아도 똑같이 제한할수 있는 부분이라 스레드풀만의 특징인건가 하고말씀드렸어요
정성스러운 댓감사합니다
@@zackgreinke2382 아하 그러셨군요~
핵심이 '스레드풀만의 특징이 아닌데 굳이 얘기할 필요가 있었는가' 였군요 부연 설명 감사합니다 :)
저는 개념을 설명할 때, 그 개념만의 유일한 특징이 아니더라도 중요하고 의미가 있는 특징이면 같이 설명하는게 좋겠더라구요
예를 들어 이진탐색트리의 단점을 해결한 것이 AVL트리인데, 사실 AVL트리 말고도 red-black 트리도 같은 단점을 해결하고, 그외에도 다양하죠. 그럼에도 중요한 특징이니까 AVL트리를 설명할 때 같이 얘기하고 있구요
끝으로 저도 다시 한번 관심과 피드백 감사드려요 😀 의견 교환은 제가 생각지 못한 부분에 대한 시각을 얻을 수 있는 중요한 통로여서 저에게 큰 도움이 됩니다 👍
그럼 오늘도 좋은 하루 되세요~!
@@zackgreinke2382 개인적으로 저는 설명하는 것이 좋다고 생각합니다
이게 왜 나왔는지에 대해 좀더 깊게 보고 싶은 사람들한테는 더없이 좋은 영상입니다
대부분 인터넷에 보면 쓰리핸드나 포핸드 관리포인트때문이라고만 나와있으니까요
님의 말이 틀리다는게 아니고 다르게 생각하는 사람도 있다는 걸 알아주셨으면해서 답글 달았어요
@@nick6267 의견 남겨주셔서 감사합니다아 👍