많은 연결과 작은 패킷의 트래픽이 많은 기가비트 네트워크에서 TCP 성능 향상


37

“연결 수가 많고 트래픽이 적은 기가비트 네트워크를 통해 TCP 처리량을 향상 시키려고합니다. 내 서버 OS는 Ubuntu 11.10 Server 64bit입니다.

TCP 소켓 (모두 동일한 포트에 있음)을 통해 약 50.000 (및 증가하는) 클라이언트가 서버에 연결되어 있습니다.

패킷의 95 %는 1-150 바이트 (TCP 헤더 및 페이로드) 크기입니다. 나머지 5 %는 150에서 4096+ 바이트까지 다양합니다.

아래 구성을 사용하면 서버에서 최대 30Mbps (전이중)의 트래픽을 처리 할 수 ​​있습니다.

내 요구에 맞게 OS를 조정하는 데 도움이되는 조언을 해줄 수 있습니까?

/etc/sysctl.cong모습은 다음과 같습니다.

kernel.pid_max = 1000000
net.ipv4.ip_local_port_range = 2500 65000
fs.file-max = 1000000
#
net.core.netdev_max_backlog=3000
net.ipv4.tcp_sack=0
#
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.somaxconn = 2048
#
net.ipv4.tcp_rmem = 4096 87380 16777216 
net.ipv4.tcp_wmem = 4096 65536 16777216
#
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_mem = 50576   64768   98152
#
net.core.wmem_default = 65536
net.core.rmem_default = 65536
net.ipv4.tcp_window_scaling=1
#
net.ipv4.tcp_mem= 98304 131072 196608
#
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_rfc1337 = 1
net.ipv4.ip_forward = 0
net.ipv4.tcp_congestion_control=cubic
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
#
net.ipv4.tcp_orphan_retries = 1
net.ipv4.tcp_fin_timeout = 25
net.ipv4.tcp_max_orphans = 8192

내 한계는 다음과 같습니다.

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 193045
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1000000
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1000000

[추가]

내 NIC는 다음과 같습니다.

$ dmesg | grep Broad
[    2.473081] Broadcom NetXtreme II 5771x 10Gigabit Ethernet Driver bnx2x 1.62.12-0 (2011/03/20)
[    2.477808] bnx2x 0000:02:00.0: eth0: Broadcom NetXtreme II BCM57711E XGb (A0) PCI-E x4 5GHz (Gen2) found at mem fb000000, IRQ 28, node addr d8:d3:85:bd:23:08
[    2.482556] bnx2x 0000:02:00.1: eth1: Broadcom NetXtreme II BCM57711E XGb (A0) PCI-E x4 5GHz (Gen2) found at mem fa000000, IRQ 40, node addr d8:d3:85:bd:23:0c

[추가 2]

ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: on
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off

