스케쥴링...

zoops의 이미지

이걸 질문에 올려야할지.. 토론에 올려야 할지.. 모르겠는데..
일딴 질문의 느낌이 강해 질문란에 올렸습니다만...
아무도 대답을 안해주셔서... 토론란으로 옮겼습니다.
위치가 맞지 않다고 생각하시면 얘기없이 옮기셔도 무관합니다.

일딴 문제의 발단은 이렇습니다.
각 특정 다른 일을 하는 모듈 3가지가 있습니다.
각각 쓰레드를 사용하는 일이 빈번해 각각 Thread Pool 을 가지고 있고..
해당 Thread Pool 안의 Thread 수는 설정할수 있습니다.

각각 모듈의 Thread Pool 의 Thread 수가 튜닝 포인트가 될수 있겠죠.
어느 모듈의 Thread 수를 몇개로 잡아야 할지... 상황에 따라서 셋팅하면 되니까요..

그런데 이렇게 생각한 큰 배경은..
kernel 이 Thread 스케줄링을 할때 되도록이면 공평하게 CPU 시간을 부여한다는 것이였습니다. (어느 플랫폼이든지.. 말입니다.- 아.. 선점형커널에 관한이야기입니다.)

그런데 다른이가 kernel 의 Thread 스케줄링을 믿지 못하겠다.
Thread Pool 을 하나로만 둬서 상황에 따라서 Pool 에서 각 모듈에 Thread 를 할당해야한다는 의견이 나왔습니다.

전 그것은 Thread Pool 을 하나로 가지 않고 각 모듈의 각 Thread Pool 의 Thread 수를 조절함으로써 해결하자는 의견이였고, 특히나 Thread Pool 을 하나로만 두면 Thread 를 하나의 모듈이나 두개의 모듈이 모든 Thread 를 다 차지하고 있어 모듈3 이 Thread 를 받지 못하는 경우가 생길수 있다는 의견이였습니다.

나 : Thread Pool 을 각 모듈별로 따로 가져가고
커널의 쓰레드 스케줄링을 믿으며..
튜닝포인트는 각 모듈의 Thread pool 의 Thread 수다.

다른이 : 커널의 쓰레드 스케줄링을 못 믿겠으며..
모든 모듈의 Thread 는 하나의 Thread Pool 에서 가져와야하며...
하나의 Thread Pool 의 Thread 수가 튜닝 포인트가 되겠지만..
Thread Pool 에서 각 모듈에 대한 Thread 스케줄링을 해야한다.

라는 의견입니다.

어떻게 생각하시는지요?
혹은 어떻게 사용하시는지요?

전 다른 Thread Pool 을 사용하더래도 커널이 쓰레드 스케쥴링을 하기 때문에 특정 모듈만 실행되는 일이 없으며, 특정 모듈의 작업량이 많다면 Thread 수로 튜닝을 해서 최대의 성능을 낼수 있다고 생각하는데..
어떻습니까?
의견을 듣고 싶군요..

bugiii의 이미지

쓰레드 풀을 나누느냐 합치느냐와 쓰레드들이 cpu 시간을 공평하게 나눠 가질 수 있느냐 마느냐는 조금 성질이 틀린 것 같습니다.

말씀하시는대로라면 쓰레드 풀의 쓰레드가 (미리 설정된 값) 모자라서 생기는 문제이지 cpu 시간을 가져오지 못하는 경우는 아니라고 생각합니다.

모든 쓰레드들이 우선순위 설정이 없다면 최대한 공평하게 cpu 자원을 나눠가질 것이라고 생각하고 구현자들도 그렇게 노력하는 것으로 알고 있습니다만...

조금 더 자세한 상황 설명이 필요합니다. 쓰레드 풀안의 쓰레드들이 어떤 식으로 대기하고 있는지도 궁금하고 지금 적절하다고 생각하는 쓰레드 수와 작업의 종류 (계산이 주인지 io가 주인지) 등이 필요합니다. 그리고 쓰레드 풀 혹은 쓰레드간의 잡이 서로에게 어떤 영향을 미치는지 혹은 종속관계가 있는지도 궁금합니다.

