CnUnix

[알림판목록 I] [알림판목록 II] [글목록][이 전][다 음]
[ CnUnix ] in KIDS
글 쓴 이(By): swhan (Nameless 1)
날 짜 (Date): 2003년 2월 28일 금요일 오후 04시 22분 50초
제 목(Title): Re: 프로세스 안에 최적의 쓰레드 갯수??


> 여러개의 감시장비가 있고 그것은 서버와 통신합니다.
> 서버는 또 여러개의 클라이언트와 붙어서 사용자의 명령을 받습니다.
> 통신은 TCP를 통해서 할려고 하고있습니다.
> 클라이언트는 MAX 32, 감시장비는 MAX 512개를 생각하고 있는데,
> 그것을 전부 쓰레드를 이용하는게 적합할까요??
>
> 하나의 프로세스 안에 몇개의 쓰레드 정도가 적합한 것일까요??
>
> 클라이언트와 감시장비는 모두 어떤 일이 있을때만 연결해서 처리하고 ㅐ
> 연결을 끊는 것이 아니라, 한번 연결돼면 연결종료를 지시할때까지
> 계속 연결을 유지하고 있습니다.

성능은 응답시간,트랜젝션처리량,리소스절감, 등 여러 관점에서 볼 수 
있습니다. 우선 이것부터 명확히 해야합니다.
그리고 그와 동시에파악하고 있어야 할 부분은 트랙젝션의 특성입니다. 
32개의 제어 클라이언트와 512개의 센서는 다른 트랜젝션을 발생시킬꺼고 다른 
처리를 요구할겁니다. 

저라면.. 다른 설정이야 어떻든 프로세스 2개로 가겠습니다. 
제어 클라이언트는 아마도 작업의 연속성이 중요할 것으로 보이는데 이건 
각각의 새로운 연결에 대해 thread를 생성하고(연결을 게속 유지한다고 하니.. 
thread pool은 필요 없을 것으로 보입니다) 접속 user의 level에 따라 
스케쥴러의 priority설정을 바꿔줍니다(꼭 필요하지는 않은 일입니다)  
그리고..나머지는  알아서 :)

감시장비는 수가 500개나 될 가능성이 있는데다 트래픽의 처리가 (잠간 
생각하기로) 연속성이 있을 필요가 없을 것 같습니다. (간단히 생각해서 하나의 
web request정도로 보면 될 것 같습니다)
한 10개에서 (테스트 결과에 따라 ) 100개 정도 사이의 thread pool을 유지하고 
master thread는 새로운 TCP 연결에 대해 connection pool을 유지합니다. 
2nd master thread는 모든 연결에 대해 input data가 있는지 
polling합니다.(poll, selelct) input이 있으면 해당 fd를 polling list에서 
삭제하고 놀고있는 thread로 넘깁니다.( mutex + global memory정도면 충분한 
성능이 될 것 같습니다) 
놀고있는 thread중 아무나 이 fd를 받습니다. 그리고 recv, 처리.
처리가 끝나면 이 fd를 2nd master thread로 반환합니다. 

혹시 TCP연결 종료를 검출하면.. 아무놈이나(2nd master가 하든, 검출한 넘이 
하든) 연결종료처리를 합니다. 

master thread를 2개로 분리하는 것은 그냥 코딩을 쉽게 하기 위한 것입니다. 
새로운 연결 또는 연결종료를 검출하면 2nd master thread에 신호를 
보내줍니다. '이봐 poll/select 다시 설정해~'  
poll에서 accept와 recv를 같이 처리하는게 쉬우시다면 그냥 뭉치셔도 상관 
없을 것 같습니다. (poll/select로 read가능을 확인하고 accept했을 경우 time 
delay가 있을 수 있는지는 모르겠습니다.) 

질문과는 좀 다른 방향의 얘기가 됐는데.. 
thread의 총 수는 '써봐야' 알 것 같고, 
thread/process는 process scheduler의 특성을 어떻게 갈 것인가가 문제로 
보이는데 이 경우와는 별 상관 없을 것 같습니다. 

그리고 마지막으로.. 제어 클라이언트와 센서 process 사이에서.. 혹시 어느 
한쪽이 우선순위를 가져야 한다면 sched_getscheduler call을 찾아보세요. 이건 
OS에 따라서 안될 가능성도 있습니다. 

주의하실게.. 혹시나 위급상황에서 샌서로부터 데이터가 마구 날라오는 
상황에서 시스템을 중지시켜야한다면.. SCHED_RR에 priority가 같거나, 제어 
터미날의 priority가 높아야할겁니다. 
반대로, 샌서의 정보에 대해 지연이나 유실이 없어야한다면, 제어터미날에 
과부하가 없도록 뭔가 조치를 해주거나.. 아니면 샌서쪽의 priority가 
높아야겠죠. 
혹시나.. CPU가 2개이고, 프로세싱파워가 넉넉하다면.. 각각의 process를 
CPU별로 할당해주면 이런 조치를 안해도 되겠죠. :) 
CPU가 2개를 넘어가면?  -.-a 


제가 원하시는 얘기를 맞게 한건지 모르겠네요. 길게 써놓고 약발이 없으면 
허무한데... ㅋㅋ

[알림판목록 I] [알림판목록 II] [글 목록][이 전][다 음]
키 즈 는 열 린 사 람 들 의 모 임 입 니 다.