프로세스당 1024개의 descripter

하하의 이미지

클라이언트 끼리 상호 작용이 많은 MMORPG 게임 서버를

제작 고려 할때....

                           ( fd passing )
                |<--------- local machine ---------->|
    client ---- load balancer ---- gameserver_1 (1024)
         |                         gameserver_2 (1024)
         |________________________ gameserver_3 (1024)
                 ( connection )                     :

다음과 같이 client는 단순히 접속자 수를 기준으로한 load balancer에

따라 가장 부하가 적은 gameserver_X에 접속하게 됩니다.

1. 하나의 프로세스는 1024개의 디스크립터를 가질 수 있다.
= 만약 .. 모든 게임 서버가 full 일때 gameserver_1 만을 생각해 보면
1024명이 동시 다발로 데이터를 주고 받으면 기존 poll , select 방식
으론 성는 저하를 고려하지 않을 수 없을거 같습니다. 하지만
게임 서버를 충분히 많이 띄움으로서 한 서버당 400~500명 정도 동접
을 유지 하게끔 한다.
이때 문제점으론
- gameserver1에 속한 유저와 gameserver2에 속한 유저는 같이 게
임을 할 수 없습니다. 따라 서 gameserver1과 gameserver2에 속한
유저 정보를 가지고 있는 ...... 다시 말해 모든 게임서버의 접속된 사용
자 정보를 가지고 있는 manageserver를 통해 각 게임 서버에 구애
받지 않고 모든 유저가 게임을 할 수 있게끔 합니다.. 하지만...... 구현히 어렵고
유지 보수가 상당히 까다롭다.

위와 같이 고려를 한 이유는

두가지가 있을거 같습니다.

첫째. 프로세스는 1024개의 디스크립터만 사용할 수 있다.
둘째. 프로세스에 1000명이상이 동시 접속일 경우 poll, select
방식으론 빠른 성능을 보장 할 수 없다.

두번째 문제점은 epoll 등을 이용해 해결 할 수 있을거 같습니다.

epoll 밴치마켓 한 결과를 보더라도(사용해 보진 않았습니다)

http://www.monkey.org/~provos/libevent/

디스크립터 5000개 ~ 25000개 까지의 처리율(?)이 별반 차이가
없어 보입니다.
하지만 프로세스당 가질 수 있는 디스크립터가 1024이니 어짜피
managerserver 같은 역활을 하는 중계서버가 필요할 듯 합니다
그렇다면 epoll을 사용하므로써 얻는 장점은 단지 속도 개선 밖에
없을 듯 합니다.

다른 구성을 통해 managerserver 없이도 많은 유저가 동시에
개임을 할 수 있는 좋은 방법은 없을까요?
DB를 이용한다면 .. 가능 할거 같습니다만..
구현 방법엔 여러 가지가 있을거 같아.. 여러분을 의견을 듣고 싶습니다

하하의 이미지

답글이 없어서 ㅎㅎ

“바람에게도 길은 있다. 나는 비로소 나의 길을 가느니. 길은 언제나 어디에나 있다.”

김충길의 이미지

1024 한계는 커널 컴파일 다시하시고 ulimit 를 사용하여 해결 가능합니다.
(이쪽은 검색을 해보시기 바랍니다. 이미 올라왔는 주제들입니다.)

개발중인 게임이 존 개념이 있다면 존단 서버를 구분하는것도 한 대안일듯
쉽군요. 존별로 서버를 묶어 두는 거죠. 물론 서버에 여려개의 존 프로세스가
존재할 수도 있고요.

screen + vim + ctags 좋아요~

GENIUS의 이미지

정확하게 이해는 할수 없습니다만

저도 용도는 다르지만 서버 프로그램을 하고 있습니다.

그래서 방식으로

지금 사용하는 방식은 여러개의 같은 프로그램을 포트만 다르게 서버를 띄우는 것으로 생각됩니다.

먼저 데이터의 공유 방식을 메모리 쉐어 방식으로 서로 다른 프로그램이 공유할수 있도록 하는 방법이 있습니다. 데이터 베이스를 사용하는 방법보다 빠르고 간단합니다.

그리고 프로그램을 스레드 형식으로 짜는 방법입니다. 지금은 select와 poll을 이용한 fd 관리 방식인것 같습니다.
이방법은 무슨 이유에서인지 프로세스가 죽어서 좀비가 되는 경우가 있습니다. 이경우 재실행도 되지않고 ....

1024의 한계는 커널 컴파일로 해결가능합니다. 그리고 향후 나오는 버전에서는 65535개이상 지원하게 될것으로 생각됩니다.

리눅스 네트웍 개발 (FA) /유비쿼터스 네트웍 하드웨어 개발 프로젝트 진행/인터넷을 통한 원격제어/
리눅스 베이스 FA 구현/초소형 무선랜 모듈개발 진행중/리눅스 웹 통합시스템 구축