특히 어떻게 쓰레드의 대기상태를 풀어주는냐가 중요할 수도 있습니다. 풀 매니져가 이것을 인위적으로 강제하고 있는지, 아니면 잡을 대기열에 넣고 이것을 워커가 알아서 가져가게 한 것인지도 중요하겠습니다. 아마도 이런 구현의 차이점이 논쟁거리가 된 것 같습니다.

xfree의 이미지

모듈별로 쓰레드풀을 갖느냐와 하나의 글로벌 쓰레드풀을 갖느냐의 문제에서 어느것이 좋다라고 말하기는 곤란하다고 봅니다. 단순한 설계의 차이점이구요.

더 넣은 퍼포먼스를 위해 하나의 글로벌 쓰레드풀을 가지면서 쓰레드 스케쥴링에 직접 관여하겠다면... 말그대로 운영체제를 못믿겠다는 것인데... 어떤 종류의 어플리케이션이냐에 따라 더 좋은 성능을 낼 수도 있고 아닐 수도 있다고 봅니다. 스케쥴러를 구현하는 것은 그리 어려운 일이 아니지만 매우 공평한 스케쥴러를 구현하는것 그리 쉬운일이 아닙니다.

커널의 스케쥴러를 믿지 못하고 직접 구현하겠다면 타켓 플랫폼 운영체제의 스케쥴러에 대해 매우 자세한!!! 지식을 갖고 있어야 가능하며 저라면 커널을 믿겠습니다. 이유는........ 구현에 대한 생각만으로도 머리가 아파옵니다.......-0- 그러나 실시간성을 요구하는 등의 쓰레드의 동작에 정말 민감한!!! 어플리케이션이라면 스케쥴링에 직접 관여하는것도 나쁘지 않다고 생각합니다.

미들웨어 플랫폼을 설계하시는것 같은데요.. 스케쥴러를 직접 구현할 정도의 어플리케이션인가에 대한 고찰 후에 현명한 선택을 해야 될것 같습니다. 물론 쓰레드풀을 어떻게 가져갈 것인가는 단순한 설계의 문제라 봅니다.

zoops의 이미지

bugiii wrote:
쓰레드 풀을 나누느냐 합치느냐와 쓰레드들이 cpu 시간을 공평하게 나눠 가질 수 있느냐 마느냐는 조금 성질이 틀린 것 같습니다.

예.. 하지만.. 쓰레드 풀을 합치자는 이유가 쓰레드들이 CPU 시간을 공평하게 나눠 가지는 것을 보장 못하기 때문이라고 해서 이야기 한것입니다.

bugiii wrote:

말씀하시는대로라면 쓰레드 풀의 쓰레드가 (미리 설정된 값) 모자라서 생기는 문제이지 cpu 시간을 가져오지 못하는 경우는 아니라고 생각합니다.

예.. 하지만 각 모듈별로 나누면 최소한 각 모듈이 모든 쓰레드를 (혹은 CPU를 ) 점유하지 않고 돌아간다고 얘기해야하지 않겠습니까?

bugiii wrote:

모든 쓰레드들이 우선순위 설정이 없다면 최대한 공평하게 cpu 자원을 나눠가질 것이라고 생각하고 구현자들도 그렇게 노력하는 것으로 알고 있습니다만...
조금 더 자세한 상황 설명이 필요합니다. 쓰레드 풀안의 쓰레드들이 어떤 식으로 대기하고 있는지도 궁금하고 지금 적절하다고 생각하는 쓰레드 수와 작업의 종류 (계산이 주인지 io가 주인지) 등이 필요합니다. 그리고 쓰레드 풀 혹은 쓰레드간의 잡이 서로에게 어떤 영향을 미치는지 혹은 종속관계가 있는지도 궁금합니다.

