Çok sayıda bağlantı ve küçük paketlerin yoğun trafiğiyle gigabit ağ üzerinden TCP performansını iyileştirme

TCP işlem hacmimi “çok sayıda bağlantı ve küçük paketlerin yoğun trafiğiyle gigabit ağı” üzerinden geliştirmeye çalışıyorum. Sunucu işletim sistemim Ubuntu 11.10 Sunucu 64bit.

Sunucuma TCP Soketleri (hepsi aynı bağlantı noktasında) üzerinden bağlı yaklaşık 50.000 (ve artan) istemci var.

Paketlerimin% 95'i 1-150 bayt (TCP üstbilgisi ve taşıma yükü) boyutuna sahip. Geri kalan% 5, 150 ila 4096+ byte arasında değişir.

Aşağıdaki yapılandırma ile sunucum 30 Mbps'ye kadar (tam çift yönlü) trafiği kaldırabilir.

İhtiyaçlarım için işletim sistemi ayarlamak için en iyi uygulamaları tavsiye edebilir misiniz?

Benim /etc/sysctl.congşuna benziyor:

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

İşte benim sınırlarım:

$ 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

[EKLENDİ]

NIC'lerim aşağıdaki gibidir:

$ 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 eklendi]

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

[EKLENMİŞ 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 hakkında bazı bilgiler: TCP SACK ne zaman kapatılır?

Sorun, ağ kartınızda çok fazla kesintiye uğramanız olabilir. Bant genişliği sorun değilse, sorun şudur:

• Ağ kartındaki gönderme / alma arabelleklerini açma

  ethtool -g eth0
  

Size mevcut ayarları gösterecektir (256 veya 512 giriş). Bunları muhtemelen 1024, 2048 veya 3172'ye yükseltebilirsiniz. Daha fazlası muhtemelen bir anlam ifade etmiyor. Bu yalnızca sunucu gelen paketleri yeterince hızlı bir şekilde işleyemediğinde doldurulan bir halka arabelleğidir.

Tampon dolmaya başlarsa, akış kontrolü yönlendiriciye söylemenin veya yavaşlamaya geçmenin başka bir yoludur:

• Sunucudaki giriş / çıkış akışını ve bağlı olduğu anahtar / yönlendirici bağlantı noktalarını açın.

  ethtool -a eth0
  

Muhtemelen gösterecek:

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

Geçerli eth0 ayarı için / var / log / mesajları kontrol edin. Gibi bir şey olup olmadığını kontrol edin:

eth0: Bağlantı 1000 Mbps'de, tam çift yönlü, akış kontrolü tx ve rx'de

Tx ve rx'i göremiyorsanız, ağ yöneticileriniz anahtar / yönlendiricideki değerleri ayarlamak zorundadır. Cisco'da, alma / iletme akışı kontrolü açık.

Dikkat: Bu Değerleri değiştirmek bağlantınızı çok kısa bir süre için aşağı ve yukarı (1 saniyeden daha az) getirecektir.

• Bunların hepsi işe yaramazsa - ağ kartının hızını 100 MBit'e de düşürebilirsiniz (anahtar / yönlendirici bağlantı noktalarında da aynısını yapın)

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

Ancak sizin durumunuzda derim ki - NIC halka tamponundaki alıcı tamponları yükseltin.

Aşağıdaki kesin cevap olmayabilir ama kesinlikle bazı fikirler ortaya koyacaktır

Bunları sysctl.conf dosyasına eklemeyi deneyin

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

Seçici tcp ack, yüksek bant genişlikli ağ durumunda en iyi performans için iyidir. Ancak, diğer sakıncalara dikkat edin . Pencere ölçeklendirmenin faydaları burada açıklanmaktadır . Üçüncü sysctl seçeneği gelince: TCP varsayılan olarak, bağlantı kapandığında rota önbelleğinde çeşitli bağlantı ölçümlerini kaydeder, böylece yakın gelecekte kurulan bağlantılar başlangıç ​​koşullarını ayarlamak için bunları kullanabilir. Genellikle, bu genel performansı arttırır, ancak bazen performansın düşmesine neden olabilir. Ayarlanırsa, TCP bağlantılarını kapatırken metrikleri önbelleğe almaz.

İle kontrol edin

ethtool -k ethX

boşaltmanın etkin olup olmadığını görmek için TCP sağlama toplamı boşaltma ve büyük segmentli boşaltma bugünün Ethernet NIC'lerinin çoğunluğu tarafından desteklenir ve görünüşe göre Broadcom da bunu desteklemektedir.

Aracı kullanmayı deneyin

powertop

şebeke boştayken ve şebeke doygunluğuna ulaşıldığında. Bu kesinlikle NIC kesintilerinin suçlu olup olmadığını gösterecektir. Cihaz yoklama böyle bir duruma bir cevaptır. FreeBsd, ifconfig içindeki doğrudan sorgulama anahtarını destekler ancak linux'un böyle bir seçeneği yoktur. Consult Bu yoklama etkinleştirmek için. BroadCom ayrıca sizin için iyi bir haber olan oylamayı da destekliyor.

Jumbo paket çimdik , sizin trafiğinizin çoğunlukla küçük paketlerden oluştuğundan bahsettiğinizden sizin için kesmeyebilir. Ama yine de dene!

yükü tüm CPU çekirdeklerine dağıtmanız gerekir. 'İrqbalance' uygulamasını başlatın.

Tweaks listesinde zaman damgalarının kapalı olduğunu fark ettim, lütfen bunu yapma. Bu, bant genişliğinin gerçekten pahalı olduğu ve insanların birkaç byte / paket tasarruf etmek istediği eski günlere ait eski bir gerilemedir. Örneğin, bugünlerde TCP yığını tarafından, "CLOSE_WAIT" içindeki bir sokete gelen bir paketin bağlantı için eski bir paket olup olmadığını veya yeni bir bağlantı için yeni bir paket olup olmadığını ve RTT hesaplamalarında yardımcı olduğunu söylemek için kullanılır. Ve birkaç byte'ı bir zaman damgası için kaydetmek, IPv6 adreslerinin ekleyeceği şeye göre HİÇBİR ŞEY değildir. Zaman damgalarını kapatmak iyi olmaktan çok zarar verir.

Zaman damgalarını kapatmak için bu öneri sadece bir nesil sysadmin'den diğerine geçmeye devam eden bir gerilemedir. Bir "şehir efsanesi" türünden bir şey.

Bunu öneriyorum:

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'deki Oracle DB sunucularında ve yedekleme yazılımında test edilmiştir.

Benim durumumda sadece tek bir tuninng:

net.ipv4.tcp_timestamps = 0

çok büyük ve faydalı bir değişiklik yaptı, saha yükleme süresi% 50 azaldı.