큰 RTT를 통해 100Mbps 서버보다 1Gbps 서버에서 낮은 TCP 처리량

우리는 싱가포르, 런던, 로스 앤젤레스 등 전 세계 주요 지역에 인프라를 배포했습니다. 두 위치 사이의 RTT는> 150ms 이상입니다.

최근에 모든 서버를 업그레이드하여 100Mbps에서 1Gbps 링크를 사용했습니다. 우리는 서로 다른 위치에있는 서버간에 일부 TCP 기반 테스트를 실행했으며 놀라운 결과를 얻었습니다. 이 결과는 완전히 반복됩니다.

1. 로스 앤젤레스 (100Mbps)에서 런던 (100Mbps)까지 : ~ 96Mbps 처리량
2. 로스 앤젤레스 (100Mbps)-런던 (1Gbps) : ~ 96Mbps 처리량
3. 로스 앤젤레스 (1Gbps)-런던 (100Mbps) : 10-40Mbps 처리량 (휘발성)
4. 로스 앤젤레스 (1Gbps)-런던 (1Gbps) : 10-40Mbps 처리량 (휘발성)
5. 로스 앤젤레스 (1Gbps)-로스 앤젤레스 (1Gbps) :> 900Mbps 처리량

발신자가 1Gbps로 실행될 때마다 긴 링크에서 처리량이 매우 크게 저하되는 것으로 보입니다.

이전의 테스트 접근법은 매우 간단합니다 .cURL을 사용하여 대상 서버에서 1GB 바이너리를 다운로드하고 있습니다 (위의 경우 cURL 클라이언트는 런던 서버에서 실행되고 LA에서 다운로드되므로 LA는 발신인입니다) . 이것은 물론 단일 TCP 연결을 사용하고 있습니다.

iperf를 사용하여 UDP를 통해 동일한 테스트를 반복하면 문제가 사라집니다!

1. 로스 앤젤레스 (100Mbps)에서 런던 (100Mbps)까지 : ~ 96Mbps 처리량
2. 로스 앤젤레스 (100Mbps)-런던 (1Gbps) : ~ 96Mbps 처리량
3. 로스 앤젤레스 (1Gbps)-런던 (100Mbps) : ~ 96Mbps 처리량
4. 로스 앤젤레스 (1Gbps)-런던 (1Gbps) :> 250Mbps 처리량

이것은 내 눈에 어떤 TCP 또는 NIC / 포트 구성 문제를 직시합니다.

두 서버 모두 TCP 큐빅으로 CentOS 6.x를 실행하고 있습니다. 둘 다 최대 8MB의 TCP 보내기 및 받기 창이 있으며 TCP 타임 스탬프 및 선택적 승인이 활성화되어 있습니다. 모든 테스트 사례에서 동일한 TCP 구성이 사용됩니다. 전체 TCP 구성은 다음과 같습니다.

net.core.somaxconn = 128
net.core.xfrm_aevent_etime = 10
net.core.xfrm_aevent_rseqth = 2
net.core.xfrm_larval_drop = 1
net.core.xfrm_acq_expires = 30
net.core.wmem_max = 8388608
net.core.rmem_max = 8388608
net.core.wmem_default = 131072
net.core.rmem_default = 131072
net.core.dev_weight = 64
net.core.netdev_max_backlog = 1000
net.core.message_cost = 5
net.core.message_burst = 10
net.core.optmem_max = 20480
net.core.rps_sock_flow_entries = 0
net.core.netdev_budget = 300
net.core.warnings = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_retrans_collapse = 1
net.ipv4.tcp_syn_retries = 5
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_tw_buckets = 262144
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_retries2 = 15
net.ipv4.tcp_fin_timeout = 60
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_abort_on_overflow = 0
net.ipv4.tcp_stdurg = 0
net.ipv4.tcp_rfc1337 = 0
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_orphan_retries = 0
net.ipv4.tcp_fack = 1
net.ipv4.tcp_reordering = 3
net.ipv4.tcp_ecn = 2
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_mem = 1528512      2038016 3057024
net.ipv4.tcp_wmem = 4096        131072  8388608
net.ipv4.tcp_rmem = 4096        131072  8388608
net.ipv4.tcp_app_win = 31
net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_frto = 2
net.ipv4.tcp_frto_response = 0
net.ipv4.tcp_low_latency = 0
net.ipv4.tcp_no_metrics_save = 0
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_tso_win_divisor = 3
net.ipv4.tcp_congestion_control = cubic
net.ipv4.tcp_abc = 0
net.ipv4.tcp_mtu_probing = 0
net.ipv4.tcp_base_mss = 512
net.ipv4.tcp_workaround_signed_windows = 0
net.ipv4.tcp_dma_copybreak = 4096
net.ipv4.tcp_slow_start_after_idle = 1
net.ipv4.tcp_available_congestion_control = cubic reno
net.ipv4.tcp_allowed_congestion_control = cubic reno
net.ipv4.tcp_max_ssthresh = 0
net.ipv4.tcp_thin_linear_timeouts = 0
net.ipv4.tcp_thin_dupack = 0