특히 어떻게 쓰레드의 대기상태를 풀어주는냐가 중요할 수도 있습니다. 풀 매니져가 이것을 인위적으로 강제하고 있는지, 아니면 잡을 대기열에 넣고 이것을 워커가 알아서 가져가게 한 것인지도 중요하겠습니다. 아마도 이런 구현의 차이점이 논쟁거리가 된 것 같습니다.

쓰레드 수는 이야기 했듯이 튜닝포인트로 상황에 따라서 다르게 설정해서 최적의 성능이 되는 수를 설정할수 있도록 할수 있고...
작업의 종류는 계산과 IO 가 같이 있습니다만... 특별히 IO 만 혹은 특별히 계산만 있지도 않습니다.

마지막으로 지적해주신 부분에 대해서는 저도 논쟁거리가 될수 있다고 생각하는데..
일딴 그냥 쓰레드풀의 매니징은 빼놓고 얘기하면 안될까요?

결국엔 제 주장은
풀을 나눠사용해도
아무리 한 모듈의 job 들이 몰려도... 다른 모듈의 job 이 처리되지 못하고 있다거나.. 그런일이 없다..
라는겁니다.

- zoops -

zoops의 이미지

xfree wrote:
모듈별로 쓰레드풀을 갖느냐와 하나의 글로벌 쓰레드풀을 갖느냐의 문제에서 어느것이 좋다라고 말하기는 곤란하다고 봅니다. 단순한 설계의 차이점이구요.

더 넣은 퍼포먼스를 위해 하나의 글로벌 쓰레드풀을 가지면서 쓰레드 스케쥴링에 직접 관여하겠다면... 말그대로 운영체제를 못믿겠다는 것인데... 어떤 종류의 어플리케이션이냐에 따라 더 좋은 성능을 낼 수도 있고 아닐 수도 있다고 봅니다. 스케쥴러를 구현하는 것은 그리 어려운 일이 아니지만 매우 공평한 스케쥴러를 구현하는것 그리 쉬운일이 아닙니다.

커널의 스케쥴러를 믿지 못하고 직접 구현하겠다면 타켓 플랫폼 운영체제의 스케쥴러에 대해 매우 자세한!!! 지식을 갖고 있어야 가능하며 저라면 커널을 믿겠습니다. 이유는........ 구현에 대한 생각만으로도 머리가 아파옵니다.......-0- 그러나 실시간성을 요구하는 등의 쓰레드의 동작에 정말 민감한!!! 어플리케이션이라면 스케쥴링에 직접 관여하는것도 나쁘지 않다고 생각합니다.

그런가요?
제 생각엔.. 커널에서 스케쥴링을 하는데 어플단에서 또 한번 스케쥴링을 하는건데.. 두번하는것이 과연 좋은건가 모르겠습니다. 성능과 생산성 두가지 측변에서여..
스케쥴링을 어플단에서 하는것이 부하를 더 증가시킬것 같은데..

그리고 스케쥴링이
그렇다고 특별하게 동작중인 쓰레드를 중간에 대기시키는것도 아닙니다.
그저 job들의 갯수나 혹은 우선순위를 설정해 쓰레드를 할당하겠다는것 뿐인데.. 그렇다면 결국엔... 한 쓰레드는 job 을 다 처리할동안은 어플단에서 제공하는 스케줄링과는 독립적이게 됩니다.
이게 과연 필요한 것인지요??

xfree wrote:

미들웨어 플랫폼을 설계하시는것 같은데요.. 스케쥴러를 직접 구현할 정도의 어플리케이션인가에 대한 고찰 후에 현명한 선택을 해야 될것 같습니다. 물론 쓰레드풀을 어떻게 가져갈 것인가는 단순한 설계의 문제라 봅니다.

예.. 미들웨어 플랫폼을 설계하고 있습니다.
예.. 현명한 선택을 위해 의견을 더 듣고 싶습니다.

