Чому моя гігабітна облігація не забезпечує пропускну здатність принаймні 150 Мб / с?


17

Я безпосередньо підключив два кросовери PowerEdge 6950 (за допомогою прямих ліній) на двох різних PCIe-адаптерах.

Я отримую гігабітове посилання на кожному з цих рядків (1000 Мбіт, повний дуплекс, контур потоку в обох напрямках).

Зараз я намагаюся зв'язати ці інтерфейси в bond0 за допомогою rr-алгоритму з обох сторін (я хочу отримати 2000 Мбіт за один IP-сеанс).

Коли я перевіряв пропускну здатність, переносячи / dev / zero в / dev / null, використовуючи dd bs = 1M та netcat в режимі tcp, я отримую пропускну здатність 70 Мб / с - не - як очікувалося більше 150 МБ / с.

Коли я використовую окремі рядки, я отримую приблизно 98 Мб / с у кожному рядку, якщо я використовував інший напрямок для кожного рядка. Коли я використовую одиночні лінії, я отримую 70 Мб / с і 90 Мб / с на лінії, якщо трафік йде в "той самий" напрямок.

Після прочитання через bonding-readme (/usr/src/linux/Documentation/networking/bonding.txt) я виявив корисний наступний розділ: (13.1.1 Вибір режиму скріплення для MT для одноповерхової топології)

balance-rr: Цей режим є єдиним режимом, який дозволить одному TCP / IP-з'єднанню здійснювати смугу трафіку через декілька інтерфейсів. Отже, це єдиний режим, який дозволить одному потоку TCP / IP використовувати більше ніж один інтерфейс, який має значення пропускної здатності. Однак це досягає великих витрат: зачистка часто призводить до того, що однорангові системи отримують пакети не в порядку, внаслідок чого система контролю заторів перешкод TCP / IP починає запускатися, часто шляхом повторної передачі сегментів.

    It is possible to adjust TCP/IP's congestion limits by
    altering the net.ipv4.tcp_reordering sysctl parameter. The
    usual default value is 3, and the maximum useful value is 127.
    For a four interface balance-rr bond, expect that a single
    TCP/IP stream will utilize no more than approximately 2.3
    interface's worth of throughput, even after adjusting
    tcp_reordering.

    Note that this out of order delivery occurs when both the
    sending and receiving systems are utilizing a multiple
    interface bond.  Consider a configuration in which a
    balance-rr bond feeds into a single higher capacity network
    channel (e.g., multiple 100Mb/sec ethernets feeding a single
    gigabit ethernet via an etherchannel capable switch).  In this
    configuration, traffic sent from the multiple 100Mb devices to
    a destination connected to the gigabit device will not see
    packets out of order.  However, traffic sent from the gigabit
    device to the multiple 100Mb devices may or may not see
    traffic out of order, depending upon the balance policy of the
    switch.  Many switches do not support any modes that stripe
    traffic (instead choosing a port based upon IP or MAC level
    addresses); for those devices, traffic flowing from the
    gigabit device to the many 100Mb devices will only utilize one
    interface.

Тепер я змінив цей параметр на обох підключених серверах у всіх рядках (4) від 3 до 127.

Після повторного зв’язку я отримую близько 100 Мб / с, але все ж не більше того.

Будь-які ідеї чому?

Оновлення: Деталі обладнання від lspci -v:

24:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
        Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter
        Flags: bus master, fast devsel, latency 0, IRQ 24
        Memory at dfe80000 (32-bit, non-prefetchable) [size=128K]
        Memory at dfea0000 (32-bit, non-prefetchable) [size=128K]
        I/O ports at dcc0 [size=32]
        Capabilities: [c8] Power Management version 2
        Capabilities: [d0] MSI: Mask- 64bit+ Count=1/1 Enable-
        Capabilities: [e0] Express Endpoint, MSI 00
        Kernel driver in use: e1000
        Kernel modules: e1000

Оновити кінцеві результати:

Скопійовано 8589934592 байт (8,6 ГБ), 35,8489 секунд, 240 Мб / с

Я змінив багато варіантів tcp / ip та драйверів низького рівня. Сюди входить розширення мережевих буферів. Ось чому ddтепер відображаються цифри, що перевищують 200 Мб / с: dd закінчується, поки ще є вихід, який очікує на перенесення (у буферах відправлення).

