얼마나 많은 소켓 연결이 가능합니까?

얼마나 많은 소켓 연결이 가능합니까?

---

현대 표준 루트 서버에서 가능한 tcp-socket 연결 수를 아는 사람이 있습니까? (일반적으로 각 연결에 트래픽이 적지 만 모든 연결이 항상 작동해야합니다.)

편집 : 우리는 Linux 서버를 사용할 것입니다.

---

"C10K"문제에 대한 Google 주변. 이것은 기본적으로 10,000 개 이상의 동시 연결 관리에 대한 논의 및 기술입니다.

어렵 기 때문에이 숫자가 선택되었다고 생각하지만 이론적으로는 가능합니다.

---

1600k 동시 유휴 소켓 연결을 달성했으며 동시에 Linux 데스크톱 (16G RAM, I7 2600 CPU)에서 57k req / s를 달성했습니다. epoll을 사용하여 C로 작성된 단일 스레드 http 서버입니다. 소스 코드는 여기 블로그 인 github 에 있습니다 .

편집하다:

JAVA / Clojure를 사용하여 동일한 컴퓨터에서 600k 동시 HTTP 연결 (클라이언트 및 서버)을 수행했습니다. 상세 정보 게시물 , HN 토론 : http://news.ycombinator.com/item?id=5127251

연결 비용 (epoll 포함) :

• 응용 프로그램은 연결 당 약간의 RAM이 필요합니다
• TCP 버퍼 2 * 4k ~ 10k 이상
• epoll은 epoll (7)에서 파일 기술자를위한 메모리가 필요합니다.

등록 된 각 파일 설명자는 32 비트 커널에서 약 90 바이트, 64 비트 커널에서 약 160 바이트입니다.

---

이는 해당 운영 체제뿐만 아니라 구성, 잠재적으로 실시간 구성에 따라 다릅니다.

Linux의 경우 :

cat /proc/sys/fs/file-max

동시에 열 수있는 총 파일 설명 자의 현재 최대 수를 표시합니다. http://www.cs.uwaterloo.ca/~brecht/servers/openfiles.html을 확인하십시오 .

---

10,000? 70,000? 그게 다야 :)

FreeBSD는 아마도 여러분이 원하는 서버 일 것입니다. 여기에 100,000 개의 연결을 처리하도록 조정하는 것에 대한 작은 블로그 게시물 이 있습니다. 여기 에는 완료 포트 메커니즘 역할을하는 kqueue와 함께 얼마 동안 zero-copy 소켓과 같은 흥미로운 기능이 있습니다.

Solaris는 지난 세기에 100,000 개의 연결을 처리 할 수 ​​있습니다 !. 그들은 리눅스가 더 나을 것이라고 말합니다

내가 접한 가장 좋은 설명은 확장 가능한 웹 서버 작성에 대한이 프레젠테이션 / 문서입니다. 그는 그렇게 말하는 것을 두려워하지 않습니다 :)

소프트웨어도 마찬가지입니다. 응용 프로그램 레이어의 크레 틴은 OS 레이어에 큰 혁신을 가져 왔습니다. Lotus Notes는 클라이언트 당 하나의 TCP 연결을 열어두기 때문에 IBM은 Linux에 "하나의 프로세스, 100.000 개의 열린 연결"사례에 대한 주요 최적화에 기여했습니다.

그리고 O (1) 스케줄러는 원래 일부 관련없는 Java 벤치 마크에서 좋은 점수를 얻기 위해 만들어졌습니다. 결론은이 팽창이 우리 모두에게 이익이된다는 것입니다.

---

Linux에서는 비동기 I / O를 위해 epoll을 사용해야합니다. 연결 당 너무 많은 커널 공간을 낭비하지 않도록 소켓 버퍼를 미세 조정하는 것도 좋습니다.

합리적인 컴퓨터에서 10 만 개의 연결에 도달 할 수 있어야한다고 생각합니다.

---

열린 소켓 수에 대한 제한은 / proc 파일 시스템에서 구성 할 수 있습니다.

cat /proc/sys/fs/file-max

정수 제한으로 정의 된 OS에서 들어오는 연결의 최대 값입니다.

Linux 자체는 수십억 개의 오픈 소켓을 허용 합니다.

소켓을 사용하려면 웹 서버와 같은 응용 프로그램을 수신해야하며 소켓 당 일정량의 RAM을 사용합니다.

RAM과 CPU는 실제 한계를 도입합니다. (현대 2017, 수십억이 아닌 수백만을 생각하십시오)

1 백만은 가능하지만 쉽지는 않습니다. 1 백만 개의 소켓을 관리하기 위해 X 기가 바이트의 RAM을 사용할 것으로 예상됩니다.

나가는 TCP 연결은 IP 당 ~ 65000 포트 번호로 제한됩니다. 여러 IP 주소를 가질 수 있지만 무제한 IP 주소는 없습니다. 이것은 Linux가 아닌 TCP의 한계입니다.

---

응용 프로그램에 따라 다릅니다. 각 클라이언트에서 몇 개의 패키지 만있는 경우 Linux에서는 100K가 매우 쉽습니다. 우리 팀의 엔지니어가 몇 년 전에 테스트를 수행 한 결과, 연결이 설정된 후 클라이언트에서 패키지가 없으면 linux epoll이 CPU 사용량 수준이 50 % 미만인 경우 400k fd를 읽을 수 있습니다.

---

어떤 운영 체제?

Windows 머신의 경우 확장을 위해 서버를 작성하고 있으므로 I / O 완료 포트 및 비동기 I / O를 사용하는 경우 주요 제한은 각 활성 연결에 사용하는 비 페이징 풀의 양입니다. . 이는 시스템에 설치된 메모리 양을 기반으로 한 제한으로 직접 변환됩니다 (비 페이징 풀은 설치된 총 메모리를 기반으로하는 유한 한 고정 크기 양입니다).

트래픽이 많지 않은 연결의 경우 비 페이징 풀을 사용하지 않고 잠긴 페이지 제한 (잠재적으로 제한 될 수있는 다른 리소스)에 영향을주지 않는 '제로 바이트 읽기'를 게시하여 더 효율적으로 만들 수 있습니다. 많은 소켓 연결이 열려 있음).

그 외에는 프로파일 링이 필요하지만 적당히 지정된 (760MB 메모리) 서버에서 70,000 개 이상의 동시 연결을 관리했습니다. 자세한 내용은 http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html 을 참조하십시오.

분명히 '연결 당 스레드'또는 '선택'과 같은 덜 효율적인 아키텍처를 사용하는 경우 덜 인상적인 수치를 얻을 수 있습니다. 그러나 IMHO, Windows 소켓 서버에 대해 이러한 아키텍처를 선택할 이유가 없습니다.

편집 : 여기를 참조하십시오http://blogs.technet.com/markrussinovich/archive/2009/03/26/3211216.aspx ; 비 페이징 풀의 양을 계산하는 방식이 Vista 및 Server 2008에서 변경되었으며 이제 훨씬 더 많은 기능을 사용할 수 있습니다.

---

현실적으로 애플리케이션의 경우 단일 시스템에서 4000-5000 개 이상의 오픈 소켓이 비실용적입니다. 모든 소켓의 활동을 확인하고 관리하는 것만으로도 특히 실시간 환경에서 성능 문제가되기 시작합니다.

참고 URL : https://stackoverflow.com/questions/651665/how-many-socket-connections-possible