쓰레드풀을 어떻게 가져갈 것인가는 단순한 설계의 문제라 봅니다 라는것은 어떤 의미인지?? 전 무지 고민하고 있는건데..

- zoops -

지리즈의 이미지

Quote:
1. 각 모듈별 Thread들이 소모하는 CPU Time이 다르다.
2. 모듈별로 Thread들이 소모하는 CPU Time은 다르나, 각각의 모듈별로 처리하는 Task간의 Sync가 보장되어야 한다.
3. Mission Critical 하거나 Real Time 성이 어느 정도 보장되어야하는 부분이 있다.

위의 경우 모두 커널의 스케쥴러만으로는 해결안되는 면이 있습니다.

3번같은 부분이 있으면, 반드시 별도의 스케쥴러를 구성해야 합니다.
(RTOS 제외)
1,2번같은 부분이 있으면, 별도의 스케쥴러의 필요성을 염두에 들 필요는 있습니다.

하지만. "다른이" 분께서 말씀하신 것처럼 반드시 단일 쓰레드풀에서 모든 쓰레드의 스케쥴을 관리하는 것이 능사는 아닙니다.

큐와 같은 각 모듈간의 통신 매개체를 두어서 스케쥴을 조정할 수 있지요.. zoops님의 주장처럼 별도의 쓰레드풀을 사용하면서요...
제가 "다른이"와 같이 커널 스케쥴러를 못 믿는다면,
zoops님과 같은 주장을 할 것 같은데요...

커널 스케쥴러만을 전적으로 신뢰할 수 없는 상황이므로, 별도의 스케쥴러와
별도의 쓰레드 풀을 두어서 관리해야 한다. 라는 식으로요...

There is no spoon. Neo from the Matrix 1999.

zoops의 이미지

지리즈 wrote:
Quote:
1. 각 모듈별 Thread들이 소모하는 CPU Time이 다르다.
2. 모듈별로 Thread들이 소모하는 CPU Time은 다르나, 각각의 모듈별로 처리하는 Task간의 Sync가 보장되어야 한다.
3. Mission Critical 하거나 Real Time 성이 어느 정도 보장되어야하는 부분이 있다.

위의 경우 모두 커널의 스케쥴러만으로는 해결안되는 면이 있습니다.

3번같은 부분이 있으면, 반드시 별도의 스케쥴러를 구성해야 합니다.
(RTOS 제외)
1,2번같은 부분이 있으면, 별도의 스케쥴러의 필요성을 염두에 들 필요는 있습니다.

음.. 이유를 듣고 싶은데요..
일딴 RT 라는것이 App 에서 따로 스케쥴러를 구성하더래도 그것이 보장되나요?
제 생각엔.... 보장이 안될것 같은데...
App 단에서 또 스케쥴링을 한다는것은 부하를 또 주는것 아닙니까?

그리고 하나의 job 이 CPU 를 다 먹는다면..
단일 쓰레드풀을 사용하더래도 job 중간에 쓰레드를 멈추지 않으므로..
해결책이 아니라고 보는데요..
만약에 job 이 i/o 없는 프로세싱만 계속적으로 해야하는것이라면..
job 중간에 쓰레드를 멈추고 다른 쓰레드에게 제어를 넘기는 작업을 App 단에서 해야한다는것에 대해선 저도 동의를 합니다만..
다른이는 job 중간에 쓰레드를 멈추는 행위를 하기 위해 쓰레드풀을 하나로 가지고 가자고 주장하는 것은 아닙니다.

그리고 지금 job 은 i/o 와 프로세싱이 함께 있으며...
job 의 크기가 크지 않습니다. (유동적이긴 하지만요.. )
그리고 이건 제 생각인데.. job 에 i/o 없이 프로세싱만 오래되는 job 은 보편타당하게 처리하면 안될것 같은데요.. 특별히 처리해야지.. 예를 들어서.. 특정시간이후에 제어를 넘겨준다던지.... 아무리 선점형 커널이라도 프로그래밍에서 그렇게 고려를 해줘야 할것 같은데... 아닌가요??