blackmir의 이미지

프로세스에 할당되는 리소스의 제한은 getrlimit 로 볼 수 있고, setrlimit 로 조정할 수 있습니다.

파일 디스크립터의 개수 제한 역시 마찬가지로 getrlimit 를 이용해 볼 수 있고, setrlimit를 이용해 조정할 수 있습니다. 단 조정할 때 super 유저의 권한이 필요한 경우도 있습니다.

프로세스당 할당되는 파일 디스크립터의 개수 제한을 풀기 위해 커널 컴파일을 다시해야 된다는 것은 아주 옛날 얘기가 아닐까 합니다만...

liongo의 이미지

흐흠 제가 재확인은 안했지만 1024 디스크립터 제한은

옛날이야기로 알고있습니다. 디폴트 ulimit 값이 1024라면 모를까..

ulimit 로 값을 조정할수있고요 차선으로 커널컴파일까지 갈수있습니다.

프비인경우에는 sysctl로 조정하시구요 현재 어느 OS인지 epoll을 언급하신

걸 보아서는 Linux계열인것같습니다. 커널 Ver이 하위버젼으로 정해진상황

같지는 않아보입니다. epoll사용하려면 또한 별도 수작업이 필요한일이니까요

서버 방식에 따라 마니 틀리겠습니다 좀더 구체적인 방식이 필요할것같습니다.

MMORPG라고 해도 존단위로 구성되는것인지 아니면 한존을 여러서버가나눠

서 처리하는방식인지요.. 조금 혼동의 여지가 있는것같습니다.. 한계를 미리

정하시는것같습니다만 All in One서버도 있습니다 리니지2가 한대에서 한월드

를 담당하는것으로 알고있구요(맞나? ㅋㅋ) 다른겜서버들은 존단위를 구성하는서버 한월드 를 여러 서버가 나눠서 하는경우도 있지요..

또 한서버라는것이 물리적 서버인경우를 포함한것인지도 불분명하군요..

물리적 서버 여러대 그안의 데몬이 1024씩 맡는다고하여도..

중간에서 데이타 처리를 해주는 서버가 못버텨줄수도있지요.. 단위가 너무

작게 쪼개지면 중간서버가 바쁘니까요..

제가생각하기엔 MMORPG 서버란게 예외상황이 상당히 많습니다.

제공되는 서비스에 맞게 구성을 잘하시는게 최선인것같습니다..

그러므로 적절한 서비스 예측구성및 테스트를 위한 클라이언트를 만드셔서

충분한 테스트를 하시는것이 좋을것같습니다..

p.s 잡설이 너무길었죠 ^^; 간만에 왔더니만 말이 많아졌는듯.

' 형식이 내용을 규정한다. '

하하의 이미지

음..

제가 제목을 1024의 디스크립터로 해놔서 약간

의도가 빗나간 듯 도 합니다.

1024를 이상 조정 할 수 있습니다.

딴에는....

만약 하나의 서버(프로세스)가 1024명의 동접 사용자를 처리한다

했을때 .. 1024명의 사용자가 아주 빈번한게 데이터를

전송한다면.. poll, select 는 그 성능이 저하되지 않

나 생각 되어 집니다.

해서 epoll을 사용..

(하나의 프로세스가 처리할 수 있는 디스크립터 10000으로 늘리고)

서버가 10000명의 데이터를 처리 할때의

문제는 없을지 .....

아님.. epoll을 사용하지만 여러 프로세스를 띄워 (1000명씩 분산)

하나의 공유 데이터 서버를 두어 각각의 프로세스에 물려있는 사용자간

게임을 할 수 있도록 .. 해야 할지....

이런 저런 생각에.. 제 생각도 정리 할겸.. 여러분의 의견도 들을겸..

모자란 글 솜씨로 올려봤습니다. ^^;

“바람에게도 길은 있다. 나는 비로소 나의 길을 가느니. 길은 언제나 어디에나 있다.”

김충길의 이미지

연결에 대한 멀티플렉싱을 얘기한게 아니라 데이타 통신에 대한 멀티플렉싱을 얘기한 거군요. 엉뚱한 대답을 드렸네요.

단순함을 위해 공유 데이타 메모리를 두고 멀티 스레드로 하는게 좋지 않을까요.

select, poll 같은 경우 감시 하는 fd가 많을 경우 효율이 나빠지지 않을까요?

screen + vim + ctags 좋아요~

liongo의 이미지

현재 내용으로보고 딱히 말한다면..

답은 없다? 가 아닐가싶습니다.. epoll부분이 영향을 끼치는부분은

전체 서비스의 빙산의 일각이 아닐까 싶구요 나머지는 분산처리에대한

구성이나 서비스에 최적화 튜닝의 문제일것같습니다.

