엠브리오 2015-03

여러대의 컴퓨터로 분산시키는게 답입니다.

김윤술 2015-03

리눅스나 윈도우나 OS가 받을수 있는 소켓 세션은 정해졌습니다. 결국 NLB로 분산을 시켜야 됩니다.

전설속의미… 2015-03

그럼, CPU 및 램 사양등이 많이 좋아져도..
  하드웨어가 좋아 지는 것 만큰 최대 TCP 수용량이 늘어 나는 것이 아니라,
  일정 부분에 수렴하면... 더이상 TCP 클라이언트를 수용 못하는 건지 궁금합니다.
  실제로 어느 정도까지가 한계인지 궁금합니다.

두 분의 답변 감사 드립니다. 꾸벅

김윤술 2015-03

1~1024 (서비스가 주로 사용하는 포트)
1024~65535 (서비스를 받고 세션을 맺고 통신을 하는 쓰레드 할당 포트)
보통 위 기준으로 소켓범위를 잡고 개발을 합니다. 개발을 발로 하면 위 기준 다 무시하고 세션이 재 할당되지도 않고 다 차서 리부팅하는 케이스가 종종 발생하는데 이거 전부 개발 잘못입니다. OS에서 백날 튜닝해봐야 근본원인이 잘못된걸 아무리 해결해도 되지가 않는다는겁니다.
소켓통신은 치고 빠지는구현을 제대로 개발해야 되는데 이거 무시되면 하드웨어 성능이 부족하다느니 OS 버그라느니 이상한 소리가 오고 가는겁니다.
TCP는 랜덤으로 세션을 맺고 풀어지고 하는데 이게 잘안된다면 개발쪽에 먼저 의심을 해봐야 하고 어느정도 세션이 차면 OS 부하도 같이 올라가기 때문에 성능의 이슈로 결론이 나면 댓수를 늘리는 방법밖에 없습니다.
소켓통신도 쓰레드를 단독이냐 멀티냐 인증세션은 어떻게 할거냐에따라 상당히 복잡해집니다. 그래서 어느정도 이상에서는 접속을 받지 않는다고 한다면 댓수 늘리는게 제일 편하다는겁니다.

전설속의미… 2015-03

해당 사유로 port re-use, tcp time-wait등 TCP 포트 재사용을 원할히 할 수 있도록 구성은 하였습니다.
혹시 웹서버 같이 TCP 소켓을 극도로 많이 사용 서버들이 소켓 문제를 해결하기 위한
sysctl.conf 와 같은 환경 설정 튜닝된 사이트나 글을 모아둔 곳 아시면, 소개 부탁 드립니다.

좋은 주말 되세요....

김동수P 2015-03

소켓 수가 아니라 file descriptors 문제일 가능성이 높습니다.
뭘로 구현되어 있나요? select? poll? epoll?
이미 소켓 수가 문제가 되는 시절은 지나간것 같습니다.
개발하기에 따라서 i7-2600, 16g ram 정도의 사양으로 idle conn은 1500k 정도, throughput 은 50k req/s까지 성능이 나옵니다. (epoll 기준..)
포트 65535 문제는, 머신의 문제가 아니라, nic에 ip여러개 할당하고, ip당 40~50k 씩 잘라서 받으면 되는 문제입니다.

전설속의미… 2015-03

네.. 제가 진적 짝 코드는 아니구 인도 개발자가 준 바이너리로 테스트 중 인 상태 입니다. 에구
말씀 해 주신 거 읽어 보니, 문제가 명확해 지는 거 같네요
리눅스 TCP 스택 문제는 아닌 거 같네

FD 문제인지는 어케 접근 해 볼만한 CLI 난 방법을 여쭈어 볼 수 있을런지요 ?

답변 거듭 감사드립니다.