지리즈 wrote:
Quote:

하지만. "다른이" 분께서 말씀하신 것처럼 반드시 단일 쓰레드풀에서 모든 쓰레드의 스케쥴을 관리하는 것이 능사는 아닙니다.

큐와 같은 각 모듈간의 통신 매개체를 두어서 스케쥴을 조정할 수 있지요.. zoops님의 주장처럼 별도의 쓰레드풀을 사용하면서요...
제가 "다른이"와 같이 커널 스케쥴러를 못 믿는다면,
zoops님과 같은 주장을 할 것 같은데요...

커널 스케쥴러만을 전적으로 신뢰할 수 없는 상황이므로, 별도의 스케쥴러와
별도의 쓰레드 풀을 두어서 관리해야 한다. 라는 식으로요...

제가 얘기하는것엔 각 모듈간에 큐를 가지고 있습니다. 작업큐를여...
그리고 따로 쓰레드풀을 가지고 있구요..
각 모듈간은 독립적이구요.. synch 를 맞출필요는 없습니다. (현재는.. )
전 각 모듈간의 처리차이를 각 모듈에 속한 쓰레드풀의 쓰레드 수로 조절해 최상의 성능을 내자라는 주장입니다.

- zoops -

junghwanz의 이미지

우선 어떤 스케줄링을 할것인지가 중요하겠네요...
1. Real-time scheduling을 원하신다면 다른님이 말씀하신것과 같이 app 단에 스케줄러를 만들어야 하구요.
2. 그렇지 않다면 굳이 스케줄러를 구현할 필요가 없습니다.

1. 이유 :
일반적으로 대부분의 Real-Time scheduling을 지원하지 않기때문이죠.
그렇지만 app단에서 real-time을 스케줄러의 구현은 정말 말리구 싶군요.
사실 app단에서 real-time 스케줄러를 구현해봤자. 진짜 real-time스케줄러라할수도 없습니다. 왜냐면 이미 커널에서는 우선순위를 다 잡아놓고 시작하기 때문이죠. 게다가 커널도 계속 time slicing을 할것이기때문에 최소 스케줄러는 다른 모든 다른 task들의 실행 주기보다 짧아야 하구요. 하기사 real-time을 어디까지 원하는가에 따라서 다를수도 있겠지만요. 아무튼 커널의 스케줄러도 생각을 하면서 app스케줄러를 구현해야 하기때문에 이게 무지 머리가 아파질것 같은데요. 지금부터 thread를 task라 표현하겠습니다. 아마도 이런식으로 구현은 그 누구도 하지 않을것 같네요.
그렇지만 굳이 구현을 해볼려고 한다면 우선 task를 관리하는 스케줄러의 수행 주기가 님이 만든 다른 task들을 우선해야 그나마 좀더 real-time 성질을 더 갖을수 있구요. 그다음에 우선순의를 상속도 구현을 해야 합니다. 이미 task들은 다 우선 순위를 정해놓고 스케줄을 해야겠죠. 우선은 깊게 생각을 안해서 이정도밖에 생각이 나질 않네요. 그리고 솔직히 이렇게 하면 아마도 퍼포먼스가 훨씬 떨어질것입니다. 그리좋은 스케줄러의 역할도 하지 못하면서요. 이경우에는 차라리 커널에 스케줄러를 바꾸어버리는 것이 날것 같네요.
아 이걸 짧게 써볼려고 하니까 잘 표현이 안되는데요.
암튼 한번 깊이 생각해보세요.