일부 테스트 사례의 wireshark IO 그래프 이미지가 첨부되어 있습니다 (죄송합니다, 아직 이미지를 직접 게시 할 수는 없습니다).

테스트 사례 1 (100Mbps-> 100Mbps) -원활한 전송. 캡처 손실이 없습니다. -http : //103.imagebam.com/download/dyNftIGh-1iCFbjfMFvBQw/25498/254976014/100m.png

테스트 사례 3 ( 1Gbps- > 100Mbps) -votaile 전송, 모든 속도에 도달하는 데 시간이 오래 걸림-절대 100Mbps에 도달하지 않습니다. 그러나 캡처에서 손실 / 재전송은 없습니다! -http : //101.imagebam.com/download/KMYXHrLmN6l0Z4KbUYEZnA/25498/254976007/1g.png

요약하자면, 1Gbps 연결에 긴 링크를 사용하면 100Mbps 연결을 사용할 때보 다 TCP 처리량이 훨씬 줄어 듭니다.

TCP 전문가의 조언을 많이 부탁드립니다!

감사!

업데이트 (2013-05-29) :

위의 테스트 사례 # 4 (1Gbps 전송자, 1Gbps 수신기, 큰 RTT를 통해)와 관련된 문제를 해결했습니다. 이제 전송이 시작된 후 2 초 안에 ~ 970Mbps까지 도달 할 수 있습니다. 이 문제 는 호스팅 제공 업체에서 사용하는 스위치 인 것으로 보입니다 . 다른 것으로 이동하면 해결되었습니다.

그러나 테스트 사례 # 3은 대부분 문제가 남아 있습니다. 수신기가 100Mbps에서 실행되고 발신자가 1Gbps 인 경우, 수신기가 100Mbps에 도달 할 때까지 약 2-3 분 정도 기다립니다 (그러나 이전과 달리 전체 속도에 도달 함). 발신자를 100Mbps로 낮추거나 수신기를 1Gbps로 높이 자마자 문제가 사라지고 1 ~ 2 초 안에 최고 속도로 증가 할 수 있습니다.

근본적인 이유는 물론 이전이 시작된 직후에 손실을보고 있기 때문입니다. 그러나 이것은 느린 시작의 작동 방식에 대한 나의 이해와는 다릅니다. 인터페이스의 속도는 수신기의 ACK에 의해 제어되어야하므로 이에 영향을 미치지 않아야합니다.

감사의 말을 전하십시오! 여기에 현상금을 줄 수 있다면 나는 할 것입니다!

주요 문제는 큰 WAN 지연입니다. 임의의 패킷이 손실되면 매우 나빠질 수 있습니다.

1, tcp_mem은 더 많은 메모리를 할당하기 위해 크게 설정해야합니다. 예를 들어, net.ipv4.tcp_mem = 4643328 6191104 9286656으로 설정하십시오.

2, wireshark / tcpdump를 통해 약 몇 분 동안 패킷을 캡처 한 다음 임의의 패킷 손실이 있는지 분석 할 수 있습니다. 원하는 경우 패킷 파일을 업로드 할 수도 있습니다.

3, 당신은 다른 tcp 매개 변수를 조정하려고 할 수 있습니다. tcp_westwood = 1 및 tcp_bic = 1로 설정

해결되었습니다! 자세한 내용은 http://comments.gmane.org/gmane.linux.drivers.e1000.devel/11813을 참조하십시오 .

요컨대, 1Gbps 연결 서버는 TCP의 기하 급수적 성장 단계에서 일부 중간 장치 ( 버퍼 가 무엇인지 아는)에 버퍼를 넘치게하는 버스트를 전송하는 것으로 보입니다 . 두 가지 옵션이 남습니다.

1) 각 중간 네트워크 사업자에게 연락하여 원하는 대역폭과 RTT를 허용하도록 적절한 버퍼를 구성하십시오. 거의 없습니다! 2) 버스트를 제한하십시오.

각 TCP 흐름을 최대 100Mbps로 작동하도록 제한했습니다. 여기의 숫자는 상당히 임의적입니다. 이전 경로가 100Mbps를 처리 할 수 있고 개별 흐름에 더 이상 필요하지 않기 때문에 100Mbps를 선택했습니다 .

이것이 미래의 누군가를 돕기를 바랍니다.

iperf를 사용하여 UDP를 통해 동일한 테스트를 반복하면 문제가 사라집니다!

로스 앤젤레스 (1Gbps)-런던 (1Gbps) :> 250Mbps 처리량

문제가 사라지지 않은 것 같습니다. 패킷의 대략 75 %가 손실되고 있습니까? TCP가 항상 느리게 시작되면 평균 대역폭이 다소 낮을 수 있습니다.

Btw, 런던에서 LA, 런던에서 런던에 대한 벤치 마크가 있습니까?