[리눅스 소켓 접속 테스트 보고] 작성: 이홍기 작성일: 2001년 4월 1일 최종 수정일: 2001년 4월 17일 문서버전: 0.1.1 ---------------------------------------------------------------------------- 1. 환경 CPU : Pentium III 450Mhz RAM : 256MB Linux kernel 2.4.2 #2 2. 서버 설정 redhet 7.0 default set 2.4.2 default kernel set (Fast Packet Socket enable: 이 테스트와 연관없음) 서버 실행전 ulimit -n 30000 실행. (as root) 2. 테스트 client: several linux machines (여러 곳에서 서버 가동후 실행) simple tcp connection client bin: sock_client (connect 간 휴지시간은 0.005초) $ ulimit -n 30000 <= 이것은 선택사항이다. $ ./sock_client 7000 <= 이것 또한 선택사항이다. ** 모두 합쳐 10000개 이상의 클라이언트 연결을 만족시키도록 했음. server: simple tcp accept server bin: sock_server (backlog는 250.. 접속시에 별다른 문제는 없었다.) $ ulimit -n 30000 $ ./sock_server ...... (system X/KDE used/killed and some-file-open exausted status) 6432 client connected ...... (system restart and re-test) 7932 client connected 3. 결론 현재 linux kernel 2.4.2에서는 ulimit 명령으로 커널 수정 없이도 기본적으로 max open files 개수를 변경함으로써 소켓 개수를 정할 수 있다. Socket Connection 자체는 메모리 공간을 거의 요구하지 않으며 생성에 의한 cpu load도 없다. 현재상태로 6000-7000개의 socket 접속을 서버에서 받아내었다. 그 이상을 try하면 error가 발생한다. 이에 대한 tuning은 좀더 해보면 10000개까지도 되겠찌만 6000개 정도라면 서비스시엔 무난하리라 본다. 따라서, 6000개의 접속은 6000개의 소켓접속이 문제가 아니라. 연결당 소유되는 클라이언트 메모리 공간의 개수 *6000이기 때문에 RAM의 공간이 어느정도 필요한 것인지 예측해야 하며, 서버의 구현 방식 에 따라, 1 process (or 1 thread) 1 client 라면, 생성 및 메모리 사용의 overhead로 인해 6000개를 접속을 받아내기 위해 고사양의 시스 템에 대한 하드웨어적인 투자가 불가피하다. 6000개 이상의 접속을 어떻게 처리하느냐에 대한 것은 앞으로의 숙제이다. *7000개 정도에서 socket 접속이 안되는 이유는 /proc/sys/kernel에 있는 file-max와 file-nr이 8000여개로 되어 있기 때문이다. 최적화를 위해선 inode개수도 적당히 바꾸어줘야한다. 이를 바꾸면 원하는 만큼(eg, 10000개이상) 얻을 수 있다.