2. 이유:
이미 OS 자체가 선점형 muti-tasking OS라고 한다면요. 같은 우선순위를 같는app 간의 task들은 거의 정확히 cpu자원을 나누어 사용합니다.
O/S에 time_slice값이 있는데 이 값에 따라서 schedule을 한번씩하게되죠. 일반적으로 라운드로빈큐를 사용하게되면 그다음 대기중인 task가 돌게 되고요.
어쨋거나 스케줄러의 구현은 필요없습니다.
단 이런경우는 발생할수 있습니다.(이것또한 O/S에 따라 차이가 발생하겠지만요)
예를 들어 task가 A, B, C가 있습니다. 이중 A가 엄청난 IO 처리를 하는 task라고 가정을 하죠.
우선 A가 io buffer쪽에다 대고 엄청난 자료를 보냈다고 가정하면요.
kernel쪽에서는 이 데이타를 가지고 실제 출력을 내보내려고 할 것입니다.
interrupt가 팍팍 뜨기 시작하죠. A task는 자기가 한짓을 후회하면서 대기상태에 있겟죠. 이때는 커널 쪽에서 rescheduling time되겠죠. 즉 지정한 time_slice 시간이 왔다는거죠. 이때 task switching이 일어납니다. B task가 뜹니다. 그러나 이놈도 거의 지 할일 못하죠. interrupt때문에 다시 task switching이 되고 C task가 execution 되고요. 암튼 interrupt때문에 task들이 엄청 느려집니다.
실제로 O/S에서 엄청난 파일 카피등을 할때 느려지는것 같은 현상이 바로 이 이유죠.
근데 실제로 embedded가 아닌 상황에서 이런정도까지 되게 구현될만한 software가 있을지두 의문이네요.
그러니 거의 없는일이죠.
혹 제가 질문의 요지를 잘못 파악한건지도 몰라서 이게 답이 될란가 몰겠네요.

zoops의 이미지

jhlee1976 wrote:

2. 이유:
이미 OS 자체가 선점형 muti-tasking OS라고 한다면요. 같은 우선순위를 같는app 간의 task들은 거의 정확히 cpu자원을 나누어 사용합니다.
O/S에 time_slice값이 있는데 이 값에 따라서 schedule을 한번씩하게되죠. 일반적으로 라운드로빈큐를 사용하게되면 그다음 대기중인 task가 돌게 되고요.
어쨋거나 스케줄러의 구현은 필요없습니다.
단 이런경우는 발생할수 있습니다.(이것또한 O/S에 따라 차이가 발생하겠지만요)
예를 들어 task가 A, B, C가 있습니다. 이중 A가 엄청난 IO 처리를 하는 task라고 가정을 하죠.
우선 A가 io buffer쪽에다 대고 엄청난 자료를 보냈다고 가정하면요.
kernel쪽에서는 이 데이타를 가지고 실제 출력을 내보내려고 할 것입니다.
interrupt가 팍팍 뜨기 시작하죠. A task는 자기가 한짓을 후회하면서 대기상태에 있겟죠. 이때는 커널 쪽에서 rescheduling time되겠죠. 즉 지정한 time_slice 시간이 왔다는거죠. 이때 task switching이 일어납니다. B task가 뜹니다. 그러나 이놈도 거의 지 할일 못하죠. interrupt때문에 다시 task switching이 되고 C task가 execution 되고요. 암튼 interrupt때문에 task들이 엄청 느려집니다.
실제로 O/S에서 엄청난 파일 카피등을 할때 느려지는것 같은 현상이 바로 이 이유죠.
근데 실제로 embedded가 아닌 상황에서 이런정도까지 되게 구현될만한 software가 있을지두 의문이네요.
그러니 거의 없는일이죠.
혹 제가 질문의 요지를 잘못 파악한건지도 몰라서 이게 답이 될란가 몰겠네요.

그런데.. 많은 I/O 가 일어나면.. 컴퓨터 성능이 느려지는게 맞는건가요?
파일 카피의 경우는 하드 디스크를 사용하면서 페이징을 못하기 때문에 느려진다고 생각을 했었는데...

