Поліпшення продуктивності TCP в гігабітній мережі з великою кількістю з'єднань і великим трафіком невеликих пакетів

Я намагаюся покращити пропускну здатність TCP через "гігабітну мережу з великою кількістю з'єднань і великим трафіком невеликих пакетів". Моя ОС сервера - Ubuntu 11.10 Server 64bit.

На моєму сервері підключено близько 50 000 (і зростаючих) клієнтів через TCP Sockets (усі на тому ж порту).

95% моїх пакетів мають розмір 1-150 байт (заголовок TCP та корисна навантаження). Решта 5% варіюються від 150 до 4096+ байт.

З конфігурацією нижче мій сервер може обробляти трафік до 30 Мбіт / с (повний дуплекс).

Чи можете ви порадити кращою практикою щодо налаштування ОС на мої потреби?

Моє /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

Перевірте / var / log / повідомлення на поточну установку eth0. Перевірте щось на зразок:

eth0: Посилання працює на 1000 Мбіт / с, повний дуплекс, контроль потоку tx і rx

Якщо ви не бачите tx та rx, ваші мережеві адміністратори повинні відрегулювати значення на комутаторі / маршрутизаторі. На Cisco, який приймає / передає управління потоком.

Остерігайтеся: Змінення цих Значень призведе до того, що ваше посилання знизиться та перейде на дуже короткий час (менше 1 секунди).

• Якщо все це не допомагає - ви також можете знизити швидкість мережевої карти до 100 Мбіт (зробіть те ж саме на комутаторах / маршрутизаторах)

  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 та завантаження великого сегмента підтримується більшістю сьогоднішніх мереж EIC-мереж, і, очевидно, Broadcom також підтримує це.

Спробуйте скористатися інструментом

powertop

поки мережа не працює, і коли буде досягнуто насичення мережі. Це неодмінно покаже, чи є винуватцем переривання NIC. Опитування на пристрої - це відповідь на таку ситуацію. FreeBsd підтримує перемикач опитування прямо всередині ifconfig, але Linux не має такої можливості. Зверніться до цього, щоб увімкнути опитування. Це означає, що BroadCom також підтримує опитування, що є гарною новиною для вас.

Налаштування пакетів Jumbo може не вирізати для вас, оскільки ви згадали, що ваш трафік складається здебільшого з невеликих пакетів. Але випробувати це все одно!

вам потрібно розподілити навантаження по всіх ядрах процесора. Почніть "irqbalance".

Я помітив у списку налаштувань, що часові позначки вимкнено, будь ласка, не робіть цього. Це старий відкат до днів, коли пропускна здатність була дуже дорогою, і люди хотіли заощадити кілька байт / пакет. Наприклад, він використовується, наприклад, стеком TCP в ці дні для того, щоб визначити, чи є пакет, що надходить для сокета в "CLOSE_WAIT", старий пакет для з'єднання або якщо це новий пакет для нового з'єднання і допомагає в обчисленнях RTT. І збереження кількох байтів для часової позначки НІЧОГО порівняно з тим, які 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

Тестовано на серверах Oracle DB на RHEL та в резервному програмному забезпеченні.

У моєму випадку лише один тунінг:

net.ipv4.tcp_timestamps = 0

зробив дуже велику і корисну зміну, час завантаження сайту зменшився на 50%.