[추가 3]

 sudo ethtool -S eth0|grep -vw 0
 NIC statistics:
      [1]: rx_bytes: 17521104292
      [1]: rx_ucast_packets: 118326392
      [1]: tx_bytes: 35351475694
      [1]: tx_ucast_packets: 191723897
      [2]: rx_bytes: 16569945203
      [2]: rx_ucast_packets: 114055437
      [2]: tx_bytes: 36748975961
      [2]: tx_ucast_packets: 194800859
      [3]: rx_bytes: 16222309010
      [3]: rx_ucast_packets: 109397802
      [3]: tx_bytes: 36034786682
      [3]: tx_ucast_packets: 198238209
      [4]: rx_bytes: 14884911384
      [4]: rx_ucast_packets: 104081414
      [4]: rx_discards: 5828
      [4]: rx_csum_offload_errors: 1
      [4]: tx_bytes: 35663361789
      [4]: tx_ucast_packets: 194024824
      [5]: rx_bytes: 16465075461
      [5]: rx_ucast_packets: 110637200
      [5]: tx_bytes: 43720432434
      [5]: tx_ucast_packets: 202041894
      [6]: rx_bytes: 16788706505
      [6]: rx_ucast_packets: 113123182
      [6]: tx_bytes: 38443961940
      [6]: tx_ucast_packets: 202415075
      [7]: rx_bytes: 16287423304
      [7]: rx_ucast_packets: 110369475
      [7]: rx_csum_offload_errors: 1
      [7]: tx_bytes: 35104168638
      [7]: tx_ucast_packets: 184905201
      [8]: rx_bytes: 12689721791
      [8]: rx_ucast_packets: 87616037
      [8]: rx_discards: 2638
      [8]: tx_bytes: 36133395431
      [8]: tx_ucast_packets: 196547264
      [9]: rx_bytes: 15007548011
      [9]: rx_ucast_packets: 98183525
      [9]: rx_csum_offload_errors: 1
      [9]: tx_bytes: 34871314517
      [9]: tx_ucast_packets: 188532637
      [9]: tx_mcast_packets: 12
      [10]: rx_bytes: 12112044826
      [10]: rx_ucast_packets: 84335465
      [10]: rx_discards: 2494
      [10]: tx_bytes: 36562151913
      [10]: tx_ucast_packets: 195658548
      [11]: rx_bytes: 12873153712
      [11]: rx_ucast_packets: 89305791
      [11]: rx_discards: 2990
      [11]: tx_bytes: 36348541675
      [11]: tx_ucast_packets: 194155226
      [12]: rx_bytes: 12768100958
      [12]: rx_ucast_packets: 89350917
      [12]: rx_discards: 2667
      [12]: tx_bytes: 35730240389
      [12]: tx_ucast_packets: 192254480
      [13]: rx_bytes: 14533227468
      [13]: rx_ucast_packets: 98139795
      [13]: tx_bytes: 35954232494
      [13]: tx_ucast_packets: 194573612
      [13]: tx_bcast_packets: 2
      [14]: rx_bytes: 13258647069
      [14]: rx_ucast_packets: 92856762
      [14]: rx_discards: 3509
      [14]: rx_csum_offload_errors: 1
      [14]: tx_bytes: 35663586641
      [14]: tx_ucast_packets: 189661305
      rx_bytes: 226125043936
      rx_ucast_packets: 1536428109
      rx_bcast_packets: 351
      rx_discards: 20126
      rx_filtered_packets: 8694
      rx_csum_offload_errors: 11
      tx_bytes: 548442367057
      tx_ucast_packets: 2915571846
      tx_mcast_packets: 12
      tx_bcast_packets: 2
      tx_64_byte_packets: 35417154
      tx_65_to_127_byte_packets: 2006984660
      tx_128_to_255_byte_packets: 373733514
      tx_256_to_511_byte_packets: 378121090
      tx_512_to_1023_byte_packets: 77643490
      tx_1024_to_1522_byte_packets: 43669214
      tx_pause_frames: 228

SACK에 대한 정보 : TCP SACK을 해제하는시기는?


1
도움이 될 수 있습니다 : datatag.web.cern.ch/datatag/howto/tcp.html
yrk

제한 요인은 무엇입니까? CPU가 최대가 되나요? 그렇다면 잘못된 나무를 짖는 것입니다. CPU가 무엇을하고 있는지 확인해야합니다.
David Schwartz 2012

어떤 NIC가 있습니까?
SaveTheRbtz

1
BTW : 왜 SACK을 해제합니까?
Nils

1
당신은 ... 브로드 NIC를 사용하여 재고해야
휴 버트 Kario에게

답변:


21

네트워크 카드에 인터럽트가 너무 많아서 문제가있을 수 있습니다. 대역폭이 문제가 아닌 경우 주파수는 문제입니다.

  • 네트워크 카드에서 보내기 / 받기 버퍼 켜기

    ethtool -g eth0
    

현재 설정 (256 또는 512 개 항목)을 표시합니다. 아마도 1024, 2048 또는 3172로 올릴 수 있습니다. 더 말이되지 않습니다. 이것은 서버가 들어오는 패킷을 충분히 빨리 처리 할 수없는 경우에만 채워지는 링 버퍼입니다.