p.s 한서버로도.. 10000명을 수용하는 서버를 구성하신다해도..

epoll의 성능이 좌우하는 부분은 데몬의 성능의 1% 미만이 아닐까요?

' 형식이 내용을 규정한다. '

하하의 이미지

Quote:

p.s 한서버로도.. 10000명을 수용하는 서버를 구성하신다해도..

epoll의 성능이 좌우하는 부분은 데몬의 성능의 1% 미만이 아닐까요?

전 조금 다른 생각을 가지고 있습니다.

epoll은 클라이언트와 서버간 연결된 다중 소켓에 대해

읽을것이 있는지 체크하는 핵심적인 부분이라 생각해서

요..

실제로 .. 데이터 처리에 대한 부분은 그리 큰.. 시간을

요하지는 않는거 같습니다. ( 이부분은 다소 틀릴수도 있겠습니다 ㅎ)

동접률 10000명까지 가서 모든 사용자가 계속 데이터

보낸다고 할때.. epoll. 및 read는 모든 사용자가 1번 데이터를

보낼때 10000번 루프를 돌아야 하고 그 조건을 검색

할때.. 1~10000번 까지.. 맞는게 있는지를 검색한다

면(select, poll) 이는 많은 비효율을 가져오지 않나 싶

습니다만..... 제 생각이 틀린걸까요? ^^

멀티플렉서가 좋다면.. 서버 쪽은.. 구조상 많은

단순화를 가져오지 않을까 싶습니다....

“바람에게도 길은 있다. 나는 비로소 나의 길을 가느니. 길은 언제나 어디에나 있다.”

liongo의 이미지

흐음 그런가요 저도 서버를 만들면서 고민을 하는부분입니다만..

단순히 루트를 본다면...

epoll [ 이벤트 처리 ]
|
read or recv [ 요청 ]
|
processing [ 처리 ] - [ game processing ] Thread?
|
send or write [ 응답 ]

라고 할경우.. 요청은 1:1 이지만 처리는 1:n이 되겠지요..

MMORPG 기준으로 이야기 하겠습니다..

예를들면.. 한사용자가 한명의 이동 요청이나 말을 할경우..

주위에 사용자가 많은 광장이라고 해두죠 한마디할경우.. 처리가

되는부분을 간단히 따져보아도.. 1번의 요청이지만.. 10000명의

사용자의 내영역( 전달되어야하는 최소 영역 )의 사용자들의 좌표를

계산하여야합니다.. 알고리즘 최적화를 안거친다면 10000명에 대하여

일일이 영역검색을 해야합니다.. 또한 각종 게임관련 예외처리 문들이

포함되지요.. 10000명의 사용자가 한마디씩 말이나 이동 할경우.. 들어온 request 는 만번이지만 실제 처리되야하는 부분은 n의 n승입니다..

장난이 아니지요..

그외에 몹 AI 부분과.. 충돌영역처리 좌표처리 게임 관련 수많은 실시간

처리.. 등이 있지요.. 제가 말씀 드리는부분은..

epoll + 멀티플레서의 프레임웍 부분 구조도 한영역을 차지 하기는 합니다만

심각한 오류를 범하지 않는 심플한 구조라면 작은 수치이상의 성능향상을 기대
하기 힘듭니다.

위의 논의된 처리부분의 최적화된 알고리즘적용이 좀더 무궁한 속도향상을

가져다 줄거라는 거지요..

p.s 제가 논점을 잘못 잡은걸까요..? 다른분들도 의견 부탁드립니다..
제 답글수준이 넘떨어지네요 두서도 없고 ㅜ.ㅜ
역시나 앞으로 답변글 자제하겠습니다.

' 형식이 내용을 규정한다. '

김충길의 이미지

간단하게 성능상 비교를 해볼 수 있는 시뮬레이션을 해보는건 어떨까요?

client와 서버간의 통신은 단순화 시켜서 client가 주기적으로 데이타를 전송하고 서버는 단순한 echo 정도로만 하는 형태를 취합니다.

서버를 poll을 사용했을때와 thread로 사용했을때 나눠서 작성하고 vmstat로 시스템 성능을 지켜보는 정도로 하면 될듯 한데요.

screen + vim + ctags 좋아요~

honestee의 이미지

liongo wrote:
현재 내용으로보고 딱히 말한다면..

답은 없다? 가 아닐가싶습니다.. epoll부분이 영향을 끼치는부분은

전체 서비스의 빙산의 일각이 아닐까 싶구요 나머지는 분산처리에대한

구성이나 서비스에 최적화 튜닝의 문제일것같습니다.

p.s 한서버로도.. 10000명을 수용하는 서버를 구성하신다해도..

epoll의 성능이 좌우하는 부분은 데몬의 성능의 1% 미만이 아닐까요?

동의합니다...

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.