Вопрос: Повышение производительности TCP по сравнению с гигабитной сетью с большим количеством подключений и высоким трафиком небольших пакетов


Я пытаюсь улучшить пропускную способность TCP через «гигабитную сеть с большим количеством соединений и высоким трафиком небольших пакетов». Моя серверная ОС - Ubuntu 11.10 Server 64bit.

Около 50 000 (и растущих) клиентов подключены к моему серверу через TCP-сокеты (все на одном порту).

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

[Добавлено]

Мои сетевые адаптеры следующие:

$ 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

[ADDED 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?


36
2018-02-07 22:10


Источник


Это может помочь: datatag.web.cern.ch/datatag/howto/tcp.html - yarek
Какой ограничивающий фактор? Максимально ли ваш процессор? Если это так, вы лаем неправильное дерево. Вам нужно посмотреть, что делает процессор. - David Schwartz
Какой сетевой адаптер у вас есть? - SaveTheRbtz
BTW: Почему вы отключите SACK? - Nils
Вы должны пересмотреть использование Broadcom NICs ... - Hubert Kario


Ответы:


Проблема может заключаться в том, что вы получаете слишком много прерываний на своей сетевой карте. Если полоса пропускания не является проблемой, частота является проблемой:

  • Включение буферов отправки / получения на сетевой карте

    ethtool -g eth0
    

Покажу вам текущие настройки (256 или 512 записей). Вероятно, вы можете повысить их до 1024, 2048 или 3172. Более вероятно, не имеет смысла. Это всего лишь кольцевой буфер, который заполняется только в том случае, если сервер не способен обрабатывать входящие пакеты достаточно быстро.

Если буфер начинает заполняться, управление потоком является дополнительным средством, чтобы сообщить маршрутизатору или переключиться на замедление:

  • Включите управление потоком в / исходящие на сервере и к портам коммутатора / маршрутизатора, к которым он подключен.

    ethtool -a eth0
    

Вероятно, покажут:

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

Проверьте / var / log / messages для текущей настройки eth0. Проверьте что-то вроде:

eth0: Link работает со скоростью 1000 Мбит / с, полный дуплекс, управление потоком tx и rx

Если вы не видите tx и rx, ваши администраторы сети должны настроить значения на коммутаторе / маршрутизаторе. На Cisco, на который распространяется управление потоком приема / передачи.

Осторожно: Изменение этих значений приведет к тому, что ваша связь будет снижена и будет работать очень короткое время (менее 1 с).

  • Если все это не поможет - вы также можете снизить скорость сетевой карты до 100 Мбит (сделать то же самое на портах коммутатора / маршрутизатора)

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

Но в вашем случае я бы сказал - поднимите буферы приема в кольцевом буфере NIC.


20
2018-02-11 22:45



Глядя на ваши цифры из ethtool Я бы сказал, - установите буферы приема сетевой карты максимально, чтобы избежать сброса RX. Надеюсь, у вашего Broadcom их хватит. - Nils
Увеличение буферизации с помощью TCP почти никогда не является хорошей идеей. У нас уже слишком много буферизации: bufferbloat.net/projects/bloat/wiki/Introduction - rmalayter
Этот буфер является аппаратным буфером непосредственно на сетевом адаптере. Я уточню свой ответ с более подробной информацией. Поскольку вы теряете входящие пакеты, вам нужен этот буфер. У меня есть аналогичный сервер, где мне пришлось переключиться на другой сетевой адаптер (от встроенного Broadcom до PCIe Intel), чтобы иметь возможность увеличивать эти буферы. После этого я больше не сталкивался с потерянными RX-пакетами. - Nils
@malayter: это кольцевой буфер на уровне 2. См. мой обновленный ответ. - Nils
Наконец, у нас 1 ГБ. В разных местах было много настроек, поэтому нельзя сказать, что была одна проблема. - Worker


Следующий может быть не окончательный ответ, но он определенно выдвинет некоторые идеи

Попробуйте добавить их в 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 и большая разгрузка сегмента поддерживаются большинством современных сетевых сетевых адаптеров Ethernet и, по-видимому, Broadcom также поддерживает его.

Попробуйте использовать инструмент

powertop

пока сеть не работает и когда достигается насыщенность сети. Это определенно покажет, является ли прерывание NIC виновником. Опрос устройств - это ответ на такую ​​ситуацию. FreeBsd поддерживает переключатель опроса прямо внутри ifconfig, но linux не имеет такой опции. советоваться это для включения опроса. Он говорит, что BroadCom также поддерживает опрос, который является хорошей новостью для вас.

Jumbo packet tweak может не вырезать его для вас, так как вы упомянули, что ваш трафик состоит в основном из небольших пакетов. Но все равно попробуй!


4
2018-02-12 05:22



2kaji, я попробую вас предложения завтра. О PowerTop - следует ли настраивать энергосбережение, если моя цель - производительность? - Worker
Да, конечно, это также может помочь. Я упомянул powertop только для того, чтобы убедиться, что прерывания - это зло. Частоту прерываний можно также собирать из других инструментов - kaji
Я вижу высокие «перепланирующие прерывания» - может быть, это причина? Что такое «Перенос прерываний»? - Worker
Попытайтесь следовать этому ---> help.ubuntu.com/community/ReschedulingInterrupts - kaji
да .. Я видел этот учебник, но это для ноутбуков, в то время как я вижу высокие прерывания на сервере. Попробует применить его к серверу. - Worker


вам необходимо распределить нагрузку на все ядра ЦП. Начните «irqbalance».


1
2018-05-31 01:54



Это не поможет, если один IRQ имеет очень высокую freuency. IRQBalance пытается распространять отдельные IRQ для удовлетворения логических процессоров, но не будет ни одного процессора, обслуживающего один IRQ. - Nils


Я предлагаю следующее:

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 и в программном обеспечении резервного копирования.


1
2018-02-19 11:15



Эти номера настраиваются, потому что нет единого размера. Это означает, что сами цифры не ценны. Что может быть ценным, так это метод, который вы использовали для определения того, какие номера использовать. - kasperd


В моем случае только один tuninng:

net.ipv4.tcp_timestamps = 0

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


1
2018-02-19 10:57



Что-то должно быть серьезно нарушено в настройках, чтобы это произошло. Временные метки используют менее 1% полосы пропускания в обычных условиях и позволят TCP выполнять повторные передачи гораздо более жестко, чем в противном случае. - kasperd


Я заметил в списке трюков, что временные метки отключены, пожалуйста, не делайте этого. Это старый возврат к временам, когда пропускная способность была действительно дорогой, и люди хотели сохранить несколько байтов / пакетов. Он используется, например, стек TCP в эти дни, чтобы определить, является ли пакет, прибывающий для сокета в «CLOSE_WAIT», старым пакетом для подключения или новым пакетом для нового соединения и помогает при расчетах RTT. И сохранение нескольких байтов для метки времени НИЧЕГО по сравнению с тем, что IPv6-адреса собираются добавить. Отключение временных меток приносит больше вреда, чем пользы.

Эта рекомендация по отключению временных меток - это всего лишь возврат, который продолжает переходить от одного поколения системного администратора к другому. Вид «городской легенды».


0
2018-05-13 16:39