[ CnUnix ] in KIDS 글 쓴 이(By): guest (guest) <203.236.3.241> 날 짜 (Date): 2002년 10월 10일 목요일 오후 08시 33분 48초 제 목(Title): [q] IPC performance (socket)? IPC로 tcp socket program이 빠른가요? 아니면 Domain socket이 빠른가요? 그리고, Domain socket이 UDP와 유사하게 돌아간다고 하는데, UDP와 Domain socket중에는 뭐가 더 빠른까요? 현재 1 machine안에 1개의 server program이 있고, 이와 통신하는 client가 약 100여개 있는데, 이가운데 ipc를 tcp socket으로 했더니 속도가 좀 느려서 Shared memory를 했더니 어쩔수 없이 polling을 해서 tcp보다 그리 좋을것도 없네요... 그래서 UDP와 domain socket으로 바꾸어 볼까 고민중입니다. 이때 packet loss때문에 ack해주는 logic도 포함해야 되겠지요? 이와 유사한 문제를 먼저 경험하신 고수분의 훈수 부탁드립니다. [ CnUnix ] in KIDS 글 쓴 이(By): Tony (登仙狹路) 날 짜 (Date): 2002년 10월 11일 금요일 오후 04시 33분 45초 제 목(Title): Re: [q] IPC performance (socket)? shared memory만 쓰셔서 폴링하셨나요?? semaphore를 함께 쓰심 될것같은데요?? 그쪽이 가장 빠른걸로 알고있습니다... socket으로 만들면 클라이언트를 다른컴터에 이식하거나 포팅하기야 편하겠지만 장점 없을듯요... [ CnUnix ] in KIDS 글 쓴 이(By): swhan (foo bar) 날 짜 (Date): 2002년 10월 12일 토요일 오후 02시 24분 58초 제 목(Title): Re: [q] IPC performance (socket)? 일단 속도라고 해도 다 같은 속도가 아닙니다. A가 보낸 다음 최대한 빨리 B가 받게 하는걸 원하는지 단위 시간에 최대한 많은 데이터를 보내려고 하는건지 또, 패킷 크기는 일정한지 아니면 아주 작은 패킷에서 큰 패킷까지 다양한지. 해당 시스템에만 최적화 되면 되는지 아니면 포터블해야하는지, 포터블이면 Unix에서만인지 아니면 RTOS나 windoze등등도 고려해야 하는지.. 모든 경우에 대해서 다 적기는 양이 너무 많고 제 머리속에 알코올도 너무 많군요. :) (잠간 생각해봤더니 모든 경우에 대해 다 적을 능력이 없군요. -.-a) 어떤 종류의 성능을 원하시는지 기술해주시면 할 말이 좀 생길 것 같습니다만.. @ Unix domain socket의 경우, Datagram은 OS마다 특성이 틀립니다. Linux는 유실 없다고 못박아놨고 Zolaris는 테스트 결과 유실 없는 것 같고 Tru64는 테스트 결과 유실 절라 많습니다. 다른건? 모르겠습니다 -.-a [ CnUnix ] in KIDS 글 쓴 이(By): Tony (登仙狹路) 날 짜 (Date): 2002년 10월 12일 토요일 오후 06시 33분 58초 제 목(Title): Re: [q] IPC performance (socket)? 근데 그래도 semaphore와 sharedmemory가 무조간 최고의 성능 또는 최고와 같은 성능을 내지 않을까요? 일단 datasize가 커지면 sharedmemory가 copy overhead를 먹어버려서 유리할것 같고.. datasize가 작아도 semaphore나 semaphopre와 같은 방법으로 구현된 인터페이스를 통과할테니... 아무리 생각해도 세마퍼+공유메모리로 구현한것보다 빠르게 만들 방법이 안떠오르는데요? [ CnUnix ] in KIDS 글 쓴 이(By): swhan (foo bar) 날 짜 (Date): 2002년 10월 13일 일요일 오전 07시 54분 08초 제 목(Title): Re: [q] IPC performance (socket)? shared memory가 빠르다는데 이의를 달 사람은 없겠지만, semaphore가 Unix System V IPC의 그 semaphore라면 그리 빠른 방법은 아닙니다. portable하고는 거리가 약간 있지만 한 2~15줄만 블랙박스로 하나 만들어두면 atomic lock이 제일 빠릅니다. CPU별로 test-and-set이나 비슷한 역할을 할 수 있는 instruction set이 있으니까 포팅시에 약간씩만 손봐주면 됩니다. (4 byte or 8 byte : 실제로는 1bit이용) 이보다 조금 느리지만 포터블한 pthread_mutex_XXXX도 있습니다. 메모리는 atomic lock보다 좀 많이 먹지만 속도는 빠르(다고하)ㅂ니다. :) (약 60 byte) 여러개 만들기 어렵고 좀 귀찮은 방법이지만 file lock도 상당히 빠른 방법중의 하나라고 합니다. semaphore는 이 뒤에 놔야 할겁니다. :) 만약에.. shared memory를 쓰면서 그 공간을 application이 직접 읽고 부분 update하고 다시 넘기고 등등을 할게 아니라(공유공간이 아니라) data를 copy해가고 끝날꺼라면, posix message queue가 더 좋을겁니다. 속도는 posix shared memory + pthread_mutex를 조합한 속도중 최고의 속도를 내면서 다양한 기능을 제공해줍니다. 단점이라면, shared memory를 쓰고 최고의 속도를 내기 위해 미리 정한 크기의 message array를 유지하기 때문에 memory에 비효율적이고 미리 정한 크기 이상의 message를 넘기려면 user가 fragmentation and reassemble을 수작업으로 해야 한다는 점. frag & reassemble이 귀찮으면 stream socket이나 pipe를 써야겠죠. connection 관리를 해줘야겠지만 :) @저는 대용량 트랜젝션에 일정 시간 이내의 turn around time을 가져야 하는 경우가 있었는데, (server time 400ms이내, 평균 100~200ms이내, process수 5개 이상, 2-phase commit포함) shared memory에 buffer pool을 만들어두고 썼었습니다. memory copy가 상당한 overhead가 되는 상황이어서... atomic lock과 message별 flag set, posix signal 조합. 호주애들은 보니까 buffer pool유지하고, atomic lock를 쓰면서 transaction을 다른 process로 넘기는데는 posix signal을 쓰더군요. 초당 트랜젝션에는 아주 약간의 손해가 있지만 반응속도는 단연 최고입니다. 물론 선점형 커널이라는 전제가 필요합니다. :) @참 shared memory도 posix shared memory를 쓰면 수백메가 이상의 공간 할당하는게 좀 쉬워집니다. sysV shared memory는 공간 학보가 너무 어려워서리 -.-a [ CnUnix ] in KIDS 글 쓴 이(By): sang (멍텅대만) 날 짜 (Date): 2002년 10월 13일 일요일 오후 01시 50분 27초 제 목(Title): Re: [q] IPC performance (socket)? 벅님 의견에 대체적으로 동감하며 한가지 질문이 있습니다. 제 체감적(?) 느낌으로는 pthread mutex lock이 절대 빠른거 같지가 않습니다. 그래서 가급적 pthread를 사용하지 않고, atomic lock과 signal을 사용해서 코딩해 왔는데(제 경우는 주로 kernel mode에서 동작하는 모듈들을 코딩하는데 mutual exclusion을 kernel module내에서 해결해주느냐 user mode의 pthread 내에서 해결해주느냐를 결정해야 할때가 종종 있습니다.) 혹시 pthread_mutex_lock의 속도를 정량적으로 측정해 놓거나 다른 critical region 보호 방법들과 비교해 놓은 자료가 있는지 궁금합니다. 그러고보니 님의 글에서 호주애들이 사용한 방법이 제가 사용하는 방법과 거의 동일하네요. [ CnUnix ] in KIDS 글 쓴 이(By): Tony (登仙狹路) 날 짜 (Date): 2002년 10월 13일 일요일 오후 02시 45분 21초 제 목(Title): Re: [q] IPC performance (socket)? pthread 에대해서는 어떤 플랫폼에서 어떤 구현이 그런지 명시를 해줘야 할 것 같네요... ㅎㅎㅎ posix thread라는게 interface정의일 뿐이니... 속도 비교에 대해서도 implementation과 사용한 인터페이스에따라 너무도 달라지기때문에 분석 자료가 나오기 쉽지는 않을듯요.. 이러이러한 케이스에는 이런 구현이 빠르다 하는식의 자료들은 가끔 본 것 같은데요. 뭐가 빠르다 하기엔 좀... ps. ㅎㅎ그래도 저도 swhan님 의견에 대부분 동의. 슝~~ 수정했다는... [ CnUnix ] in KIDS 글 쓴 이(By): swhan (foo bar) 날 짜 (Date): 2002년 10월 13일 일요일 오후 11시 19분 02초 제 목(Title): Re: [q] IPC performance (socket)? 흣~ 날카로운 지적 pthread mutex의 속도에 대해서 implementation마다 다를 수 있다는 것은 저도 동의합니다. 하지만 어떻게 다를 수 있는지는 전혀 감이 안오는군요. 다만, thread의 경우처럼 껍떼기만 씌우기는 좀 어려울 것 같고, signal의 경우처럼 커널이 좀 많이 변해야 하는 것 같지도 않고... mutex가 말이 pthread_mutex지 thread를 쓰지 않는 겨우에도 갖다 쓰거든요. 자백하자면, 전 pthread_mutex와 semaphore의 속도 비교는 해보지 않았습니다. 다만 빠른 lock방법을 찾던중, 수 많은(근거를 댈 수 없는!!!) 자료들이 atomic lock이 빠르고 semaphore보다는 pthread mutex가 빠르다....고 말을 하길래 -.-a 그리고, 제가 이거로 고민할 시절에는 user mode에서만 해결해야 했었습니다. 도중에 context switching이 일어나지 않도록 노력했구요. 그래서, 완전한 또는 부분적 선점형 커널을 고르고 process scheduler도 선택하고 등등 작업도(당연하지만) 해줬었구요. (하고픈 말은 커널모드는 모르겠다...배째시라~~ 뭐 이런거죠 -.-a 죄송합니다) 흠..signal도 sysv signal과 posix signal이 특성이 틀리고 반응속도나 유실 여부도 틀리니 속도가 틀리다고 말을 해야겠군요. @그리고 전 swhan인데요 -.-a @생각난김에 웹서핑이나 해야겠군요. lock속도에 대한 벤치마킹... @참..전 atomic lock을 pthread_mutex대신 선택한게..memory size 때문이었습니다. 코드를 가급적 portable하게 만들어 달라는 요구가 있어서 assembly 코드를 넣지 않으려고 했는데 pthread_mutex_t의 크기가 60Byte정도 하는바람에 수천개 array랑 곳곳에 삽입하기가 참 어려워지더군요. (읔 지금 Zol5.6에서 손으로 대충 세어보니 24Byte로군여. 치매일까 implementaion 차이일까... -.-a ) [ CnUnix ] in KIDS 글 쓴 이(By): Tony (登仙狹路) 날 짜 (Date): 2002년 10월 14일 월요일 오전 12시 17분 35초 제 목(Title): Re: [q] IPC performance (socket)? ㅎㅎ 언능 위로 올라가서 수정했다죠... ATOMIC LOCK은 LOCK변수 두고 POLLING하기땜시 락이 풀린후 반응속도가 가장 빠를수밖에 없습니다. 문제는 폴링이기때문에 LOCK변수에대해서는 빠른 반응을 보이지만 전체적인 시스템성능은 떨어뜨리죠.. PTHREAD_MUTEX는 흠흠.. 보통은 유저레벨에서 구현했다고 치고 Kernel Switching Overhead없다는 이유로 빠르다는 말이 도는 거 같고 semaphore는 커널을 통과하니만큼 느리다고 하는게 아닐까.. 생각합니다만 이런 이유로 7-80년대 논문들이 하는 소리라면 요즘쓰는 시스템에서는 조금 다를지도 모를것 같네요.. 커널 지원 안받는 PTHREAD찾기도 힘들고.. [ CnUnix ] in KIDS 글 쓴 이(By): swhan (foo bar) 날 짜 (Date): 2002년 10월 13일 일요일 오후 11시 57분 47초 제 목(Title): lock benchmark 1) http://www.geocrawler.com/archives/3/417/2001/7/100/6291232/ atomic lock 없이 나머지만 테스트했는데 나머지난 보통 예상대로지만 fcntl이 좀 많이 느리군여. flock이 빠르다고 누가 그랬던가? semaphore보다는 빨라야 체면을 좀 세워줄텐데.. 2) http://www.llnl.gov/CASC/mixed_models/presentations/sdsc_pthreads.pdf 이건 HP-UX에서 pthread에 대한 벤치마크. (lock방법간의 속도비교는 아닙니다) 99년 자료이긴 하지만 숫자가 재미있군요. 중간에 mutex도 나옵니다. sun하고 비교도 있구요. 3) http://inf33-www.informatik.unibw-muenchen.de/research/milan/paper_milan.pdf 지금까지 얘기와는 별로 상관 없지만 Linux에서 약간의 benchmark 테스트 결과가 있습니다. 선점형 커널에 대한 설명과 Linux의 커널 특성 약간. 벤치마크 약간 그리고는 나머지는 광고(라는 느낌이)네요 :) 아~ 졸려서 이만 자야겠네요. 1번에서 atomic lock과 pthread와 비교를 해줬으면 더 좋았을 것을... 츱.. [ CnUnix ] in KIDS 글 쓴 이(By): swhan (foo bar) 날 짜 (Date): 2002년 10월 14일 월요일 오전 12시 29분 24초 제 목(Title): Re: [q] IPC performance (socket)? @ㅎㅎ 자려고 했는데 계속 Re:가... 이러다 게시판 talk이 되겠네요 :) @앗 벌써 수정해주셨군여. 감사합니다. :) >ATOMIC LOCK은 LOCK변수 두고 POLLING하기땜시 락이 풀린후 반응속도가 가장 >빠를수밖에 없습니다. 문제는 폴링이기때문에 LOCK변수에대해서는 빠른 반응을 >보이지만 전체적인 시스템성능은 떨어뜨리죠.. 이건 spin lock을 말씀하시는거죠? atomic lock을 쓴다고 해서 항상 spin을 시키라는 법은 없잖습니까? 항상 쓰나? o.O [ CnUnix ] in KIDS 글 쓴 이(By): Tony (登仙狹路) 날 짜 (Date): 2002년 10월 14일 월요일 오전 10시 11분 13초 제 목(Title): Re: [q] IPC performance (socket)? atomic lock을 쓰면서 test and set하면서 polling안하는 방법 있나요? 마땅한 방법이 머릿속에서 생각 안나는데요? 혹시 아시는분~~ [ CnUnix ] in KIDS 글 쓴 이(By): terzeron (microkid) 날 짜 (Date): 2002년 10월 14일 월요일 오전 10시 33분 27초 제 목(Title): Re: [q] IPC performance (socket)? atomic lock의 정의가 뭔지 확실치 않지만 high-level lock의 구현을 위한 가장 작은 단위의 도구가 되는 거라면 각각의 아키텍쳐가 지원하는 어셈블리 수준의 코드가 될 것이고, spin lock이 testandset을 이용하여 while loop으로 묶어준 atomic lock보다 한 단계 높은 수준의 lock으로 알고 있습니다. PS x86에서는 testandset이 xchg(assembly)를 이용해서 지원되는 것 같더군요. [ CnUnix ] in KIDS 글 쓴 이(By): swhan (foo bar) 날 짜 (Date): 2002년 10월 14일 월요일 오전 10시 36분 43초 제 목(Title): Re: [q] IPC performance (socket)? 흠..제가 용어를 혼동하는건가요? 그럴지도 -.-a for( trycnt = 0; trycnt < 10 ; trycnt++) { for( i = 0; i < 200; i++) { if( trylock() == SUCCESS) return SUCCESS; } sleep minimal interval; } return FAIL; 에전에 spin lock thread에서 퍼온건데.. 전 단지, 위에 200번 spin을 돌리지 않아도 되지 않겠나? 하는 의미로 한 말입니다. trylock()만 따로 떼어서 쓰면 (모양은 어떨지 몰라도) 큰 부하가 걸리는건 아니지 싶어서요. :) @앗 그새 terzeron님이 re를 다셨네요. 전 바로 그런 의미로 쓴 말이고 atomic lock은 testandset 또는 testandset과 spinlock을 지칭하는 의미로 썼던 것입니다. @간만에 재미있는 thread죠? :D [ CnUnix ] in KIDS 글 쓴 이(By): dalgong (달공아저씨) 날 짜 (Date): 2002년 10월 14일 월요일 오전 10시 45분 19초 제 목(Title): Re: [q] IPC performance (socket)? busy waiting하는 방법도 문제의 성격마다 다르겠지만, multi-processor인 경우에 context-switch를 피할 수 있는 아주 효과적인 방법입니다. IPC의 속에 관한 거라면 SUN doors에 관한 언급이 없길래 저도 껴듭니다. 스티븐스 책에 보면 ipc performance비교한 자료 있습니다. [ CnUnix ] in KIDS 글 쓴 이(By): swhan (foo bar) 날 짜 (Date): 2002년 10월 14일 월요일 오전 10시 59분 14초 제 목(Title): Re: [q] IPC performance (socket)? 네. SMP의 CPU간에 쓴다고 들었고(썼었고) 모 코드 보니까 device들끼리도 쓰더군요. (본론은 이게 아니고 -.-a) SUN doors가 뭔가요? (구글에서 찾으니까 이상한 문짝과 태양빛 등등에 대한 얘기만 나오네요 -.-a) 그리고 스티븐 아자씨 책에 뭐라 나와있는지 간단하게 누가좀 알려주세요 집에는 한 10년 지난 책만 있고 주변에 스티븐 아자씨 책을 가진 사람이 없는 동네에 와있어서 :( @수정입니다. 이런 링크를 찾았네요. :) Doors/Linux is an implementation of the Solaris Doors API on the Linux operating system. The Doors API provides a high-speed RPC mechanism which uses the UNIX notion of the filesystem as a universal namespace and has built-in support for multithreading. [ CnUnix ] in KIDS 글 쓴 이(By): vinawara (우산장수) 날 짜 (Date): 2002년 10월 15일 화요일 오전 10시 32분 43초 제 목(Title): Re: [q] IPC performance (socket)? 저도 doors로 끼어들까 하다가 locking쪽으로 이야기가 흘러가기에 그냥 보고만 있었습지요. doors라는건 local process간의 function call이 가능한 매커니즘정도로 이해하면 되겠군요. ( LPC 정도면 될려나 ) named-stream(named-pipe 비슷한)에 function을 맵핑시켜서 다른 프로세스가 call할 수 있도록 하는것이지요. 성능은 꽤 믿을만한 수준으로 알고있습니다. Linux port쪽에서 실험한 데이터로는 unix-domain socket, pipe등과 비교해서 제일높은 성능을 나타내었다더군요. 당연히, solaris의 application들도 door를 꽤 많이 이용하는것 같구요. 제가 있는 팀의 어떤분이 signal/sharedmem방식에서 signal loss가 발생해 문제가 있던것을 door를 써서 해결 사례(?)도 있습니다. ( 스티븐아저씨의 UNP 2ND Ed.의 Vol.2 IPC에서도 한챕터를 할애에 설명이 되어있습니다. 보다 자세한 설명은 여길., 혹은 man door_create 라고 하셔도 :) ref. Door Linux port : http://www.rampant.org/doors Kernel 2.2까지만 포팅이 되었고 그 이후로는 프로젝트가 중단되었습니다. 대충의 예제는 아래와 같습니다. Server Side ---8<--- #include #include #define TEST_COOKIE ((void *)0xa4a4b5b5) #define TESTDOOR ".testdoor" void server_proc(void *cookie, char *argp, size_t arg_size, door_desc_t *dp, size_t n_desc) { door_cred_t cred; printf("hi dude\n"); : door_return((char *)"Hey man", strlen("Hey man"), NULL, 0); } main() { int door, fd; if ((fd = creat(TESTDOOR, 0600))<0) { perror("creat"); exit(1); } close(fd); if ((door = door_create(server_proc, (void *)TEST_COOKIE, 0))<0) { perror("door_create"); exit(1); } fdetach(TESTDOOR); if (fattach(door, TESTDOOR)<0) { perror("fattach"); exit(1); } printf("OK START Service\n"); for(;;) pause(); } client side ---8<--- #include #include #include #define TEST_COOKIE ((void *)0xa4a4b5b5) #define TESTDOOR ".testdoor" main() { door_arg_t args; door_info_t info; int fd; char res[255]; if ((fd = open(TESTDOOR, O_RDONLY))<0) { perror("open"); exit(1); } if (door_info(fd, &info)<0 ) { perror("door_info"); exit(1); } printf("fd = %d\n", fd); args.data_ptr = (char *) "HuHu Hi"; args.data_size = sizeof("HuHu Hi"); args.desc_ptr = NULL; args.desc_num = 0; args.rbuf = res; args.rsize = sizeof(res); if (door_call(fd, &args)<0) { perror("door_call"); } printf("args.rbuf = %s\n", args.rbuf);