버퍼가 채워지기 시작하면 흐름 제어는 라우터에게 알리거나 속도를 낮추도록하는 추가 수단입니다.

  • 서버와 서버에 연결된 스위치 / 라우터 포트에서 흐름 제어를 켜거나 끕니다.

    ethtool -a eth0
    

아마 보여줄 것입니다 :

Pause parameters for eth0:
Autonegotiate:  on
RX:             on
TX:             on

eth0의 현재 설정에 대해 / var / log / messages를 확인하십시오. 다음과 같은 것을 확인하십시오.

eth0 : 링크가 1000Mbps, 전이중, 흐름 제어 tx 및 rx에서 작동

tx 및 rx가 표시되지 않으면 네트워크 관리자가 스위치 / 라우터의 값을 조정해야합니다. 수신 / 전송 흐름 제어가 설정된 Cisco에서.

주의 : 이 값을 변경하면 링크가 아주 짧은 시간 (1 초 미만) 동안 작동 중지됩니다.

  • 이 모든 것이 도움이되지 않으면 네트워크 카드의 속도를 100MBit로 낮출 수도 있습니다 (스위치 / 라우터 포트에서 동일하게 수행).

    ethtool -s eth0 autoneg off && ethtool -s eth0 speed 100
    

그러나 귀하의 경우에는 NIC 링 버퍼에서 수신 버퍼를 높이십시오.


ethtool내가 말한 번호를 보면 RX 폐기를 피하기 위해 네트워크 카드의 수신 버퍼를 최대로 설정하십시오. Broadcom에 충분한 정보가 있기를 바랍니다.
Nils

1
TCP로 버퍼링을 늘리는 것은 거의 좋은 생각이 아닙니다. 우리는 너무 많은 이미 버퍼링 한 : bufferbloat.net/projects/bloat/wiki/Introduction을
rmalayter

3
이 버퍼는 NIC의 하드웨어 버퍼입니다. 자세한 내용으로 답변을 업데이트하겠습니다. 들어오는 패킷을 잃어 버렸으므로 해당 버퍼가 필요합니다. 이러한 버퍼를 증가시키기 위해 다른 서버 (Broadcom에서 PCIe Intel로)로 전환해야하는 비슷한 서버가 있습니다. 그 후 나는 더 이상 RX 패킷을 잃어 버리지 않았습니다.
Nils

@malayter : 이것은 레이어 2의 링 버퍼입니다. 업데이트 된 답변을 참조하십시오.
Nils

1
마지막으로 1GB가 있습니다. 여러 곳에서 많은 튜닝이 있었기 때문에 실제로 단일 문제가 있다고 말할 수는 없습니다.
노동자

5

다음은 결정적인 대답은 아니지만 몇 가지 아이디어를 분명히 제시합니다.

이것을 sysctl.conf에 추가하십시오

##  tcp selective acknowledgements. 
net.ipv4.tcp_sack = 1
##enable window scaling
net.ipv4.tcp_window_scaling = 1
##
net.ipv4.tcp_no_metrics_save = 1

선택적 tcp ack은 고 대역폭 네트워크의 경우 최적의 성능에 적합합니다. 그러나 다른 단점을 조심하십시오 . 창 스케일링의 이점은 여기 에 설명되어 있습니다 . 세 번째 sysctl 옵션의 경우 : 기본적으로 TCP는 연결이 닫힐 때 다양한 연결 메트릭을 라우트 캐시에 저장하므로 가까운 미래에 설정된 연결에서이를 사용하여 초기 조건을 설정할 수 있습니다. 일반적으로 전체 성능이 향상되지만 성능이 저하 될 수 있습니다. 설정하면 TCP는 연결을 닫을 때 메트릭을 캐시하지 않습니다.

확인

ethtool -k ethX

오프로드가 활성화되어 있는지 확인하십시오. TCP 체크섬 오프로드 및 대규모 세그먼트 오프로드는 오늘날 대부분의 이더넷 NIC에서 지원되며 Broadcom 에서도 지원합니다.

도구를 사용해보십시오

powertop

