아래 내용중에 유저하나당 프로세스하나가 가장 안정적이라고
쓰셨는데, 이 말을 클라이언트로 해석해도 될까요?
그렇다면 네트워크게임 같은 경우 접속과 해제가 빈번할텐데,
순간 프로세스생성이 CPU에 과부하를 주지 않을까요?
음.. 그리고 관련 책 좀 추천해 주세요.
PS. 내일은 RPC를 배우는데, 게임에 어떻게 적용일 될지...
스레드 대신 프로세스를 쓰면, 메모리나 핸들 등을 서로 건드릴 수 없기
때문에,
프로그램을 잘 만든다면, 메모리를 건드리는 등의 문제가 생겨도 그 프로세스를
죽이고 몇가지 정리를 하는 것으로 웬만한 방어 시스템이 갖춰질 수 있습니다.
또한, 여러 대의 컴퓨터에서 따로 돌릴 수 있게 만드는 것도 나중에 용이할
수
있습니다.
그런데, 제가 알기로는, 한 대의 x86계열 컴퓨터에서는 x86의 보호모드 특성상
4096 아니면 8192개까지의 프로세스만 만들 수 있다고 합니다. 스레드는 몇개까지
가능한지는 저도 모르겠습니다.
아시는 분은 답변을..
전통적인 유닉스 상의 서버 구성법은 클라이언트 하나당 서버 프로세스 하나입니다.
이 방법이 쓰레드에 비해 장점은 아래 배현직님이 말씀하신대로구요.
문제가 생기면 해당 프로세스에 영향을 미치게 되니까 전체적으로는 영향을
끼치지
않죠.
프로세스끼리의 통신은 IPC나 시그널 공유메모리등을 가지고 하면 쉽게 되고요.
프로세스 개수의 한계는 있습니다. 쓰레드도 한계가 있지요.
프로세스 수의 한계는 리눅스의 커널 소스를 보면 알 수 있는데 최대 프로세스의
개수를 헤더 화일에서 정해줄 수 있습니다. (task.h가? 정확히 기억이 안나네요.)
4096개고요. 커널 2.1에서 늘어난거고 커널 2.0에선 900여개였던것으로
기억이납니다.
하지만 한 시스템에 2000명 이상이 동시 접속한다면 서버를 분리해주는게
좋겠지요.
프로세스 갯수엔 문제가 없다고 판단했구요.
순간적인 프로세스의 생성은 유저가 초기 접속시 한번만 프로세스를 생성해주는건데
문제될 부분은 없습니다. (TCP사용)
물론 쓰레드도 씁니다. 유저가 아닌 몬스터들의 움직임등을 처리하기 위해서죠.
두가지 적절히 혼합된 구조로 설계를 했습니다.
안녕하세요? 레이옷입니다.
저희팀은 한때 솔라리스에서 놀다가 이제는 리눅스를 기웃거리기 시작하고
있습니다. 비록 지금은 펜티엄2에서 CPU 1개로 껄떡대고 있긴 합니다만,
나중에 몇천만원/몇억짜리 컴퓨터에 옮아갈 지도 모르고 거기에 몇 개의
CPU가 달려 있을 지 누가 알겠습니까? ^^*
그러니 CPU 1개에서는 쓰레드를 많이 만들면 컴이 버벅댐이 분명하지만,
나중에 CPU가 4개 8개 붙어나가면 그땐 정말 진정한 병렬처리가 이루어
질 것임이 분명하니깐.. 그때를 기약하는 의미에서, 쓰레드를 열라열라
만들어서 띄워놓고 있슴다.
흐흐.. 그 날이 올까요?
암튼 아직은 오지 않았으니, 지금은 Thread:ActiveObject = M:N (M<N) 으로
돌리고, 그날이 오면 1:1 로 조정할 생각이에용. 일단 이렇게 하면 유저가
100명이든 200명이든 가장 최적화된 비율만 찾아내면 그렇게 신경쓸 필요가
없을테니깐요... (성질나면 쓰레드를 1개만 만들어서 야! 니 다 처리해!
라고 하면 됩니다. -_-;)
그럼 모두들 수고하세요~~
안녕하세요? 이홍기입니다.
제가 사용하는 개발환경은, 리눅스 레드햇 5.2에 커널 2.2.3을 올려서
쓰고 있습니다. P-II 300에 128MB 메모리구요.
제가 테스트해본 바로, TCP echo서버를 fork하는 방식으로
One child process per client방식으로 하나의 클라이언트당
하나의 프로세스를 생성하게 해서, 800개정도 띄워서 클라이언트는
계속 무한루프를 돌면서 1byte를 실시간으로 주고받도록 했었습니다.
그랬는데, 서버부하가 거의 없었습니다.
리눅스의 최대 프로세스 개수를 4096으로 바꾸고 컴파일한 커널이었구요.
스티븐스의 네트웍 바이블인 NEtwork Programing 책(두번째판)을 보면서
여러가지 서버모델을 시험하고 살펴보고 있었는데, select도 고려를했었
습니다만.. select로 서버를 처리하게되면, collision(맞나요? ^^) 발생
할 가능성에 대한 언급이 있더군요.
죽일 가능성이 있기 때문에 접어두고 있습니다.
리눅스의 쓰레드를 사용하려고 시험중인데, 리눅스 쓰레드는..
쓰레드 하나당 프로세스 하나가 생성됩니다. 커널 버전 2.2.x에 포함된
쓰레드의 구현이 clone()시스템콜을 사용하는데, 그게.. 메모리는 공유하면서
child를 하나 fork하는 방식이었습니다.
음.. 쓰레드가 100개면 프로세스가 100개가 늘어난다는 얘기 같더군요.
어쨌든.. 전.. 리눅스에서 좀더 테스트해보고 있습니다.
멀티쓰레드형을 생각하려고 했는데,아무래도 한 쓰레드가 뻑나면 프로세스를
프로세스든 쓰레드든 한계가 많습니다.
PC급의 OS에서 한 피씨로 수백명을 처리하는 건 무리죠.
NT나 유닉스나 모두 마찬가지 입니다.
결국 분산구조로 가야 합니다.
그러기 위해선 결국 초반 설계를 잘해야 합니다.
하드웨어 사양을 올린다고 해도 OS적인 한계도 있고. 흑~
음..
흑 난 잘하구 있나?
하나의 서비스를 여러개의 컴에서 구현하기 위한 방법은 여러가지가 있지만
크게 세가지 방법이 있습니다.
1. NAT (Network Address Translation)
2. 분산 처리.
3. 패러럴 프로세싱(병렬처리)
1번은 IP하나를 여러개의 컴이 공유하는 것이죠.
같은 종류의 서비스를 여러대의 컴에서 같은 기능을 하는 똑같은 프로그램을
올려 주는 거죠. 그리고 로긴 서버에서 로드밸런싱을 해주면서 클라이언트를
로드가 안몰리는 서버에 접속 시켜 주는것이죠.
2번과 3번은 거의 비슷한 개념인데 2번은 모듈별로 나눠서 컴에 분산 시켜
주는거고
3번은 그야말로 병렬이죠. 모든 노드가 병렬 처리되는 컴 끼리는 똑같이 걸리는.
아주 이상적인 시스템이죠.
2번은 몇가지 구현되어 있는게 있지만.
일반적으로 멀티 서버의 구현은 NAT로 합니다.
2.3번의 경우 기술적으로 고난이도고 어렵기도 하고요.
암튼 중요한건 설계~정두재 (isoft )
앗 잡담이네여..
File descripter의 갯수도 제한이 되어 있습니다.
2000여개로 제한이 되어 있지요.
사실상 2000명 이상은 한 PC에서 처리를 못하는것이죠.
시스템이 아무리 빵방해도 말이죠.
(소켓하나 열때마다 File descripter로 매치가 되져.)
그래서 한시스템에서 처리하는 유저의 수를 1000명정도로
잡고 그에 해당하는 시스템을 구현해야 할 것 같습니다.
NT쪽은 이런 데이터 없나요?
음.. 정말 잡담에다가 다 알고 있는 사실일지 모르겠는데요.
사실.. 머그게임같은 서버에서는 주로 하는 일이 그리 많지 않다고
봅니다. 간단하게 생각나는데로 말씀드리면..
1. Recv (from Socket)
2. Protocol Parse.
3. Command Processing
3-1. 받은 데이타의 약간의 가공
3-2. 데이타 베이스 쿼리등의 작업.
3-3. 다른 사용자에게 전송.
3-4. 등등등... :)
4. return and waiting.
의 순서라고 생각이 드는데요.. 이정도의 프로세싱이라면 GDI에서
네모 그리고 색깔 칠하고 하는 프로세싱보다 적다고 생각이 드는데..
아.. 갑자기 왠 GDI에서 그림그리는 이야기를 하냐면...
Visual C++에서 네모, 원, 선등을 무작위로 그리는 프로그램을 쓰레드로
작동시키는 샘플 프로그램이 있는데... 2000개까지 쓰레드를 생성시켜
봤었습니다. 펜티엄 프로 200, 램 128메가에서요. 별 무리없이 작동을
하더군요.. 물론 느려지긴 했죠..
같이 일하는 사람중에 한 사람은 Unix에서 머드 게임 만들던 사람인데.
유닉스에서는 프로세스 단위로 생성시키는 것이 가장 탁월한(?) 선택인거
같더군요.. NT에서는 쓰레드 단위로 하는것이 좋을것 같습니다.
쓰레드가 미끈하게 생성되서 실행되더군요..
실은 스타체이스 서버를 만들때 멀티 프로세스로 만들었다가 몇주동안
고생한적이 있어서.. 지금은 쓰레드 단위로 작동시키고 있습니다.
그리고 하나의 쓰레드가 죽을때 전체가 죽는것을 대비해서 SEH를 쓰고
있습니다. (흐.. 그래도 다운되더군요...-.-;;) 암튼.. SEH를 써서
전체가 다운될뻔한건 많이 막아내었습니다. ^^;
어차피 서버에서의 멀티XXX 를 사용하는 이유는 병렬 수행으로
인한 속도 향상이 주목적이라고 생각합니다. 아래의 글들을 종합
해보면 둘은 거의 비슷한데, 멀티프로세스를 사용할 경우라면
안정성이 멀티쓰레드 버전에 비해 훨씬 낫다라는 결론이 되네요.
어쨌든 최소한 서버 전체가 죽지는 않을 테니까.. 시스템은
계속 서비스할 수 있다... 정도가 될까요?
근데 멀티프로세스는 필수적으로 IPC 를 사용해야 하지 않습니까?
멀티쓰레딩에 비해 IPC 를 사용할 경우 속도가 저하된다고 알고 있는데..
누구 자세한 벤치마킹을 해주시면 좋겠네요.
그리고, 쓰레드가 죽어서 프로세스가 확 죽어버리는 건 프로세스로
대체한다고 해서 될 문제가 아닌 것 같네요. 어차피 확 죽어 버리면
그 데이타는 날라갈테니깐요.. (구현에 따라 다를테지만 말입니다.)
즉 최대한 빨리 서버를 다시 띄워주면 될테니깐요..
안녕하세요
지금 윈98의 텔넷으로 글쓰느라 깨져보이니 오타가 있더라도 용서를
제가 머그를 제작중에 있는데 단일 프로세스 방식과
멀티프로세스 방식중 어느것이 더 효율적인지 알고싶습니다
>>다음 조건을 만족하면 멀티스레드가 더 효율적이라고 봅니다.
-비교적 많은 사용자가 물려있다.
-서버가 빵빵하다. (CPU여러개 물린 냉장고급 정도?)
-멀티서버등 확장을 할 가능성이 높다.
-동기화할 리소스 분할이 효율적으로 되어있다.
-게임 디자인이 체계적으로 잘 되어있다.
-멀티스레드 프로그래밍에 익숙하거나,고생문이 열려도 충분히 버텨낼 각오가
되어있다.(좀 조악한 표현이지만,저의 경험을 감안한다면.. -_-;)
-잦은 데이터베이스 처리 등으로 인해 각 사용자에 대한 처리 시간이 비교적
길고, 그것이 다른 사용자에게 영향을 끼치는 때가 많다.
물론........속도 보다는 제작하는데 편리한 쪽으로....^^;;
>>그렇다면,당연히 싱글스레드죠. 멀티스레드는 아무래도 복잡하답니다.
아참 그리고 데이타를 보낼때 꼭 암호화를 해야하는지
>>안해도 됩니다. 그래도 잘만 돌아갑니다.
그 방법 말고는 없는지 등등 많은것이 궁금합니다
그러고 보니....아직 시작도 못했군요
답변 부탁드립니다
감사합니다
>>천만에요. 하지만,소개팅이라도 시켜주신다면 감사히 받겠습니다.
:)
안녕하세요
우선 밑에분들 답변 감사드립니다
많은 도움이 되었구요
몇가지만 더 질문을 하겠습니다 ^^v
1.싱글 쓰레드일경우 멀티씨퓨하에서 어떠한 성능을 보이는지
>> x86과 NT의 경우, 한 개의 스레드는 1개의 CPU만 씁니다. 그러니까,
싱글
스레드 프로그램은 1개의 CPU만 쓰죠.
2.서버에서는 대체적으로 어떠한일을 하는지(자세히 ^^)
>> 게임마다 약간의 차이가 있지만,대체로 이렇습니다.
사용자 계정 관리
클라이언트로부터의 게임 진행 상황 수신
게임 진행 상황을 다른 클라이언트로 송신
게임 진행 상태 유지(NPC, 각 사용자 위치 등)
게임 환경 진행(NPC, 기후, 승패 상황 등)
3.또...한가지 있었는데 요건 기억나면 다시....^^;;
관련자료나 참고할만한 곳 이 있으면 주저마시고 알려주세용
어디 소스라도 있으면 좋으련만 T_T
감사합니다
>> 저도 별다른 소스는 찾은게 없습니다. 제가 본건,직접 그래픽머드같은게
아니라, 다이렉트플레이나 샘플 게임,텍스트 머드 정도입니다.
-_-;;..................
제가 원래 좀 시끄러운 녀석이라.....
또 질문 입니다
멀티쓰레드일 경우
1.사용자 1인당 1프로세스를 생성해야 합니까?
>> 제가 보기에는, 서버를 디자인하다보면, 아무래도 사용자 1인당 1스레드나
프로세스를 배분하는게 몇몇 처리에서 효율적일 수 있는데, 그런게 있을 경우에만
프로세스나 스레드를 배분하는게 좋다고 봅니다. 하지만, 1스레드에서 모든걸
처리해도 서버는 잘 돌아갈 수 있습니다. 웬만한 텍스트 머드가 그렇다는군요.
2.암호화를 해야한다면 어떤기법이 가장 좋은지?
>> 앞에서도 언급했지만, 안써도 잘 돌아가죠. 하지만, 암호화를
하는게 해킹
등으로 게임을 망치는걸 어느 정도는 막을 수 있죠. 암호화에 대해서는, 저도
후보를 고르고 있습니다.
3.데이터를 관리할때 오라클 같은 전문 프로그램을 쓰는지
아니면 자체적으로 제작해서 쓰는지.....
(케릭이 죽거나 몹이 죽거나 하면 변하는 데이터)
>> 안정성, 효율성 등에서 괜찮다고 생각된다면, 어떤 것이든 좋다고
봅니다.
저는 MS SQL server를 씁니다. 만약, PC에서 서버를 돌린다면, 그냥 간단한
것을
만들거나 Access같은것을 쓰셔도 된다고 봅니다. 배현직
한개의 캐릭터 마다 한개의 쓰레드를 쓰면 OS의 한계에 부딧히게 됩니다.
Linux같은경우 OS구조상 4000개정도의 쓰레드밖에 못쓰는데
그러면 한써버에서 처리할 수 있는 동시 유저수가 줄어들지요. NPC처리까지
맞게된다면 장난아니겠지요.
제가 구상한 서버에서는 구역단위로 쓰레드를만듭니다.
이건 지금 더 테스트를 해봐야 하는데 임의의 구역을 나누고
PC와 NPC를 각각 하나의 쓰레드로 만들어서 처리해 주는거죠..
(구역당 쓰레드는 2개가 되는거죠 PC용 NPC용)
그렇게 하면 쓰레드의 잇점도 살릴 수 있지요.
그리고 통신모듈쪽도 쓰레드로 구성하구요.
정확하게 말하자면 쓰레드 풀(Pool)이죠..
쓰레드 단위로 클라이언트를 처리하는 방법을 주로 쓰고 있는데요.
그다지 부하가 많이 먹지는 않습니다. 아래 고광현님께서 말씀하신
부분에 대한 저의 경험은 그렇다는 것입니다.. ^^;
헬브레이스의 1초당 처리되는 프로토콜의 양과 스타체이스에서
1초당 처리되는 프로토콜의 양중 어떤 것이 더 많을지는 모르겠지만
(개인적으로는 스타체이스가 더 많다고 생각합니다. 6^^;) 스타체이스에서
클라이언트가 300개 붙어서 돌아갈때 CPU점유율이 약 20% 안밖이었습니다.
그러니까 눈으로 계속 보고 있으면 15% ~ 22%정도로 왔다갔다 했었으니까요.
아.. 그리고 다른 이야기.. 쓰레드를 클라이언트마다 생성시키지 않고
현재 사용자 대 쓰레드 수의 비율을 설정해서 사용하는 방법도 괜찮은
방법이더군요. 사용자 5명당 스레드 하나.. 모 이런식으로 설정해서
서버를 제작해도 괜찮게 작동합니다. 위에서 예를 든 쓰레드 300개가
있다고 쳐도, 각 쓰레드당 CPU점유 시간보다는 Waiting하는 시간이 더
많으니까요.
오랜만에 게시판에 글을 올려보는군요.. ^^;
제가 만드는 서버에선 쓰레드 풀로 처리를 합니다.
즉 사용자의 요구가 계속 큐에 쌓이고 쓰레드 풀에서
큐의 내용을 쓰레드 풀이 허용하는 한 가져다가 처리하는 거죠.
그리고 처리가 끝나면 또 큐에서 긁어 오구..
그런 방식이죠. 풀에 디폴트로 있는 쓰레드의 수로 로드 밸런싱을 하고요.
준수님이 말씀하신 것과 비슷 한 방식이 되겠군요.
쓰레드를 쓰는 경우가 멀티 씨피유인경우 확실히 좋더군요.
일례로 싱글쓰레드에서 1000만번 루프도는거랑 쓰레드 3개에서 동시에 1000만번씩
도는거랑 속도가 거의 같더군요.
Thread 는 멀티 프로세서를 탑재한 (CPU 많이 단) 머신의 경우에만
그 진가를 발휘 할겁니다.
개인적인 소견으로는 싱글 프로세서의 컴퓨터에서는 오히려 single
thread 가 나을 것 같군요. 그리고 또 개인적인 소견이지만
사용자
하나하나마다 thread 생성은 아무래도 thread 의 장점을
십분 활용
하지는 못할 것으로 예상 되는군요.
물론 멀티 프로세서를 탑재한 머신에서 싱글 쓰레드를 고집하는
것
역시 바보같은 짓이라 할 수 있습니다만... -_-;
I/O Thread, Calculation Thread, AI Thread,
이런 식으로 나눠서 각각의 프로세서에 소수의 '큰일'을
분담시켜
주는 것이 효율적일 것이라는 지극히 개인적인 소견이었습니다.
무조건 Thread 만 쓰면 좋은건 아니겠지요.
아무래도 Thread 자체가 모든 책임을 Programmer 로 떠넘긴
듯한
느낌을 지우지 못하니까요. 그..그 엄청난 노가다.. -_-;
전 그
노가다를 해본 사람으로써 생각만하면 치가 떨리는군요.
혹자는 쓰레드가 프로그램을 더욱 구조적이게 만들어 준다고도
하지만,
늘어나는 흰머리와 쌓여가는 스트레스 그리고 향기로운
싱글 스레드만
기다리고 있을 뿐입니다. 노가다가 무슨 구조적인 프로그램이여. -_-;
-비엽
리눅스에선 쓰레드가 내부적으로는 프로세스로 구현됩니다.
(Pthread쪽 소스를 보면 fork를 사용 하죠)
따라서 만들 수 있는 프로세스의 갯수랑 같은데..
커널 컴파일 할 때 limit값을 조절하면 4096개까지 만들 수 있습니다.
1000개정도까지 만들어 봤는데..
하나의 유저당 쓰레드 하나씩 만드는건 효율적이지 못하죠..
인호님이 올리신데로 병목현상이 심한 부분을 찾아서 쓰레드로 처리하는것이
좋은 방법입니다.
리눅스나 유닉스쪽 서버를 분석해 봐도 쓰레드는 그런식으로 밖에 안쓰고요
사실은 쓰레드를 거의 안쓰더군요.
그럼..
소켓에서 쓰레드를 쓰신다면
Async 소켓을 쓰는건 아닐테고..
아마도 read에서의 블러킹을 쓰레드로 해결하실거라면..
소켓 하나당 쓰레드는 두개가 되어야합니다..
read 뿐 아니라 write 에서도 가끔 블러킹이 되기 때문이죠..
커널레벨의 내부 소켓 큐가 가득 차면.. 아마 블러킹 되는게 아닐까 하고
생각합니다만..
그리고.. 윈도에선 제가 해보니..
WIN98 에선 쓰레드가 1200개.. NT에선 2000개가 한계더군요.
으음.. 전 개인적으로 I/O 멀티플렉싱을 가장 선호한다는..
그래야 포팅도 쉽죠..