많은 연결과 작은 패킷의 트래픽이 많은 기가비트 네트워크에서 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.