전 I/O 는 CPU Time 을 처음 명령 내릴때 한번만 사용한다고 생각했는데..
제가 잘못 생각한건가요?
명령만 내려지면 해당 Device 에 붙어있는 컨트롤러가 따로 처리하는거 아니였던가요?

그리고 real-time scheduling 을 app 단에서 지원하는것이 가능한건가요?
쓰신 글에서도 조금 부정적으로 쓰시긴 했지만...

- zoops -

zoops의 이미지

아아.. 추가적으로...
실제로 많은 I/O 가 일어나는 작업입니다.
네트웍 I/O 여..

정확히는 Message Queue 입니다.
Message Broker 라고 해서 더 쉬우실려나..

그럼.. 또 의견을 기다리겠습니다.

- zoops -

지리즈의 이미지

zoops wrote:

각 모듈간은 독립적이구요.. synch 를 맞출필요는 없습니다.

그런데.. 커널 스케쥴러를 신뢰할 수 없다면.. 그 OS는 사용하면 안됍니다.

혹시 게임회사에 근무하시나여?
게임회사라면 message queue server를 반드시 고려하게 되지요.

저정도 수준이면.. module별 thread인 모덻보다는 task 별 thread 모델정도로 해결될 것 같은데...

sourceforge에 가면... message server project가 있습니다.
혹은 여기도 방문해보세요. 자바기반이긴 하지만요..
http://www.mque.net/

There is no spoon. Neo from the Matrix 1999.

zoops의 이미지

지리즈 wrote:
zoops wrote:

각 모듈간은 독립적이구요.. synch 를 맞출필요는 없습니다.

그런데.. 커널 스케쥴러를 신뢰할 수 없다면.. 그 OS는 사용하면 안됍니다.

혹시 게임회사에 근무하시나여?
게임회사라면 message queue server를 반드시 고려하게 되지요.

저정도 수준이면.. module별 thread인 모덻보다는 task 별 thread 모델정도로 해결될 것 같은데...

sourceforge에 가면... message server project가 있습니다.
혹은 여기도 방문해보세요. 자바기반이긴 하지만요..
http://www.mque.net/

엇.. 지리즈님..
게임회사라면 Message Queue Server 를 반드시 고려하게 되지요..
에 대한 더 자세한 설명좀 부탁해도 될까요?

관심이 있어서여..
게임서버는 어떻게 처리하나에 대해서여..

전.. 음.. 게임서버랑 비슷끄리무리한걸 하거덩여..
역시나 자바기반입니다.
^^

- zoops -

musik의 이미지

저의 짧은 식견엔, 모듈에 특화된 쓰레드풀로 분할하는것이 낫지 않을까 합니다.

작업 특성에 따라 쓰레드 컨트롤을 잡고 실행되는 코드가 저마다 천차만별일텐데요...
예를 들어 IO 가 많은 작업군과 CPU 지향적인 작업군을 같은 쓰레드풀에 배치했을때, IO 에 소요되는 작업으로 인해(음.. 컨트롤을 잡고 블럭킹되는 경우를 생각해본다면....) CPU 지향적인 작업이 불필요하게 손해를 보는 등의 (풀내의 쓰레드를 얻을 기회를 놓치는 등...물론 아주 단편적인 예이지만) 불균형이 초래된다는 것을 짐작해 볼 수 있지 않을까요..

또한, 한번 메모리에 적재된 코드를 재사용하는 측면에서 보더라도 같은 쓰레드 컨트롤이 같은 코드를 실행하도록 하여 페이지폴트를 줄이는 효과를 얻는 등의 효과를 노릴수도 있을듯합니다.

개인적인 의견입니다만, 웬만한 어플리케이션의 구현 문제는 커널 특성이나 기타 OS의 특정 구현부에 얽매여선 안된다고 생각합니다.
감사합니다.

지리즈의 이미지

