Cải thiện hiệu suất TCP qua mạng gigabit với nhiều kết nối và lưu lượng lớn các gói nhỏ

Tôi đang cố gắng cải thiện lưu lượng TCP của mình qua mạng gigabit có nhiều kết nối và lưu lượng lớn các gói nhỏ. Hệ điều hành máy chủ của tôi là Ubuntu 11.10 Server 64 bit.

Có khoảng 50.000 khách hàng (và đang phát triển) được kết nối với máy chủ của tôi thông qua TCP Sockets (tất cả trên cùng một cổng).

95% các gói của tôi có kích thước 1-150 byte (tiêu đề và tải trọng TCP). 5% còn lại thay đổi từ 150 đến 4096 byte.

Với cấu hình bên dưới, máy chủ của tôi có thể xử lý lưu lượng lên tới 30 Mbps (song công hoàn toàn).

Bạn có thể vui lòng tư vấn thực hành tốt nhất để điều chỉnh hệ điều hành cho nhu cầu của tôi?

Tôi /etc/sysctl.congtrông như thế này:

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

Dưới đây là giới hạn của tôi:

$ 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

[THÊM]

Các NIC của tôi như sau:

$ 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

[THÊM 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

[THÊM 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

Một số thông tin về SACK: Khi nào tắt TCP SACK?

Vấn đề có thể là bạn đang nhận quá nhiều gián đoạn trên card mạng. Nếu Băng thông không phải là vấn đề, tần số là vấn đề:

• Bật bộ đệm gửi / nhận trên thẻ mạng

  ethtool -g eth0
  

Sẽ hiển thị cho bạn các cài đặt hiện tại (256 hoặc 512 mục). Bạn có thể có thể nâng những thứ này lên 1024, 2048 hoặc 3172. Nhiều hơn có lẽ không có ý nghĩa. Đây chỉ là bộ đệm vòng chỉ lấp đầy nếu máy chủ không thể xử lý các gói đến đủ nhanh.

Nếu bộ đệm bắt đầu lấp đầy, điều khiển luồng là một phương tiện bổ sung để báo cho bộ định tuyến hoặc chuyển sang làm chậm:

• Bật điều khiển luồng vào / ra trên máy chủ và các cổng chuyển đổi / bộ định tuyến được gắn vào.

  ethtool -a eth0
  

Có thể sẽ hiển thị:

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

Kiểm tra / var / log / message cho cài đặt hiện tại của eth0. Kiểm tra một cái gì đó như:

eth0: Liên kết tăng lên 1000 Mbps, song công hoàn toàn, kiểm soát luồng tx và rx

Nếu bạn không thấy tx và rx, quản trị viên mạng của bạn phải điều chỉnh các giá trị trên switch / bộ định tuyến. Trên Cisco đó là nhận / truyền điều khiển luồng trên.

Chú ý: Thay đổi các Giá trị này sẽ đưa liên kết của bạn xuống và lên trong một thời gian rất ngắn (dưới 1 giây).

• Nếu tất cả điều này không giúp được gì - bạn cũng có thể hạ tốc độ của card mạng xuống 100 MBit (thực hiện tương tự trên các cổng chuyển đổi / bộ định tuyến)

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

Nhưng trong trường hợp của bạn, tôi sẽ nói - nâng cao bộ đệm nhận trong bộ đệm vòng NIC.

Theo sau có thể không phải là câu trả lời dứt khoát nhưng nó chắc chắn sẽ đưa ra một số ý tưởng

Hãy thử thêm chúng vào 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

Trong khi tcp ack chọn lọc là tốt cho hiệu suất tối ưu trong trường hợp mạng băng thông cao. Nhưng hãy cẩn thận với những hạn chế khác mặc dù. Lợi ích của việc mở rộng cửa sổ được mô tả ở đây . Đối với tùy chọn sysctl thứ ba: Theo mặc định, TCP lưu các số liệu kết nối khác nhau trong bộ đệm tuyến khi đóng kết nối, để các kết nối được thiết lập trong tương lai gần có thể sử dụng các số liệu này để đặt các điều kiện ban đầu. Thông thường, điều này làm tăng hiệu suất tổng thể, nhưng đôi khi có thể gây suy giảm hiệu suất. Nếu được đặt, TCP sẽ không lưu trữ số liệu trên các kết nối đóng.

Kiểm tra với

ethtool -k ethX

để xem giảm tải có được kích hoạt hay không. Giảm tải tổng kiểm tra TCP và giảm tải phân khúc lớn được hỗ trợ bởi phần lớn các Ethernet Ethernet hiện nay và dường như Broadcom cũng hỗ trợ nó.

Hãy thử sử dụng công cụ

powertop

trong khi mạng không hoạt động và khi đạt đến độ bão hòa mạng. Điều này chắc chắn sẽ hiển thị nếu các ngắt Nic là thủ phạm. Thăm dò thiết bị là một câu trả lời cho tình huống như vậy. FreeBsd hỗ trợ chuyển đổi bỏ phiếu ngay bên trong ifconfig nhưng linux không có tùy chọn như vậy. Tham khảo ý kiến này để cho phép bỏ phiếu. Có thể nói BroadCom cũng hỗ trợ bỏ phiếu, đó là tin tốt cho bạn.

Tinh chỉnh gói Jumbo có thể không cắt giảm cho bạn vì bạn đã đề cập đến giao thông của mình chủ yếu là các gói nhỏ. Nhưng dù sao hãy thử nó!

bạn cần phân phối tải trên tất cả các lõi CPU. Bắt đầu 'mất cân bằng'.

Tôi nhận thấy trong danh sách các chỉnh sửa dấu thời gian bị tắt, xin vui lòng không làm điều đó. Đó là một sự trở lại cũ cho những ngày mới khi băng thông thực sự đắt đỏ và mọi người muốn tiết kiệm một vài byte / gói. Ví dụ, nó được sử dụng bởi ngăn xếp TCP để cho biết liệu một gói đến ổ cắm trong "CLOSE_WAIT" là gói cũ cho kết nối hay nếu đó là gói mới cho kết nối mới và giúp tính toán RTT. Và việc lưu một vài byte cho dấu thời gian là KHÔNG CÓ so với địa chỉ IPv6 sẽ thêm vào. Tắt dấu thời gian có hại nhiều hơn tốt.

Khuyến cáo này về việc tắt dấu thời gian chỉ là một trở ngại tiếp tục được truyền từ thế hệ sysadmin này sang thế hệ tiếp theo. Sắp xếp một loại "truyền thuyết đô thị".

Tôi đề xuất điều này:

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

Đã thử nghiệm trong các máy chủ Oracle DB trên RHEL và trong phần mềm sao lưu.

Trong trường hợp của tôi chỉ có một tuninng duy nhất:

net.ipv4.tcp_timestamps = 0

đã thực hiện một thay đổi rất lớn và hữu ích, thời gian tải trang web giảm 50%.