“연결 수가 많고 트래픽이 적은 기가비트 네트워크를 통해 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을 해제하는시기는?
답변
네트워크 카드에 인터럽트가 너무 많아서 문제가있을 수 있습니다. 대역폭이 문제가 아닌 경우 주파수는 문제입니다.
-
네트워크 카드에서 보내기 / 받기 버퍼 켜기
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 링 버퍼에서 수신 버퍼를 높이십시오.
답변
다음은 결정적인 대답은 아니지만 몇 가지 아이디어를 분명히 제시합니다.
이것을 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 내에서 바로 폴링 스위치를 지원하지만 리눅스에는 그러한 옵션이 없습니다. 폴링을 활성화하려면 이것을 참조하십시오 . 브로드 컴은 폴링도 지원한다는 것은 좋은 소식이다.
트래픽이 대부분 작은 패킷으로 구성되어 있다는 점을 언급했기 때문에 점보 패킷 조정으로 인해 잘리지 않을 수 있습니다. 그러나 어쨌든 시도해보십시오!
답변
모든 CPU 코어에로드를 분산시켜야합니다. ‘irqbalance’를 시작하십시오.
답변
타임 스탬프가 꺼져있는 조정 목록에서 알았습니다. 그렇게하지 마십시오. 대역폭이 실제로 비싸고 사람들이 몇 바이트 / 패킷을 절약하고 싶었을 때 그것은 며칠 전의 오래된 반품입니다. 예를 들어, “CLOSE_WAIT”에있는 소켓에 도착한 패킷이 연결에 대한 오래된 패킷인지 또는 새로운 연결에 대한 새로운 패킷인지 RTT 계산에 도움이되는지 확인하기 위해 요즘 TCP 스택에서 사용됩니다. 타임 스탬프에 몇 바이트를 절약하는 것은 IPv6 주소가 추가 할 수있는 것과 비교할 수 없습니다. 타임 스탬프를 끄면 좋은 것보다 더 해 롭습니다.
타임 스탬프 해제에 대한이 권장 사항은 한 세대의 sysadmin에서 다음 세대로 계속 전달되는 후퇴입니다. 일종의 “도시 전설”의 일종.
답변
나는 이것을 제안한다 :
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 서버 및 백업 소프트웨어에서 테스트되었습니다.
답변
제 경우에는 단 하나의 tuninng 만 있습니다.
net.ipv4.tcp_timestamps = 0
사이트로드 시간이 50 % 단축 된 매우 크고 유용한 변경을 수행했습니다.