Оновлення 2011-08-05: Налаштування, які були змінені для досягнення мети ( /etc/sysctl.conf ):

# See http://www-didc.lbl.gov/TCP-tuning/linux.html
# raise TCP max buffer size to 16 MB. default: 131071
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# raise autotuninmg TCP buffer limits
# min, default and max number of bytes to use
# Defaults:
#net.ipv4.tcp_rmem = 4096 87380 174760
#net.ipv4.tcp_wmem = 4096 16384 131072
# Tuning:
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# Default: Backlog 300
net.core.netdev_max_backlog = 2500
#
# Oracle-DB settings:
fs.file-max = 6815744
fs.aio-max-nr = 1048576
net.ipv4.ip_local_port_range = 9000 65500
kernel.shmmax = 2147659776
kernel.sem = 1250 256000 100 1024
net.core.rmem_default = 262144
net.core.wmem_default = 262144
#
# Tuning for network-bonding according to bonding.txt:
net.ipv4.tcp_reordering=127

Спеціальні параметри для bond-пристрою (SLES: / etc / sysconfig / network / ifcfg-bond0 ):

MTU='9216'
LINK_OPTIONS='txqueuelen 10000'

Зауважте, що встановлення найбільшого можливого MTU було ключем до рішення.

Налаштування буферів rx / tx задіяних мережевих карт:

/usr/sbin/ethtool -G eth2 rx 2048 tx 2048
/usr/sbin/ethtool -G eth4 rx 2048 tx 2048

Ви перевірили, /proc/net/bonding/bond0щоб переконатися, що ви насправді отримуєте баланс-rr ? Чи бачили ви зауваження, що документація, яку ви вставили про зв'язок між 4 інтерфейсами, дає лише 2.3 інтерфейси, варті пропускної здатності? Враховуючи цю замітку, здається, дуже малоймовірно, що ви наблизитесь до потрібних 2000 Мб / с.
Zoredache

Я не впевнений, що LACP / Bonding може розділити один сеанс TCP на кілька фізичних посилань.
Кедаре

@ Kedare, це не LACP, це власний модуль скріплення модулів Linux, власний планувальник пакетних пакетів, який може використовувати декілька посилань для одного сеансу TCP.
larsks

1
Кращим способом тестування пропускної здатності на посилання є використання nuttcp. Легко протестуйте одиночні з'єднання або кілька підключень
MikeyB

Відповіді:


8

У мене була подібна проблема, намагаючись підвищити швидкість синхронізації drbd за двома гігабітними посиланнями деякий час тому. Врешті-решт мені вдалося досягти швидкості синхронізації близько 150 Мб / сек. Це були налаштування, які я застосував до обох вузлів:

ifconfig bond0 mtu 9000
ifconfig bond0 txqueuelen 10000
echo 3000 > /proc/sys/net/core/netdev_max_backlog

Ви також можете спробувати ввімкнути переривання злиття, якщо у вас ще немає мережевих карт (з ethtool --coalesce )


Не знаю. У моєму випадку це було не потрібно. Встановлення цих параметрів було достатньо. Але я думаю, якщо ви встановите це, це не зашкодить. Чи покращилась швидкість передачі?
user842313

1
Наразі це не можу перевірити, але це буде найбільш широко. Ваш натяк про «злиття» пропагандистсько вражає позначку. Я знайшов цікаву статтю (німецькою мовою) про налаштування "High Speed ​​Ethernet". Кадри джамбо йдуть в тому ж напрямку - мова йде про зменшення кількості pci-переривань, необхідних для перенесення навантаження.
Нілс

Якщо ви думаєте про деяке вузьке вузьке вузьке місце, наприклад, обмеження переривань, такий інструмент, як colled , безумовно, допоможе, хоча це вимагає трохи налаштування. Дивіться, наприклад, цей графік
user842313

0

Ви налаштували цей двосторонній магістраль на комутаторі? якщо ні, то він не працюватиме так, він просто працюватиме в активному / пасивному режимі і використовуватиме лише 1 з посилань 1Gbps.


Немає мережевого пристрою. Це прямі кросоверні кабелі.
Нілс

