저는 용량 계획을 세우고 있는데, 서버가 처리할 수 있는 TCP 연결 수를 메모리 관점에서 예측하는 데 사용할 수 있는 공식이 있는지 알고 싶습니다. 현재는 메모리 요구 사항에만 관심이 있습니다.
수식에 나타날 것으로 생각되는 일부 변수는 다음과 같습니다.
- sysctl
net.ipv4.tcp_wmem(최소 또는 기본값) - sysctl
net.ipv4.tcp_rmem(최소 또는 기본값) - sock, sock_common, proto 및 기타 소켓별 데이터 구조의 크기입니다.
tcp_wmem과 tcp_rmem이 실제로 얼마나 할당되었는지, 해당 메모리가 언제 할당되었는지 잘 모르겠습니다. 소켓 생성시? 요청에 따라?
답변1
tcp_mem은 tcp 스택이 메모리 사용량 측면에서 동작하는 방식을 정의하기 때문에 더 중요합니다. IMO 송신 및 수신 버퍼는 tcp_mem의 배수여야 합니다. 다음은 수신 버퍼 공식에 대한 링크입니다.http://www.acc.umu.se/~maswan/linux-netperf.txt. 간단히 말해서:
오버헤드는 window/2^tcp_adv_win_scale(tcp_adv_win_scale 기본값은 2)입니다. 따라서 Linux 수신 창(tcp_rmem)의 기본 매개변수는 87380 - (87380 / 2^2) = 65536입니다. 대서양 횡단 링크(150ms RTT)가 주어지면 최대 성능은 65536/0.150 = 436906바이트/초 또는 약 400kbyte/s가 되는데, 이는 오늘날 매우 느립니다. 기본 크기가 증가하면: (873800 - 873800/2^2)/0.150 = 4369000바이트/초 또는 약 4MB/초이며 이는 최신 네트워크에 적합합니다. 이것이 기본값이며, 발신자가 더 큰 창 크기로 구성되면 10배(8738000*0.75/0.150 = ~40Mbytes/s)로 확장되어 최신 네트워크에 적합합니다.
다음은 기사에 나온 tcp_mem에 대한 내용입니다.
제거하는 것은 TCP 성능에 대한 인위적인 제한이며, 이 제한이 없으면 사용 가능한 종단 간 대역폭 및 손실로 인해 제한됩니다. 따라서 업링크를 보다 효율적으로 포화시킬 수 있지만 tcp는 이를 처리하는 데 능숙합니다.
제 생각에는 중간 tcp_mem 값이 클수록 연결이 더 빨라지지만 보안이 저하되고 메모리 사용량이 약간 증가합니다.
다음을 사용하여 네트워크 스택을 모니터링할 수 있습니다.
grep skbuff /proc/slabinfo
답변2
소스코드를 수정할 수 있다면 rusage 데이터를 이용해 RSS를 측정하고 측정 당시 사용 중인 TCP 연결 수를 기록해 보세요.
소스 코드를 변경할 수 없는 경우 top 또는 ps에서 보고한 웹 애플리케이션의 RSS를 사용하여 측정 당시의 네트워크 연결 수를 가져옵니다 lsof -i.
이 데이터는 애플리케이션에 최대 부하가 발생할 때 매분 수집되며, 이 데이터를 기반으로 연결 수와 RAM 사용량을 연결하는 공식을 생각해 낼 수 있습니다.
물론 측정할 수 있는 것이 훨씬 더 많습니다. 특히 tcp 데이터 구조는 미리 예측 가능하고 계산되어야 하지만 커널 RAM 사용량을 측정하고 싶을 수도 있습니다. 아무튼 이 질문 좀 보세요https://serverfault.com/questions/10852/what-limits-the-maximum-number-of-connections-on-a-linux-serverTCP 튜닝에 대한 자세한 정보와 네트워크 스택에서 무슨 일이 일어나고 있는지 명확하게 이해하는 방법.
답변3
David는 질문에 대해 매우 좋은 답변을 제공했지만 특별히 사용하지 않는 한LFN, 이벤트 기반 서버에서도 TCP 버퍼는 각 연결이 차지하는 공간의 작은 부분일 수 있습니다.
용량 계획의 경우 테스트 서버 및 컴퓨팅 로드 메모리 사용량 회귀를 대체할 수 있는 방법은 없습니다.