tcpdump는 udp 성능을 향상시킵니다

13

다음 설정의 성능을 확인하기 위해 일련의로드 테스트를 실행하고 있습니다.

Node.js test suite (client) --> StatsD (server) --> Graphite (server)

요컨대, node.js 테스트 스위트는 x 초마다 설정된 양의 메트릭을 다른 서버에있는 StatsD 인스턴스로 보냅니다. 그런 다음 StatsD는 매초마다 동일한 서버에있는 Graphite 인스턴스로 지표를 플러시합니다. 그런 다음 테스트 스위트가 실제로 전송 한 메트릭 수와 Graphite가 얼마나 많은 메트릭을 수신하여 테스트 스위트와 Graphite 간의 패킷 손실을 확인했는지 살펴 봅니다.

그러나 때때로 20-50 % 범위의 매우 큰 패킷 드롭률 (UDP 프로토콜과 함께 전송 됨)을 얻었습니다. 따라서 StatsD의 성능 문제 일 수있는 것으로 보아이 패킷이 삭제 된 위치를 조사하기 시작했습니다. 그래서 시스템의 모든 부분에서 메트릭을 로깅하기 시작하여이 드롭이 발생한 위치를 추적했습니다. 그리고 이것은 상황이 이상 해지는 곳입니다.

내가 사용하고 는 tcpdump를 테스트 실행 완료되면 내가 검사 캡처 파일을 만들 수 있습니다. 그러나 tcpdump를 실행하여 테스트를 실행할 때마다 패킷 손실이 거의 없습니다! tcpdump가 어떻게 든 테스트의 성능을 향상시키는 것처럼 보이며 이것이 왜 그리고 어떻게 수행되는지 알 수 없습니다. 서버와 클라이언트 모두에서 tcpdump 메시지를 기록하기 위해 다음 명령을 실행하고 있습니다.

tcpdump -i any -n port 8125 -w test.cap

하나의 특정 테스트 사례에서 40000 메트릭 / s를 보냅니다. tcpdump를 실행하는 동안의 패킷 손실은 약 4 %이고 패킷 손실은 약 20 %입니다.

두 시스템 모두 다음 설정으로 Xen VM으로 실행됩니다.

Intel Xeon E5-2630 v2 @ 2.60GHz
2GB RAM
우분투 14.04 x86_64

잠재적 인 원인을 이미 확인한 것 :

UDP 버퍼 수신 / 전송 크기 늘리기
테스트에 영향을주는 CPU로드 (클라이언트와 서버 측 모두에서 최대 40-50 %의 부하)
'any'대신 특정 인터페이스에서 tcpdump를 실행합니다.
'-p'와 함께 tcpdump를 실행하여 무차별 모드를 비활성화합니다.
서버에서만 tcpdump를 실행합니다. 이로 인해 패킷 손실이 20 % 발생했으며 테스트에 영향을 미치지 않는 것 같습니다.
클라이언트에서만 tcpdump를 실행합니다. 결과적으로 성능이 향상되었습니다.
netdev_max_backlog 및 netdev_budget을 2 ^ 32-1로 증가시킵니다. 이것은 아무런 차이가 없었습니다.
모든 NIC에서 가능한 모든 무차별 모드 설정을 시도했습니다 (서버 켜기 및 클라이언트 끄기, 서버 끄기 및 클라이언트 켜기, 둘 다 켜기, 모두 끄기). 이것은 아무런 차이가 없었습니다.

— 루벤 홈스
소스

3

tcpdump가 기본적으로하는 한 가지는 네트워크 인터페이스를 무차별 모드로 설정하는 것입니다. -p차이가 있는지 확인하기 위해 옵션 을 전달 하지 않아도됩니다.

— Zoredache

따라서 클라이언트와 서버 모두에서 tcpdump를 실행 중이며 패킷 손실률이 감소합니까? 클라이언트에서만 실행하면 어떻게되며 서버에서만 실행하면 어떻게됩니까? (그리고, 그래, 또한 있는지, 오히려 "임의의"장치보다 시험에 사용되는 특정 네트워크 인터페이스에 포착하려고 아마 또한 무차별 모드를 끄면 시도하고 그 차이를 만든다.)

귀하의 의견에 감사드립니다. 나는 두 가지 권장 사항을 모두 시도하고 내가 시도한 것을 반영하기 위해 내 질문을 편집했지만 이것은 문제에 영향을 미치지 않았습니다.

— Ruben Homs

두 시스템의 nics를 무차별 모드로 설정하면 tcpdump를 실행하는 것과 동일한 효과가 있습니까? eth0에서 무차별 모드를 ifconfig eth0 promisc활성화 및 ifconfig eth0 -promisc비활성화합니다. 차이가 나면 두 시스템에서 가능한 4 가지 promisc on / off 조합을 비교해보십시오. 문제의 원인을 찾아내는 데 도움이 될 수 있습니다.

— 폭스

@Fox 답장을 보내 주셔서 감사합니다! 모든 nic에 대해 가능한 모든 조합을 시도했지만 결과에는 차이가 없습니다. 이것을 반영하기 위해 질문을 업데이트했습니다.

— Ruben Homs

10

tcpdump가 실행 중이면 들어오는 프레임을 읽을 때 상당히 프롬프트됩니다. 내 가설은 NIC의 패킷 링 버퍼 설정이 작은 크기 일 수 있다는 것입니다. tcpdump가 실행되면 더 적시에 비워집니다.

Red Hat 가입자 인 경우이 지원 문서는 패킷 수신 개요에 매우 유용합니다 . 아직 당신이 생각하지 않은 것들이 있습니다.