죄송합니다.
저도 게임회사에 근무하는 것은 아니고..
게임회사에 근무하는 친구들이 좀 있습니다.
그 놈들이 맞나면 늘 자사 게임섭의 장점에 대해서 서로 격돌을 펼치는데...
그때 귀동량을 좀 한 게 있어서...

대강 들은 예기로는
1.클라이언트가 섭에 접속하면... 그 클라이언트에 대한 프로세스가 하나 생성된다. 클라이언트는 오직 그 프로세스하고만 통신을 한다.
2. 각 유저(클라이언트)들간의 통신은 프로세스가 대행한다.(여기서 통신의 내용은 채팅을 포함...모든 액팅에 해당하는 메세지를 포함한다.)
3. 프로세스간 통신은 주로 IPC(메세제큐)로 해결한다.
4. 섭을 가지고 클러스터링을 구성할 경우, 각 섭하나를 작은 지역(불록)으로 정의하고... 사용자가 다른 불록으로 이동할때 서버와 서버의 통신이 발생하는데...
이때 메세지 큐잉 서버를 사용할 수 있다.

등이더군요...
모든 회사가 하나의 섭에서 모든 사용자를 감당할 수 없고...
그렇다고.. 섭마다 사용자를 제약하는 것도 한계가 있고 해서...
다들 클러스터링을 고려하고 있는데 반드시 화두되는 것이 메세지 큐잉 서버입니다. 물론 여러 다른 솔루션을 포함해서요...

그리고 로컬 메세지큐는 아무래도 속도의 한계가 있어서...
NT기반에서 쓰레드를 이용한 특화된 메세지큐나...
리눅스의 커널을 패치해서 사용한다고 들었습니다.

자바기반으로 개발하신다면..
www.mque.net에 들어가보면.. http://www.osmq.org 와 링크가
되어 있는데.. 여기서 자바소스를 배포하고 있습니다.
도음이 되시길 바라네요.

zoops wrote:
지리즈 wrote:
zoops wrote:

각 모듈간은 독립적이구요.. synch 를 맞출필요는 없습니다.

그런데.. 커널 스케쥴러를 신뢰할 수 없다면.. 그 OS는 사용하면 안됍니다.

혹시 게임회사에 근무하시나여?
게임회사라면 message queue server를 반드시 고려하게 되지요.

저정도 수준이면.. module별 thread인 모덻보다는 task 별 thread 모델정도로 해결될 것 같은데...

sourceforge에 가면... message server project가 있습니다.
혹은 여기도 방문해보세요. 자바기반이긴 하지만요..
http://www.mque.net/

엇.. 지리즈님..
게임회사라면 Message Queue Server 를 반드시 고려하게 되지요..
에 대한 더 자세한 설명좀 부탁해도 될까요?

관심이 있어서여..
게임서버는 어떻게 처리하나에 대해서여..

전.. 음.. 게임서버랑 비슷끄리무리한걸 하거덩여..
역시나 자바기반입니다.
^^

There is no spoon. Neo from the Matrix 1999.

ftfuture의 이미지

저의 짧은 식견과 윗분들으 의견을 참고해 보면
제가 보기에는 zoops님 설계안이 좋으리라고 봅니다.

정리를 해보면
1. 따로 스케쥴러를 만들기보다 OS자체의 스케쥴러를 믿는편이 낮다.
이유 : 따로 스케쥴러를 만들면 이중으로 스케쥴러가 동작하므로 부하가 가중된다. 또 따로 만드는 스케쥴러의 설계가 까다로와 성능이 의심된다.
2. 쓰레드풀을 따로 만들어 관리하는편이 낮다.
이유 : 여러종류의 쓰레드를 한 풀에서 관리하면
작업량이 많은 쓰레드로 인해(IO등) 다른 쓰레드에 영향을 줄수 있다, 또 제가 생각하기에 각 쓰레드의 작업에 따라 나누는것이 한 파트의 쓰레드가 문제가 생겼을때 다른 파트의 쓰레드가 영향을 받지 않으리라 생각됩니다.