Я пытаюсь улучшить пропускную способность TCP в «гигабитной сети с большим количеством подключений и большим трафиком небольших пакетов». Моя серверная ОС - это Ubuntu 11.10 Server 64bit.
К моему серверу через сокеты TCP (все на одном порту) подключено около 50 000 (и их число растет).
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
[ДОБАВЛЕНО 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 / messages текущие настройки 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 и разгрузка большого сегмента поддерживаются большинством современных сетевых адаптеров Ethernet и очевидно Broadcom также поддерживает это.
Попробуйте использовать инструмент
powertop
пока сеть неактивна и когда сеть насыщена. Это определенно покажет, являются ли причиной прерывания сетевого адаптера. Опрос устройства - ответ на такую ситуацию. FreeBsd поддерживает переключатель опроса прямо внутри ifconfig, но в Linux такой опции нет. Проконсультируйтесь этот для включения опроса. В нем говорится, что BroadCom также поддерживает опросы, и это хорошая новость для вас.
Настройка Jumbo-пакетов Возможно, это не поможет вам, поскольку вы упомянули, что ваш трафик состоит в основном из небольших пакетов. Но все равно попробуйте!
Я заметил в списке настроек, что отметки времени отключены, пожалуйста, не делайте этого. Это старый возврат к былым временам, когда полоса пропускания была очень дорогой и люди хотели сэкономить несколько байтов на пакет. В наши дни он используется, например, стеком TCP, чтобы определить, является ли пакет, поступающий на сокет в «CLOSE_WAIT», старым пакетом для соединения или это новый пакет для нового соединения и помогает в расчетах RTT. И сохранение нескольких байтов для метки времени - НИЧЕГО по сравнению с тем, что адреса IPv6 собираются добавить. Отключение меток времени приносит больше вреда, чем пользы.
Эта рекомендация по отключению временных меток - просто возврат, который постоянно передается от одного поколения системных администраторов к следующему. Что-то вроде "городской легенды".
Предлагаю это:
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 и в программном обеспечении для резервного копирования.
вам необходимо распределить нагрузку по всем ядрам процессора. Запустите irqbalance.
В моем случае только одна настройка:
net.ipv4.tcp_timestamps = 0
внесены очень большие и полезные изменения, время загрузки сайта уменьшилось на 50%.