5
А, значить, тобі не пощастило з іншої зовсім іншої причини; Такі магістралі LACP / Etherchannel розраховують на дисперсію в першому (і, де це доцільно, другому і третьому) найменш значущому біті MAC призначення, щоб визначити, який член магістралі використовується для передачі зв'язку з цим MAC. Враховуючи, що у вас буде лише один MAC для магістралі на кожному кінці, вони ніколи не використовуватимуть більше ніж одне посилання.
Chopper3

2
він не використовує etherchannel / 802.3ad, він використовує balance-rr, який, якщо бути точним, навіть не потребує підтримки комутаторів.
the wabbit

@ Chopper3: Отже, питання MAC не повинно з'являтися в RR на ваш погляд?
Нілс

2
Не знаю, що достатньо добре коментувати, хотілося, щоб ви згадали про ці речі раніше, але не забувайте.
Chopper3

0

Схоже, PowerEdge 6950 обмежений можливо PCI-слотами, які досягають 133 Мб / с, що ділиться по всій шині. Можливо, ви бачите обмеження вводу / виводу в самій архітектурі системної шини.

Крім тестування інших систем з різною технікою обладнання та архітектури вводу-виводу, тестування кабелів також може вступати в гру. Деякі можливі комбінації можуть бути як за різними оцінками (5e проти 6), так і по довжині (коротше не завжди краще).


Я вже отримав 160 Мб / с - використовуючи одночасні одиничні рядки. Але це знижується до 100 Мб / с після з'єднання. На кожному рядку я отримую майже 100 Мб / с, тому кабелі теж не є проблемою.
Нілс

Здається, немає ніякої підтримки PCIe для PowerEdge 6950. Що-небудь "інше" з його шиною PCI? Незважаючи на те, ви можете ознайомитись із специфікаціями шин IO для PowerEdge 6950.
user48838

Я оновив питання з виходом lspci. Це не було вузьким місцем. Зараз я отримую свої 200 Мб / с.
Нілс

0

Кадри Jumbo?

ifconfig <interface> mtu 9000

Це має зменшити завантаження процесора, правильно? Цікаво, що робить процесор під час цих тестів.
SpacemanSpiff

1
при MTU 9000 замість 1500 ви зменшуєте кількість пакетів даних tcp, які вам потрібно перенести на той самий обсяг даних (корисна навантаження більша). Таким чином, ви робите меншу обробку пакетів з обох сторін та обох способів та надсилаєте більше даних.
Julien Vehent

Схоже, варто спробувати. Під час передачі процесори сильно простоюють. Але я все ще відчуваю, що одне фізичне посилання чекає ACK, перш ніж ядро ​​відправить наступний пакет на інше фізичне посилання.
Нілс

Мені цікаво і про результат. Також спробуйте прив’язати кожен NIC до ядра процесора. Нещодавнє ядро ​​повинно це правильно поводитись, але я не впевнений, як би це працювало із зв'язуванням. Ідея полягає у тому, щоб уникнути переходу з кешу l2 на інший для кожного пакету.
Julien Vehent

Завантаження процесора - це не проблема. Усі параметри розвантаження ввімкнено ...
Nils

0

робити джембові кадри - це гігантська допомога, якщо ваш перемикач і нік підтримують його. якщо у вас некерований сівот, швидше за все, ви не збираєтеся дістатися куди завгодно для пропускної здатності, але це не так, якщо ви зв'язуєте порти разом на комутаторі. ось щось, про що я дізнався давно, 65% часу, це фізична проблема. Ви використовуєте кабель cat6?


0

якщо ви налаштували джомбові кадри на своїх nics, які по зовнішньому вигляду ви переконайтеся, що ви налаштували свої комутатори так, щоб підтримувати високий MTU.

Кадри Jumbo - це велика продуктивність в гігабітних мережах, але вам потрібно переконатися, що вони налаштували їх в кінці (як вихідні, так і цільові сервери та мережеві комутатори, якими вони користуються).


У цьому спеціальному випадку немає мережевих пристроїв. (прямі перехресні лінії). Це також єдиний (реальний) випадок, коли ви можете використовувати алгоритм RR, щоб отримати навантаження, поділене по всіх рядках за один сеанс.
Нілс
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.