시스템이 IRQ를 처리하는 방법을 고려하십시오. 네트워크 인터페이스의 'dev_weight'를 늘리는 것을 고려하십시오 (NIC에서 사용자 공간으로 더 많은 패킷을 읽습니다). 응용 프로그램이 소켓을 읽는 빈도를 확인하십시오 (전용 스레드를 사용할 수 있습니까, 확장 성과 관련하여 알려진 문제 / 해결 방법이 있습니까).

NIC 프레임 버퍼 늘리기 ( ethtool 명령을--set-ring 인수 등을 보십시오 ).

'수신 측 스케일링'을보고 트래픽에서 읽을 수있는 최소한의 수신 스레드를 사용하십시오.

tcpdump가 패킷 링 버퍼에 대한 커널 지원을 사용하는 것과 같은 멋진 일을하고 있는지 궁금합니다 . 그것은 당신이보고있는 행동을 설명하는 데 도움이 될 것입니다.

— 카메론 커
소스

이 환경은 Xen 환경이므로 Xen 호스트에서 수행해야합니다 (적어도 일부는 수행해야 함).

— Cameron Kerr

이것은 내가 전에 생각하지 못했던 매우 흥미로운 것들입니다. 감사합니다! Xen 호스트에 액세스하면 시도해보고 어떻게 진행되는지 알려 드리겠습니다.

— Ruben Homs

2

어떤 전력 거버너를 사용하고 있습니까? "주문형"또는 "보수적"주지사와 유사한 행동을 보았습니다.

"성능"조정기를 사용하고 서버 BIOS에서 절전 기능을 비활성화하십시오.

뭔가 바뀌나요?

— 쇼 단쇼
소스

사용중인 전원 관리자를 찾는 데 문제가 있습니다. 나는 달리기를 시도 cpufreq-info했지만라는 메시지가 나타납니다 no or unknown cpufreq driver is active on this CPU. 또한 사용 cpupower frequency-info하면을 반환합니다 no or unknown cpufreq driver is active on this CPU. 현재로서는 확인할 수 없지만 VM 제조업체의 웹 사이트 에서 인텔 CPU를 사용하기 때문에 "성능"모드로 실행되고 있다고 생각합니다.

— Ruben Homs

다음 명령의 출력을 보여줄 수 있습니까? 1) cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor2) cat /proc/cpuinfo3)lsmod | grep cpu

— shodanshok

당신은 간다

— Ruben Homs

1

다른 방법은 ip_conntarck모듈입니다. 리눅스 박스가 새로운 연결을 받아 들일 수 있습니까? 통해 테스트 :

root@debian:/home/mohsen# sysctl net.ipv4.netfilter.ip_conntrack_max
net.ipv4.netfilter.ip_conntrack_max = 65536
root@debian:/home/mohsen# sysctl  net.ipv4.netfilter.ip_conntrack_count
net.ipv4.netfilter.ip_conntrack_count = 29

당신은 테스트해야

net.ipv4.netfilter.ip_conntrack_max >  net.ipv4.netfilter.ip_conntrack_count

max == count 인 경우 최대 연결이 가득 차서 Linux 상자에서 새 연결을 수락 할 수 없습니다.
ip_conntrack이없는 경우 다음을 통해 쉽게로드 할 수 있습니다.modprobe ip_conntrack

— 페르시아 만
소스

2

이 경우 'raw'테이블에서 NOTRACK 대상을보고 연결 추적을 방지해야합니다. 나는 최근에 바쁜 DNS 서버에 대해 그렇게했으며 병목 현상에서 iptables를 제거하고 DNS 확인 시간 초과를 유발했습니다.

— Cameron Kerr

그리고 NOTRACK 규칙을 사용하여 IPTables가 UDP DNS에 대한 연결 추적을 수행하지 않도록하는 방법의 예입니다. 산만 -it.blogspot.co.nz/2015/05/…

— 카메론 커

1

수신 측이 단순히 패킷 속도를 처리 할 수 없다고 생각하며 그 이유는 다음과 같습니다.

클라이언트에서 tcpdump 를 사용 하면 손실 된 패킷이 줄어 듭니다. tcpdump가 클라이언트 속도를 저하 시키므로 서버가 여전히 부분적으로 처리 할 수있는 훨씬 낮은 패커 속도를보고 있습니다. 클라이언트와 서버 모두에서 RX / TX 패킷 카운터를 확인하여이 가설을 확인할 수 있어야합니다.
UDP 버퍼 수신 / 전송 크기를 늘렸다는 것을 언급했습니다. 자세한 방법은 무엇입니까? 서버에서 rmem_max 와 rmem_default를 모두 변경하는 것이 중요합니다. 예를 들면 다음 과 같습니다. sysctl -w net.core.rmem_max=524287 sysctl -w net.core.wmem_max=524287 sysctl -w net.core.rmem_default=524287 sysctl -w net.core.wmem_default=524287

설정 테스트

statsd 및 노드 애플리케이션을 중지 한 후 시스템 유휴 사용 iperf 를 하여 네트워크 / 커널이 처리 할 수있는 패킷 속도를 테스트하십시오. iperf로 40K 패킷을 스트리밍 할 수 있지만 statsd로는 스트리밍 할 수 없다면 statsd 조정에 집중해야합니다.

다른 튜너 블

net.core.netdev_max_backlog : 특정 인터페이스가 커널이 처리 할 수있는 것보다 빠르게 패킷을 수신 할 때 대기열에 허용되는 최대 패킷 수 를 조정 해야합니다.

— 유 니콜 티
소스