용량 계획을 세우고 있는데 메모리 관점에서 서버에서 처리 할 수있는 TCP 연결 수를 예측하는 데 사용할 수있는 공식이 있는지 궁금합니다. 현재 메모리 요구 사항에만 관심이 있습니다.
수식에 나타날 것으로 생각되는 일부 변수는 다음과 같습니다.
- sysctl
net.ipv4.tcp_wmem(최소 또는 기본값) - sysctl
net.ipv4.tcp_rmem(최소 또는 기본값) - sock, sock_common, proto 및 기타 소켓 별 데이터 구조의 크기
실제로 얼마나 많은 tcp_wmem 및 tcp_rmem이 할당되고 언제 메모리가 할당되는지 확실하지 않습니다. 소켓 생성시? 주문형?
답변
소스 코드를 수정할 수있는 경우 rusage 데이터를 사용하여 RSS를 측정하고 측정시 사용중인 TCP 연결 수를 기록하십시오.
소스 코드를 변경할 수없는 경우 top 또는 ps에서보고 한대로 네트워크 앱의 RSS를 사용하고에서 측정시 네트워크 연결 수를 확인하십시오 lsof -i.
응용 프로그램이 최대로드를 통과하는 동안 매분이 데이터를 수집하면 해당 데이터에서 RAM 사용과의 연결 수와 관련된 수식을 얻을 수 있습니다.
물론 tcp 데이터 구조는 사전에 예측 가능하고 계산 가능해야하지만, 측정 할 수있는 것, 특히 커널 RAM 사용량을 측정하려는 경우가 더 많습니다. 어쨌든 TCP 튜닝에 대한 자세한 내용 은 다음 질문을 참조하십시오 네트워크 스택에서 발생하는 상황을 명확하게 파악하는 방법
답변
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 bytes / s 또는 약 400 kbyte / s로 끝나며, 오늘날에는 실제로 속도가 느립니다. 기본 크기가 증가하면 (873800-873800 / 2 ^ 2) /0.150 = 4369000 바이트 / s 또는 약 4Mbytes / s로 최신 네트워크에 적합합니다. 발신자가 더 큰 창 크기로 구성된 경우 이것이 기본값 인 10 배 (8738000 * 0.75 / 0.150 = ~ 40Mbytes / s)까지 확장 할 수 있으며 이것이 현대 네트워크에 매우 적합합니다.
다음은 tcp_mem에 대한 기사입니다.
제거하는 것은 사용 가능한 엔드 투 엔드 대역폭과 손실에 의해 제한되지 않는 tcp 성능에 대한 인위적인 제한입니다. 따라서 업 링크를 더 효과적으로 포화시킬 수 있지만 tcp는 이것을 처리하는 데 능숙합니다.
IMO 중간 tcp_mem 값이 클수록 보안 수준이 떨어지고 연결 속도가 빨라지고 메모리 사용량이 약간 증가합니다.
다음을 사용하여 네트워크 스택을 모니터링 할 수 있습니다.
grep skbuff /proc/slabinfo
답변
David는 요청에 따라 질문에 대한 훌륭한 답변을 제공했지만 LFN을 독점적으로 사용하지 않는 한 이벤트 기반 서버에서도 TCP 버퍼는 연결 당 풋 프린트의 일부에 지나지 않습니다.
용량 계획의 경우 서버 테스트 및 메모리 사용량의 회귀 계산을 대체 할 수있는 방법은 없습니다.
