☰

UDP 수신 버퍼 오류

tag-icon • tag-icon linux performance udp
UDP 수신 버퍼 오류

UDP 프로토콜을 사용하는 트래픽이 많은 환경에서 opensips SIP 프록시를 실행하고 있습니다. 때때로 RX인터페이스에 버그나 오버플로 오류가 표시됩니다. 설정했지만 rmem_max to 16M여전히 오류가 표시됩니다. 이것이 netstat에 표시되는 것입니다. 이 오류를 해결하는 방법을 아시나요?

우리 시스템에는 40개의 CPU와 64GB의 메모리가 있으므로 이는 리소스 문제가 아닙니다.

또 다른 점은 tcpdump를 실행하고 모든 SIP 트래픽을 캡처한다는 것입니다. tcpdump그것이 이 문제의 원인이라고 생각하시나요 ?

네트워크 통계-su

Udp:
    27979570 packets received
    2727 packets to unknown port received.
    724419 packet receive errors
    41731936 packets sent
    322 receive buffer errors
    0 send buffer errors
    InCsumErrors: 55

물방울 관찰-l kas

846 drops at tpacket_rcv+5f (0xffffffff815e46ff)
3 drops at tpacket_rcv+5f (0xffffffff815e46ff)
4 drops at unix_stream_connect+2ca (0xffffffff815a388a)
552 drops at tpacket_rcv+5f (0xffffffff815e46ff)
503 drops at tpacket_rcv+5f (0xffffffff815e46ff)
4 drops at unix_stream_connect+2ca (0xffffffff815a388a)
1557 drops at tpacket_rcv+5f (0xffffffff815e46ff)
6 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1203 drops at tpacket_rcv+5f (0xffffffff815e46ff)
2051 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1940 drops at tpacket_rcv+5f (0xffffffff815e46ff)
541 drops at tpacket_rcv+5f (0xffffffff815e46ff)
221 drops at tpacket_rcv+5f (0xffffffff815e46ff)
745 drops at tpacket_rcv+5f (0xffffffff815e46ff)
389 drops at tpacket_rcv+5f (0xffffffff815e46ff)
568 drops at tpacket_rcv+5f (0xffffffff815e46ff)
651 drops at tpacket_rcv+5f (0xffffffff815e46ff)
622 drops at tpacket_rcv+5f (0xffffffff815e46ff)
377 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1 drops at tcp_rcv_state_process+1b0 (0xffffffff81550f70)
577 drops at tpacket_rcv+5f (0xffffffff815e46ff)
9 drops at tpacket_rcv+5f (0xffffffff815e46ff)
135 drops at tpacket_rcv+5f (0xffffffff815e46ff)
217 drops at tpacket_rcv+5f (0xffffffff815e46ff)
358 drops at tpacket_rcv+5f (0xffffffff815e46ff)
211 drops at tpacket_rcv+5f (0xffffffff815e46ff)
337 drops at tpacket_rcv+5f (0xffffffff815e46ff)
54 drops at tpacket_rcv+5f (0xffffffff815e46ff)
105 drops at tpacket_rcv+5f (0xffffffff815e46ff)
27 drops at tpacket_rcv+5f (0xffffffff815e46ff)
42 drops at tpacket_rcv+5f (0xffffffff815e46ff)
249 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1080 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1932 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1476 drops at tpacket_rcv+5f (0xffffffff815e46ff)
681 drops at tpacket_rcv+5f (0xffffffff815e46ff)
840 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1076 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1021 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1 drops at tcp_rcv_state_process+1b0 (0xffffffff81550f70)
294 drops at tpacket_rcv+5f (0xffffffff815e46ff)
186 drops at tpacket_rcv+5f (0xffffffff815e46ff)
313 drops at tpacket_rcv+5f (0xffffffff815e46ff)
257 drops at tpacket_rcv+5f (0xffffffff815e46ff)
132 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1 drops at tcp_rcv_state_process+1b0 (0xffffffff81550f70)
343 drops at tpacket_rcv+5f (0xffffffff815e46ff)
282 drops at tpacket_rcv+5f (0xffffffff815e46ff)
191 drops at tpacket_rcv+5f (0xffffffff815e46ff)
303 drops at tpacket_rcv+5f (0xffffffff815e46ff)
96 drops at tpacket_rcv+5f (0xffffffff815e46ff)
223 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1 drops at tcp_rcv_state_process+1b0 (0xffffffff81550f70)
183 drops at tpacket_rcv+5f (0xffffffff815e46ff)

답변1

찾기 tpacket_rcv: 에서 tcpdump를 나타냅니다 af_packet.c. AF_PACKET

다른 사람들이 tcpdump에 의해 발생한 문제를 보았지만 해결하지 못한 것 같습니다.https://groups.google.com/forum/#!msg/mechanical-sympathy/qLqYTouygTE/rq9XSBxgqiMJ

하지만 tpacket_rcv의 손실이 의심스럽습니다. 아마도 이것은 label 을 통해 함수를 종료하는 것을 의미합니다 ring_is_full. 버퍼 오버플로로 인해 패킷이 tcpdump에 도달하지 못하는 것 같습니다. 그러나 이것이 패킷이 (반드시) 완전히 삭제되었음을 의미하지는 않습니다. 여전히 UDP 소켓에 도달할 수 있습니다. 이는 드롭워치 레코드가 카운터에 표시된 UDP 드롭을 다루지 않음을 나타냅니다. 나는 AF_PACKET이 둘 다 데이터그램 소켓이기 때문에 UDP 삭제로 간주되지 않는다고 생각합니다. 안타깝게도 이러한 내용 tp_drops은 표시되지 않는 것 같습니다 netstat.

나는 dropwatch를 실행하고 tpacket_rcv 행을 필터링하고 싶습니다 grep -v. UDP 수신 오류 카운터가 증가하는 것을 볼 때까지 기다리십시오.

rmem_maxUDP의 경우 애플리케이션이 수신 버퍼를 늘리려고 시도하는 경우에만 도움이 된다고 생각합니다 . "opensips rmem"에 대한 실제 검색결과가 없습니다. 을 올려보도록 하겠습니다 rmem_default. 하지만 그것이 문제라면 "수신 버퍼 오류"로 표시되었으면 좋겠습니다.

그러나 UDP 체크섬 오류도 아닙니다.

라는 또 다른 조정 가능 매개변수가 있습니다 netdev_max_backlog. 당연히 해당 오버플로 카운터는 두 번째 열 /proc/net/softnet_stat(CPU당 한 행)입니다. 그러나 이는 패킷이 UDP 스택에 공급되기 전에 발생하므로 UDP 통계에 영향을 주어서는 안 됩니다.

앗, 지금 생각나는 건 그게 전부입니다. 좀 이상하네요. :(.

편집하다:

높은 pps 속도를 처리하기 위해 더 작은 SIP 프록시 서버 관련 버퍼 크기 설정이 있습니다. 조정 후에 우리는 좋은 결과를 보았습니다. 방울이 있지만 양이 매우 적습니다. ——사티쉬

관련 정보