멀디 쓰레드... 요즘 서버프로그램에 대세인가요?
글쓴이: hbsnow / 작성시간: 월, 2003/09/08 - 1:50오후
멀티쓰레드는 프로젝트를 통해 구현해본 사람이구요. 점더 깊이있고 실전에 유용한 쓰레드 지식을 알고 싶어서 책을 찾고 있답니다.
1. Unix Systems Programming : Communication, Concurrency and Threads (2nd Edition)
2. Programming with POSIX Threads (Addison-Wesley)
3. Pthread programing (O'Reilly)
이 정도로 좁혀지는것 같은데요..
요즘 unix 서버 프로그램 모델이 멀티 쓰레드로 가는것 같다는 생각입니다.
아닌가요?
이번 프로젝트(스트리밍 서버)도 멀티 쓰레드로 구현했답니다.
아직 상용화시점은 아니여서 동접, 속도, 안정성은 잘 모르겟네요
전 요즘 unix환경에 서버프로그램을 하는데 속도, 동접, 안정성 이런 부분들에 대해 고민을 많이 하고 있답니다.
개발 3년차구요.
많은 조언과 추천, 도움을 부탁드립니다....
Forums:
서버뿐만 아니라.....
모든 프로그램의 추세가 멀티쓰레드로 가고있고, 그래야 한다는 생각입니다.....
개인 데탑용 프로그램이야 멀티쓰레드의 장점이 당장 나오지는 않지만, 서버의 경우에는 당장 그 장점이 발휘되기 때문에 멀티쓰레드가 좋은 것이겠죠.
Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24
multi processor 환경에서 multi thread 의 장점이
multi processor 환경에서 multi thread 의 장점이 확실하게 살기 때문에최근 들어서 더욱 선호한다고 생각합니다.
세번째...
3번 Pthread programing (O'Reilly)
예전에 어떤 조교님이 책볼라면 위의 것을 보라고 권해주셔서, 한빛에서 구입했던 책입니다.. 다른 사이트에선 품절인가 해서 구하기 어려웠던 기억이..ㅡㅡa
암턴, 이 책을 반이상 보았는데요..오렐리라 물론 사이트가심 코드 받으실 수 있구요...
제 생각에 이 책은 pthread 플밍에 대해 전반적인 이해에 좋은 책 같습니다.
전반적으로 개념에 대해 쉽게 설명하고 있어서, 처음 시작하시는 분들이나 다시 개념을 체계적으로 정리하고 싶은 신 분들이 보시기에 좋은 책 같습니다.
책도 한 손에 잡힐 정도의 아담한 크기에 230페이지 정도되어서, 가볍고..술술(항상은 아니지만..^^;) 책장 넘기는 맛도 있고요..
좋긴 한데, 깊이 있게 보시기엔 좀 부족함을 느끼실 수 있을 것 같아요..
흠..이건 어디까지나 저의 주관적 견해이고요..^^ 참고하세요..
언급하신 첫 번째 책은 practical의 개정판이네요..^^ 저 책도 사보고 싶었던 책 중에 하난데... 함 구경하러 서점에 가봐야겠어요..
책 사모으는게 취미라.. :wink:
* Art is long, life is short *
PThread 괜찮은 책입니다.서버 프로그램들에서 thread 기
PThread 괜찮은 책입니다.
서버 프로그램들에서 thread 기반이 대세이긴 합니다. 하지만 껀당 처리시간이 상대적으로 짧은 경우에는 select 기반의 서버들도 상당히 좋은 결과를 냅니다. 프로세스나 쓰레드를 생성하고 관리하는 등등의 오버헤드가 줄어들어 괜찮은 퍼포먼스를 냅니다. zeus같은 서버들이나 python기반의 medusa같은 넘들도 참고 삼아 보시면 재미있을거 같습니다.
=-=-=-=-=-=-=-=-=
http://youlsa.com
멀티스레드가 많이 쓰이기는 하지만...
멀티스레드가 많이 쓰이고 프로그램하기에도 간단한 모델이긴 하지만
동기화나 컨텍스트 스위칭(스레드 스윗칭이 프로세스 스윗칭보다는 값이 싸긴 하더라도 비용이 없지는 않죠)비용, I/O방식 등
간단히 멀티스레드라고 통칭해 버리기에는 여러가지 고려해야 할 이슈들이 많이 있죠.
전에 어떤 분이 소개해 주신
http//www.kegel.com/c10k.html
나
Stevens의 책만큼 시원하지는 않지만
Schmidt의 Pattern-Oriented Software Architecture vol.2
정도를 참고하시면 어떨까 합니다.
글쎄요...
전 서버 프로그램이라면 도리어 Multi processor 방식으로 가야한다고 생각합니다.
Multi thread 는 제작상의 편리점은 있지만, 유지보수의 측면에서는 무척 힘든방식이 아닌가 싶습니다.
1. 디버깅이 힘듭니다.
문제가 발생하여 프로세서가 죽었다고 가정하면 어떤 연유에서 죽었는가를 다시 찾기위해서는 그 프로세서에 관여된 모든것을 뒤져야만 하지 않을까요?
2. 팀웤 프로그래밍에 불리하다.
Thread 의 경우는 혼자서 프로그래밍을 할때는 편리하지만 작업을 나누어서 해야하는 큰프로젝트의 경우 제작 및 결합의 방법이 모호하지 않을까요?
3. 누군가 Source 를 수정해야 한다면...
제 3의 인물이 Performance 문제 또는 기능상의 문제로 인해 수정을 하여야 한다면 어디서부터 수정을 해야할까를 고민해야 합니다. 물론 해결책으로는 아주 잘 만들어진 Document 가 존재한다면 해결 가능하겠지요.
혼자 궁시렁이었습니다. ^^
저도 멀티 쓰레딩보다는 멀티 프로세서방식이 더 나을것 같다는 생각이 드네
저도 멀티 쓰레딩보다는 멀티 프로세서방식이 더 나을것 같다는 생각이 드네요.
쓰레드는 신경쓸게 꽤 많아, 생산성이 떨어지지 않을지..
잘은 모르겠지만, 멀티프로세서에 비해 멀티 쓰레딩이 아주 뛰어나다면 모를까,
그렇지 않다면..
L-System
상황에 맞게...
이거다 아니다는 아닌것 같습니다. 제 경우에는 상황에 맞게 다르게 제작하는것이 오히려 효과적이지 않을까 생각됩니다. 요즘의 서버의 대세는 멀티 프로세서다 쓰레드다가 늘 대칭점이 존재하지는 않을것 같습니다.
어짜피 멀티 쓰레드나 프로세서나 단지 그 방식 한가지만을 가지고 사용하는 경우는 거의 없을듯 싶습니다. 예를 들면 비즈니스 로직이 결여된 미들웨어를 제작한다면 구지 협업이라던지 이런 경우는 거의 발생하지 않을듯 싶습니다. 이곳에 프로세서를 계속 띄워 나간다면 오버헤드가 너무 크지 않을까 생각됩니다. 저는 당연히 이러한 시스템에는 멀티쓰레드나 멀티플렉싱쪽에 한표를 던집니다.
비즈니스 로직 서버들의 경우는 대체적으로 1개의 마스터 프로그램에서 분기해나가는 경우가 대부분인것 같습니다. 즉, 마스터 부분은 라이브러리 형식의 동적라이브러리를 링킹할수 있게 해주고 그 룰에 따라서 개별 비즈니스 로직들을 서로 나누어 제작하는 경우가 대부분인것 같습니다. 이럴 경우에는 멀티 프로세스 방식을 따르겠지요.
시스템의 안정성이나 디버깅이나 사실 환경에 맞게 따로 따로 생각하시면 매한가지가 아닐까 생각됩니다. 미들웨어쪽(혹은 프론엔드 서버)에서 생각한다면 개별 비즈니스 로직이 적용되는 경우라기 보다 대부분 공통 모듈이 아닐까 생각됩니다. 이러면 오히려 협업작업이라는것이 더 방해가 되지 않을까 생각됩니다.( 제 개인적으로 이러한 서버는 똘똘한 1명의 제작이 효율적이라고 생각됩니다)
쓰레드 모델의 최악을 대표하는것이 '그래 같이 죽자'하는 자폭성에 의구심을 두는 경우도 있는데 요즘 시대에 예외처리 구문이 원 코드의 평균 10배 이상 된다는것인 보통이 아닐까 생각되는데 죽어야 얼마나 죽을까 하는것이 제 개인적인 생각입니다. 오히려 다운에 대한 위험은 자주 변하거나 예측 불가능한 비즈니스 로직쪽이 아닐까 생각됩니다.
또한 수정의 경우에도 표준C를 따르고 메크로를 그리 많이 사용하지 않고 정말 싸이키델릭한 코딩스타일을 따르지 않는 다음에야 대부분 어렵지 않게 제 3자가 접근할수 있지 않나 생각됩니다.
따라서 제 개인적인 생각은 그러한 부분이 분명 분리가 되어야 하고 어느 한쪽이 반드시 대세는 아닐거라고 생각됩니다. 은행에 시스템에 들어 가면 4CPU라고 하도 1개의 서버당 동시에 50개의 트렌젝션만 요구하는 사이트도 존재하고 안정성만을 최 우선으로 삼거나 혹은 같은 은행이라고 해도 트렌젝션 처리건수에 더 심혈을 기울이는 환경도 같이 존재한다고 생각됩니다. 이런곳에서는 프로세스 모델에 대해 부정적인 시각을 보내는 책임자들도 이제는 자주 보게 됩니다.
그냥 상황에 맞게 따로 구현을 해주거나 시스템에 옵션을 두어 개별적으로 동작하게 해주는것도 좋은 방법이 아닐까 생각됩니다. 개인적으로는 이러한 방법을 사용하는데 같은 제품을 가지고 총 5군데 사이트에 적용을 했는데 32로 쓰레딩이 조금 앞서는 정도입니다.
Server 와 Client 의 관계가 아닐지......
제가 알고 있는 서버와 클라이언트의 특징은 일반적으로 이렇습니다.
서버.
1. 서버의 처리량이 계산되어진다.
2. 안정성을 최우선으로 생각한다.
3. 처리능력을 최대한 균일화 한다.
클라이언트
1. 사용 프로세서의 갯수를 알 수 없다.
2. 사용가능 Resource의 한계점을 알 수 없다.
3. 언제든지 죽어도 좋다(?)
윗분이 말씀하셨듯이 꼭 이래야한다 저래야한다는 규칙은 없습니다. 하지만 통상적으로 이제까지 프로그래밍을 하면서 느낀점은 이렇군요.
-- 서버 --
1. 서버의 처리량이 계산되어진다.
서버를 결정할때는 실제처리할 량이 얼마나 되는가를 가능한 문제분석 단계에서 세밀히 조사하고 결정되어졌읍니다.
2. 안정성을 최우선으로 생각한다.
서버는 일반적으로 항온항습에 UPS 의 정전압을 받으며 최상의 조건을 유지하는곳에 설치가 되어집니다. 이것은 24시간 죽지않고 쌩쌩 잘 돌기를 기원하기 때문입니다.
3. 처리능력을 최대한 균일화 한다.
어떤 Traffic 에 의한 불균형성은 실 User 로 부터 많은 반감을 살 수 있는 문제에 직면할 수 있고, 공장에서 사용되어지는 서버의 경우 프로그램의 신뢰성을 의심하는 단계에까지 돌입하게 될 수 있습니다.
위 사항으로 봤을때 리소스 사용량의 한계성도 결정되어지고, 처리량 또한 결정되어지므로 서버 구입시 이를 고려한 투자가 이루어지므로 프로세서가 뛰워졌다 죽었다하는 경우는 서버에는 큰 의미가 없지 않나 싶습니다. 즉 처음 기동해서 서버가 셧다운될때까지 쭈~~~욱 계속 살아 있는것이죠.
24시간 계속 가동하는 프로그램에서 어느순간 문제가 발생하여 프로세서가 죽었을경우 이를 조속히 처리하지 않는다면 문제의 단계는 더 심화되어질것이 뻔합니다. 실제 이런경우를 만났을때 조그마한 소스라도 수정하기위해 뚜닥거리고 있는데 뒤에서 수많은 높으신 관계자 여러분(?)이 모여 자신의 뒤통수를 노려보고 있다면 식은땀만 줄줄 흐르고 문제의 본질을 찾았을때는 2배, 3배의 시간이 흐르고 난 뒤이죠.^^
로직을 구사하다보면 가끔 업무의 특수성을 망각한 코드들을 보게 되는데, 예를 들면 Windows XP 처럼 부팅을 빠르게 할것인가 아니면 Windows 2000 처럼 초기 부팅 동작은 느려도 실 동작이 빠르고 안정적일것인가 하는것이죠. 대부분의 경우 2가지 다 만족을 하면 좋겠지만 실제로는 둘중 한가지를 목표로 잡게 됩니다. 이경우 대부분 서버는 동작의 안정성과 빠름을 요구하고 클라이언트는 빠르게 부팅되기를 원하죠^^
-- 클라이언트 --
1. 사용 프로세서의 갯수를 알 수 없다.
2. 사용가능 Resource의 한계점을 알 수 없다.
두가지는 같은 뜻을 나타냅니다. 즉 사용자의 화면 해상도, 메모리 크기, CPU 의 처리속도가 제각각이죠. 하지만 일반적인 클라이언트 프로그램은 동작만 하면 되기 때문에 실제 사용되어질때만 Heap 이나 Thread 를 할당하여 동작 유지를 최소화 시키는 방법을 택하죠. 즉 대부분의 서버프로그램에서는 초기 동작때 프로세서나 Heap 을 결정 하여 안정성과 성능의 균일화를 요구하지만 Client 는 이런 오버헤드는 유저에게 큰 불만거리가 못된다는것입니다. 도리어 최대한 적은 메모리에서도 동작은 가능하므로 최상의 방법입니다.
3. 언제, 어디서나 죽어도 좋다(?)
Windows 계열을 쓰면서 짜증나는것은 뻑하면 죽는다는것과 뭔가 프로그램을 설치하고나면 무조건 리붓을 요구하는 악성 취미(?)가 있죠.
워드나 엑셀을 쓰다가 프로그램이 죽어도 "XX" 하고 욕한번 내뱉고 또다시 이 이상한 프로그램(?)을 우리는 쓰고 있습니다.
그런데, 만일 서버 프로그램이 이렇다면? 무척 난감하시겠죠?
이상 내가 느끼는 서버와 클라이언트입니다. 위분의 말씀처럼 흑백논리로 프로그래밍 한다는것은 정말 위험합니다.
그 업무에 가장 이상적인 케이스를 만들어주는것이 제일좋습니다.
댓글 달기