네트워크가 유휴 상태이고 네트워크 포화 상태에 도달 한 경우. NIC 인터럽트가 원인인지 확실하게 보여줍니다. 장치 폴링은 이러한 상황에 대한 해답입니다. FreeBsd는 ifconfig 내에서 바로 폴링 스위치를 지원하지만 리눅스에는 그러한 옵션이 없습니다. 폴링을 활성화하려면 이것을 참조하십시오 . 브로드 컴은 폴링도 지원한다는 것은 좋은 소식이다.

트래픽이 대부분 작은 패킷으로 구성되어 있다는 점을 언급했기 때문에 점보 패킷 조정으로 인해 잘리지 않을 있습니다. 그러나 어쨌든 시도해보십시오!


2kaji, 나는 당신에게 내일 제안을 시도 할 것입니다. PowerTop 정보-목표가 성능 인 경우 절전을 조정해야합니까?
노동자

물론 도움이 될 수도 있습니다. 인터럽트가 악한 지 확인하기 위해 powertop을 언급했습니다. 다른 도구에서 인터럽트 빈도를 수집 할 수도 있습니다
kaji

높은 "재 예약 일정"이 표시됩니다. 이유가 될 수 있습니까? "일정 예약 중단"이란 무엇입니까?
작업자


예 ..이 튜토리얼을 보았지만 서버에서 인터럽트가 많이 발생하는 동안 랩톱 용입니다. 서버에 적용하려고합니다.
노동자

2

모든 CPU 코어에로드를 분산시켜야합니다. 'irqbalance'를 시작하십시오.


1
단일 IRQ의 freuency가 매우 높은 경우에는 도움이되지 않습니다. IRQBalance는 논리 프로세서에 적합한 단일 IRQ를 배포하려고하지만 단일 IRQ를 제공하는 프로세서는 두 개 이상이 될 수 없습니다.
Nils

2

타임 스탬프가 꺼져있는 조정 목록에서 알았습니다. 그렇게하지 마십시오. 대역폭이 실제로 비싸고 사람들이 몇 바이트 / 패킷을 절약하고 싶었을 때 그것은 며칠 전의 오래된 반품입니다. 예를 들어, "CLOSE_WAIT"에있는 소켓에 도착한 패킷이 연결에 대한 오래된 패킷인지 또는 새로운 연결에 대한 새로운 패킷인지 RTT 계산에 도움이되는지 확인하기 위해 요즘 TCP 스택에서 사용됩니다. 타임 스탬프에 몇 바이트를 절약하는 것은 IPv6 주소가 추가 할 수있는 것과 비교할 수 없습니다. 타임 스탬프를 끄면 좋은 것보다 더 해 롭습니다.

타임 스탬프 해제에 대한이 권장 사항은 한 세대의 sysadmin에서 다음 세대로 계속 전달되는 후퇴입니다. 일종의 "도시 전설"의 일종.


2

나는 이것을 제안한다 :

kernel.sem = 350 358400 64 1024
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 4194304
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_rmem = 4096 262144 4194304
net.ipv4.tcp_wmem = 4096 262144 4194304
net.ipv4.tcp_keepalive_time = 900
net.ipv4.tcp_keepalive_intvl = 900
net.ipv4.tcp_keepalive_probes = 9

RHEL의 Oracle DB 서버 및 백업 소프트웨어에서 테스트되었습니다.


5
이 숫자는 모든 크기에 적합하지 않기 때문에 구성 할 수 있습니다. 그것은 숫자 자체가 가치가 없다는 것을 의미합니다. 유용한 것은 사용할 숫자를 결정하는 데 사용한 방법입니다.
kasperd

2

제 경우에는 단 하나의 tuninng 만 있습니다.

net.ipv4.tcp_timestamps = 0

사이트로드 시간이 50 % 단축 된 매우 크고 유용한 변경을 수행했습니다.


그렇게하려면 설정에서 무언가가 심각하게 깨져 있어야합니다. 타임 스탬프는 일반적인 상황에서 대역폭의 1 % 미만을 사용하며 TCP가 다른 것보다 훨씬 더 긴밀하게 재전송 할 수 있도록합니다.
kasperd
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.