orinmir story Linux High Perf Server


::: _컴퓨터 computer

Linux HighPerformance Network Server

문서상태	작성: 이홍기(orinmir _at_ chonga _dot_ pe _dot_ kr) 작성일: 2001년 6월 10일 문서버전: 0.1.2 저작권: GPL 수정일: v0.1.0 ; 2001-06-10; 문서 초안 완성 v0.1.1 ; 2001-06-12; RT signal concurrent echo server example v0.1.2 ; 2004-06-06; 일부 오자 수정 포기각서: 이 문서는 개인적인 자료 정리의 용도로 작성되었으며, 이 문서의 내용에 대한 모든 권리를 포기함. 또한 저작권에 대한 분쟁 발생시, 해당 내용은 삭제토록 한다. TODO: 이 문서는 아직 draft상태에 있으며, 대부분의 저작자에 대한 정보를 link하려고 한다. 물론 빠진 부분은 보강해 나가고자한다. 좀더 유용한 예제들을 위주로 갱신할 예정이다.
개요	Linux에서의 TCP/IP Socket 기반 고성능 서버를 제작하는 방법에는 고전적인 multiplexing io(select, poll)를 가장 많이 사용하는데, 이는 매번 kernel로부터 전체 file descriptor 를 조사하여 set을 만들어 리턴하도록 하는 방식으로 high load 일수록 CPU점유율과 응답시간이 길어지는 단점이 있다. 물론 이를 사용하여 서버프로그램을 제작하여도 1000-3000명 많게는 5000개의 클라이언트 접속을 처리할 수는 있다고 보고되고 있다. 오늘날에 와서는 여러가지 성능향상을 위한 시도가 이루어지고 있는데, 기존의 poll에 대한 성능향상을 꾀하여 /dev/poll아 같이 장치 인터페이스를 사용하는 방법(solaris 8에 도입되었다)과 기존의 SIGIO를 이용한 고전적인 방법이외에도 Realtime(RT) signal을 이용한 IO Completion signal 방식으로 high load에서의 낮은 CPU 점유율과 빠른 응답시간, inactive client 접속이 많아지더라도 처리에 문제가 없도록 하기 위한 방식들이 연구되고 구현되고 있다. 타 운영체제에서는 FreeBSD의 kqueue/kevent와 Windows계열의 IOCP(IO Completion Port) 등이 있으며 OS kernel내에 관심있는 소켓들에 대해 이벤트를 등록해놓고 kernel로부터 signal을 기다리는 방법으로 그 내용은 거의 대동소이하다. 본 문서에서는 리눅스에서의 Linux(kernel 2.2.x 이상)에서 사용할 수 있는 RT signal과 기존의 poll을 개선한 /dev/poll에 대해 이야기해보고 실제 고성능 서버의 소켓 모델에 대해서도 살펴보기로한다.
select vs. poll	고전적인 bsd socket의 multiplex io 처리 방식은 select()와 poll()에 대한 이야기로는 poll()방식이 select()에 비해 좀더 낮은 CPU점유율과 빠른 응답속도로 고성능의 서버프로그램에서 사용되고 있다는 이야기들이 일반적이다. linux의 경우 2.0전에는 poll()이 구현되어 있지 않아 select() system call을 매핑하여 poll()을 구현하였으며, 2.0이후에는 poll()이 구현되어 반대로 select()가 poll()의 매핑 system call로 바뀌었다. 그렇다면 왜? poll()방식이 더 select()보다 효율적인가? 쉽게 생각하면 poll()이 좀더 low level의 처리로 system call의 호출이 select()보다 적기 때문이다. select의 경우는 처리하고자 하는 socket만을 감시하는 것이 아니라, max filedescriptor만큼을 항상 loop를 돌며 처리해야하고 poll은 이에 비해 원하는 만큼만 max로 지정해서 늘어나는 만큼 loop를 돈다. 하지만 select()가 poll() 보다 사용하기가 조금더 쉽고 poll()을 이용하여 select()를 구현하기도 한다. poll이 select보다 효율적이지만 접속수가 늘어나면 오히려 fd당 체크 마스크의 크기가 select는 3bit인데 비해, poll은 6Byte(이부분 확실하진 않음)정도이므로 양이 많아지면 오히려 select보다 더 많은 overhead가 존재하여 성능이 더 떨어진다는 이에 대한 벤치마킹도 존재한다. 특히 리눅스에서는 그렇다는 얘긴데, 이로 인해 그리 좋은 소리는 듣고 있지 못하긴하다. 고전적인 select/poll에서의 성능 향상 방법으로는 multiple accept가 있다. 이 방법은 process fork방식에서 예를 들자면 child를 spawning시켜(listen pool형성), accept를 받아 recv/send를 해주고 끊어주는 일반적인 request-response-close로 이어지는 webserver style의 구현 방식이며, 이를 이용한 벤치마킹에서 좋은 효율을 보이고 있다. 또한 고전적인 select, poll 자체에 대한 성능 향상 패치도 물론 존재하고 있다. examples: Unix Network Programming 2e의 poll과 select 구현예제, multiple accept, multiple accept2 articles: Select() vs. Poll(),
/dev/poll	/dev/poll은 poll()의 처리 방식이 kernel내의 file descriptor 를 모두 뒤져서 응답 set을 구성하는 방식의 비효율성을 극복하기 위해 나온 방식으로 기본적으로 event driven방식으로 이루어진 poll의 성능 개선방식이다. poll을 장치 입출력 방식으로 바꾸어놓은 것이라고 볼 수 있다. 벤치마킹에서 linux /dev/poll이 성능이 제대로 나오지 않는 이유는, /dev/poll의 구현에 버그가 있다는 이야기도 있다. patches: dev_poll kernel patch(kernel 2.2.14,/ kernel 2.4.3) from here
RT Signal	커널 2.2에서부터 RealTime Signal(Posix RealTime Signal)을 지원하기 시작했다. 기존에 signal을 이용한 내용으로 sigio를 이용한 async io(타 운영체제에서는 aio_* function calls로 된 것도 있음) 에서 쓰였고 2.2가 나오기전까지는 패치를 통해 비동기 io를 사용할 수는 있었다. sigio를 이용한 signal 기반 소켓 서버의 예제도 stevens의 Unix Network Programming같은 서적을 통해서도 소개된 바있다. Linux의 RT signal방식은 기존 signal 기반 프로그램들보다는 좀더 접근하기 쉬운 방법으로 Poll을 대체할 수 있는 방법이다. (poll()에서 사용하는 POLL_IN, POLL_OUT, POLL_ERR 등을 그대로 사용한다.) RT Signal의 장점(혹은 sigio로 만들어진 것들의 장점일수도 있다.)이라면, signal을 등록해놓고 해당하는 이벤트가 발생하기 전까지는 되고 sigwaitinfo system call을 통해 대기하고 있다가, 이벤트가 발생하면, 정해둔 signal handler를 통해 처리를 하는 방식이다.(또한 timeout도 지원한다.) 물론 기존의 구현 방식에 비해 낮은 CPU점유율과 빠른 응답 속도, high load에서도 안정되고 일관된 성능을 유지하고 있다. 5000개의 소켓 접속과 high load에서도 굉장히 좋은 성능을 내고 있다는 보고가 있다. 하지만 RT Signal의 단점은 제한된 signal resource로 인해, signal overflow가 되면 더이상 새로운 접속을 처리할 수 없게 된다. 이 때에는 기존의 poll()쪽으로 처리를 돌려 해결하는 혼합된 구현 방법을 쓰기도 한다. 이를 해결하기위해 Vitaly라는 사람이 Signal-per-fd라는 kernel patch를 내놓았으며 기존의 kernel의 signal queue가 fd별로 multiple event를 받아내어야 하므로, high load시에 overflow가 일어날 수 있다는 단점에 착안, fd별로 단 하나의 signal event만을 가질 수 있도록 고쳤다고 한다. 이를 이용하여 기존의 방식들과의 성능 분석을 한 paper는 아래에 있다. 한편, Linux RT Signal로 구현된 것으로는 phhttpd가 있다. 최근 필자가 Linux RT Signal(signal-per-fd는 아직 추가 구현중)로 만든, 완벽한(???) Concurrent Echo Server 예제를 아래(rtsig_echoserver.cpp)에 링크해놓았다. examples: rtsig_echoserver.cpp, sigio_example articles: Signal-per-fd release document, patches: Signal-per-fd kernel 2.4.4 patch, dynhash kernel patch papers: A scalable and explicit event delivery mechanism for UNIX [usenix99], Scalability of Linux Event-Dispatch Mecanism [Signal-per-fd], Linux Kernel Hash Table Behavior [ring buffer], Scalable Network IO in Linux.pdf [RTsig] Analyzing_the_Overload_Behavior_of_a_Simple_Web_Server[sigwaitinfo4]
Server Frameworks	실제로 Socket 서버를 제작할 때에는 UNIX Network Programming책을 보면, 여러가지 서버 모델이 나오는데, 그중에서도 가장 많이 참고하는 쪽은 concurrent socket server일 것이다. 이에 대한 구현 방식은 서버의 성격과 패킷의 송수신 형태 등에 따라, 그 구조를 어떻게 가져가느냐에 많은 관심이 있을 것이다. usenet newsgroup의 comp.programing.threads나 comp.unix.programmer 등을 검색을 해보거나 질문을 올려보면, 대부분의 답변은 다음과 같이 정리될 수 있다고 본다. 1. linux에서는 1000+의 클라이언트 처리에도 문제가 없으며, 단지 문제가 된다면, RAM의 크기이다. 2. linux의 소켓 모델은 일반적으로 multiplexing io를 사용하여, select()보다는 poll()이 다소 처리가 매끄럽고 빠르다. 3000개 동시 접속 클라이언트이내라면 이 구조를 사용하는 것이 좋다. 만약 8000+정도를 처리해야한다면 sigio를 고려해볼만 하다. 3. 처리 방식에 있어, read전용 multiplexing io 1thread와 다수개의 write전용 thread가 좀더 효율이 좋다. 4. sigio나 성능 개선된 poll()을 쓰는 것이 CPU 사용율이라던지 효율적인 리소스 사용을 위해서는 좋을 수도 있다. 하지만 linux의 /dev/poll 구현에서 버그가 있다. articles: 1000+ Client에서 고려할점, Which_is_more_faster_socket_model, How can I multiple read() with threads papers: Design Framework For highly Concurrent Systems, ACE frameworks
Other Tuning Points	Linux에서는 Beowulf Super Clustering Server 에서 사용된 channel bonding을 kernel 2.4부터는 정식으로 포함시켰다. channel bonding은 한마디로 2개의 NIC을 하나의 NIC처럼 사용하도록 하는 것이다. 그리고 2개이상의 NIC를 사용하는 경우, 강제로 IRQ를 sharing을 하도록 하면 성능이 나아진다는 설이 있는데, 이에 대한 문헌은 좀더 찾아볼 예정이다. 아래는 이 문서내에서 다루지 않은 또다른 튜닝에 관련된 사항을 다루고자한다. patches: fast socket close kernel 2.2.x patch, improved malloc patch tunning: zeus server os tunning guide articles: How many thread can I use with Linux
Patched Packages	KERNEL 2.4.5 with /dev/poll and signal-per-fd patched : 청아에서 사용된 kernel 2.4.5 tarball이다. tarball: linux-2.4.5-chonga1.tar.gz GLIBC v2.2.2 with pthread mysql tunning : MAX_PTHREAD_NUM=4096, rpm4.0 : mysql site의 linux glibc-2.2.2 patch 적용해서 다시 패키징했다. srpms: glibc-2.2.2-10.src.rpm rpms: glibc-2.2.2-10.i386.rpm, glibc-common-2.2.2-10.i386.rpm, glibc-profile-2.2.2-10.i386.rpm, glibc-devel-2.2.2-10.i386.rpm, nscd-2.2.2-10.i386.rpm
Other Links	Chuck Lever's Linux Scalability March/Aprial 2000 Status Report Usenix symposium Client 10000 project linux에서의 dummy client socket 접속 테스트

1995-2012 어린미르(email▲) · 법적알림 | MW 2367일째, WR 2110일째