tcp rcvpruned의 원인을 알아보세요.

tcp rcvpruned의 원인을 알아보세요.

매일 로드 밸런서에서 일부 rcv 정리된 패킷을 수신하는데 그 이유가 무엇인지 알고 싶습니다.

여기에 이미지 설명을 입력하세요.

그러나 내 tcp_mem 대 tcp_mem 사용량을 기준으로 특정 패킷이 잘리는 이유를 이해할 수 없습니다.

cat /proc/sys/net/ipv4/tcp_mem
6178080 8237440 12356160

여기에 이미지 설명을 입력하세요.

답변1

RcvPruned커널이 이 기능을 떠나기 전에 TCP MIB가 증가하여 tcp_prune_queue()패킷 손실이 발생합니다.

그렇게 하기 전에 커널은 소켓 버퍼의 데이터를 축소하려고 시도합니다(데이터를 함께 압축하고 오버헤드 삭제). 데이터는 먼저 순서가 지정되지 않은 대기열에서 잘린 다음 일반 순서가 있는 대기열에서 잘립니다.

이는 소켓이 메모리 부족 상태에 있고 소켓 버퍼가 충분히 크지 않음을 의미합니다.

당신은 위에서 이렇게 말했습니다.

net.ipv4.tcp_rmem = 183936 245248 367872

최대값은 충분히 크지 않습니다. 필요에 따라 소켓 메모리를 늘릴 수 있는 커널 공간을 제공하려면 이 값을 10배로 늘립니다. net.core.rmem_maxTCP 윈도우 어카운팅에도 사용되므로 추가됩니다 .

버퍼 크기를 어떻게 계산하는지 잘 모르겠지만, 많은 작은 패킷 트래픽(예: HTTP 요청)의 균형을 맞추는 경우 대부분의 버퍼 사용량이 오버헤드가 됩니다.

이에 대한 설명은 실행 중인 커널에 따라 다릅니다. "기존" 방법은 몇 가지 부정확한 가정을 했지만 상당히 관대하다는 것이 입증되었으며 "새로운" 방법은 정확하게 계산되었으며 이전보다 약간 더 큰 버퍼 크기가 필요했습니다.

이를 변경한 패치 세트는 주로 IIRC 컴퓨팅을 중심으로 이루어졌으며 skb->truesize커널 3.0과 3.10 사이에 언젠가 적용되었습니다.

또한 값을 확인 net.ipv4.tcp_mem하고 TCP가 사용할 수 있는 총 메모리 양을 제한하지 않는지 확인해야 합니다. 이 조정 가능한 매개변수의 측정 단위는 다음과 같습니다.페이지, 바이트가 아닙니다. 개인적으로 저는 영향을 받지 않도록 모든 값을 매우 크게 설정했습니다. 필요에 따라 추가 메모리를 구입하십시오.

관련 정보