Mengapa ikatan gigabit saya tidak menghasilkan setidaknya 150 MB / s throughput?


17

Saya langsung menghubungkan dua crossover PowerEdge 6950 (menggunakan garis lurus) pada dua PCIe-adapter yang berbeda.

Saya mendapatkan tautan gigabit pada setiap baris ini (1000 MBit, dupleks penuh, aliran contol di kedua arah).

Sekarang saya mencoba untuk mengikat antarmuka ini ke bond0 menggunakan rr-algoritma di kedua sisi (saya ingin mendapatkan 2000 MBit untuk sesi IP tunggal).

Ketika saya menguji throughput dengan mentransfer / dev / nol ke / dev / null menggunakan dd bs = 1M dan netcat dalam mode tcp saya mendapatkan throughput 70 MB / s - tidak - seperti yang diharapkan lebih dari 150MB / s.

Ketika saya menggunakan baris tunggal saya mendapatkan sekitar 98 MB / s pada setiap baris, jika saya menggunakan arah yang berbeda untuk setiap baris. Ketika saya menggunakan baris tunggal saya mendapatkan 70 MB / s dan 90 MB / s di telepon, jika lalu lintas menuju ke arah "sama".

Setelah membaca bonding-readme (/usr/src/linux/Documentation/networking/bonding.txt), saya menemukan bagian berikut ini berguna: (13.1.1 Pilihan Mode Ikatan MT untuk Topologi Single Switch)

balance-rr: Mode ini adalah satu-satunya mode yang akan mengizinkan koneksi TCP / IP tunggal untuk memotong lalu lintas di beberapa antarmuka. Oleh karena itu satu-satunya mode yang akan memungkinkan aliran TCP / IP tunggal untuk memanfaatkan lebih dari satu nilai throughput antarmuka. Namun, hal ini berbiaya: striping sering mengakibatkan sistem peer menerima paket rusak, menyebabkan sistem kontrol kemacetan TCP / IP untuk menendang, sering dengan mentransmisikan kembali segmen.

    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.

Sekarang saya mengubah parameter itu pada kedua server yang terhubung pada semua baris (4) dari 3 menjadi 127.

Setelah ikatan lagi saya mendapatkan sekitar 100 MB / s tetapi masih tidak lebih dari itu.

Ada ide mengapa?

Pembaruan: Detail perangkat keras dari 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

Perbarui hasil akhir:

8589934592 byte (8,6 GB) disalin, 35,8489 detik, 240 MB / s

Saya mengubah banyak opsi tcp / ip dan driver tingkat rendah. Ini termasuk pembesaran buffer jaringan. Inilah sebabnya mengapa ddsekarang menunjukkan angka yang lebih besar dari 200 MB / s: dd berakhir sementara masih ada output yang menunggu untuk ditransfer (dalam mengirim buffer).

Pembaruan 2011-08-05: Pengaturan yang diubah untuk mencapai tujuan ( /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

Pengaturan khusus untuk bond-device (SLES: / etc / sysconfig / network / ifcfg-bond0 ):

MTU='9216'
LINK_OPTIONS='txqueuelen 10000'

Perhatikan bahwa pengaturan MTU sebesar mungkin adalah kunci untuk solusi.

Menyetel buffer rx / tx dari kartu jaringan yang terlibat:

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

Sudahkah Anda memeriksa /proc/net/bonding/bond0untuk memverifikasi bahwa Anda benar-benar disetel ke saldo-rr ? Apakah Anda melihat catatan dan dokumentasi yang Anda tempelkan tentang ikatan 4 antarmuka hanya memberi Anda 2,3 antarmuka senilai throughput? Mengingat catatan itu, tampaknya sangat tidak mungkin bahwa Anda akan mendekati 2000mb / s yang Anda inginkan.
Zoredache

Saya tidak yakin bahwa LACP / Bonding dapat membagi satu sesi TCP pada beberapa tautan fisik.
Kedare

@Kedare, ini bukan LACP, ini adalah modul ikatan Linux sendiri penjadwal paket round-robin yang dapat memanfaatkan banyak tautan untuk satu sesi TCP.
larsks

1
Cara yang lebih baik untuk menguji throughput pada tautan adalah menggunakan nuttcp. Uji koneksi tunggal atau banyak koneksi dengan mudah.
MikeyB

Jawaban:


8

Saya memiliki masalah yang sama ketika mencoba meningkatkan kecepatan sinkronisasi drbd melalui dua tautan gigabit beberapa waktu lalu. Pada akhirnya saya berhasil mendapatkan kecepatan sinkronisasi 150MB / detik. Ini adalah pengaturan yang saya terapkan pada kedua node:

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

Anda juga dapat mencoba mengaktifkan penggabungan interupsi jika Anda belum memiliki kartu jaringan (dengan ethtool --coalesce )


Saya tidak tahu Itu tidak diperlukan dalam kasus saya. Pengaturan parameter itu sudah cukup. Tapi saya kira jika Anda mengaturnya tidak ada salahnya. Apakah tingkat transfer membaik?
user842313

1
Saat ini saya tidak bisa mengujinya, tetapi itu akan paling baik. Petunjuk Anda tentang "koalesensi" mungkin akan berhasil. Saya menemukan artikel yang menarik (dalam bahasa Jerman) tentang pengaturan "High Speed ​​Ethernet". Frame jumbo menuju ke arah yang sama - ini adalah tentang mengurangi jumlah pci-interupsi yang diperlukan untuk mentransfer beban kerja.
Nils

Jika Anda berpikir pada beberapa hambatan seperti batas interupsi, alat seperti collectd pasti akan membantu, meskipun itu akan memerlukan sedikit pengaturan. Lihat, misalnya, grafik ini
user842313

0

Sudahkah Anda mengonfigurasi trunk dua arah ini di sakelar? jika tidak maka itu tidak akan berfungsi seperti itu, itu hanya akan bekerja dalam mode aktif / pasif dan hanya menggunakan 1 dari 1Gbps link.


Tidak ada perangkat jaringan yang terlibat. Ini adalah kabel crossover langsung.
Nils

5
Ah, jadi Anda kurang beruntung karena alasan lain yang sama sekali berbeda; LACP / Etherchannel trunks seperti ini bergantung pada varians di bit pertama dan ketiga yang paling tidak signifikan dari MAC tujuan untuk menentukan anggota trunk mana yang digunakan untuk berkomunikasi ke MAC tersebut. Karena Anda hanya akan memiliki satu MAC untuk trunk di setiap ujungnya, mereka tidak akan pernah menggunakan lebih dari satu tautan.
Chopper3

2
dia tidak menggunakan etherchannel / 802.3ad, dia menggunakan balance-rr, yang, tepatnya, bahkan tidak memerlukan dukungan saklar.
the-wabbit

@ Chopper3: Jadi masalah MAC seharusnya tidak muncul di RR menurut Anda?
Nils

2
Tidak tahu cukup baik untuk berkomentar, agak berharap Anda menyebutkan hal-hal itu sebelumnya tetapi tidak apa-apa.
Chopper3

0

Sepertinya PowerEdge 6950 terbatas pada kemungkinan slot PCI yang mencapai 133 MB / s yang dibagikan di seluruh bus. Anda mungkin melihat keterbatasan I / O pada arsitektur sistem bus itu sendiri.

Selain memiliki sistem lain dengan perangkat keras dan arsitektur I / O yang berbeda untuk diuji, pemasangan kabel mungkin juga ikut berperan. Beberapa kemungkinan kombinasi mungkin sepanjang garis peringkat yang berbeda (5e vs 6) serta panjangnya (lebih pendek tidak selalu lebih baik).


Saya sudah mendapatkan 160 MB / s - menggunakan baris tunggal bersamaan. Tapi ini turun menjadi 100 MB / s setelah ikatan. Pada setiap baris saya mendapatkan hampir 100 MB / s sehingga kabel tampaknya tidak menjadi masalah juga.
Nils

Tampaknya tidak ada dukungan PCIe untuk PowerEdge 6950. Adakah yang "berbeda" dengan bus PCI-nya? Meskipun demikian, Anda mungkin mencari spesifikasi bus IO untuk PowerEdge 6950.
user48838

Saya memperbarui pertanyaan dengan output lspci. Ini bukan hambatan. Saya mendapatkan 200 MB / s saya sekarang.
Nils 5'11

0

Bingkai jumbo?

ifconfig <interface> mtu 9000

Ini harus mengurangi beban CPU, kan? Saya bertanya-tanya apa yang dilakukan CPU selama tes ini.
SpacemanSpiff

1
dengan MTU 9000 dan bukan 1500, Anda mengurangi jumlah paket data tcp yang Anda perlukan untuk mentransformasikan jumlah data yang sama (payload lebih besar). Jadi Anda melakukan lebih sedikit pemrosesan paket, di kedua sisi dan kedua arah, dan mengirim lebih banyak data.
Julien Vehent

Sepertinya ini patut dicoba. CPU cukup menganggur saat transfer. Tetapi saya masih merasa bahwa satu tautan fisik sedang menunggu ACK sebelum kernel mengirimkan paket berikutnya pada tautan fisik lainnya.
Nils

Saya ingin tahu tentang hasilnya juga. Selain itu, cobalah untuk mengikat setiap NIC ke inti CPU. Kernel baru-baru ini harus mengatasinya dengan benar, tetapi saya tidak yakin bagaimana itu akan bekerja dengan ikatan. Idenya adalah untuk menghindari beralih dari cache l2 ke yang lain untuk setiap paket.
Julien Vehent

Beban CPU tidak menjadi masalah. Semua opsi pembongkaran diaktifkan ...
Nils

0

melakukan bingkai jumbo adalah bantuan raksasa, selama Anda beralih dan mendukungnya. jika Anda memiliki siwtch yang tidak dikelola, kemungkinan besar Anda tidak akan mendapatkan apa pun yang Anda inginkan untuk bandwidth, tetapi bukan itu masalahnya jika Anda mengikat port bersama pada switch. inilah sesuatu yang saya pelajari sejak lama, 65% dari waktu, itu adalah masalah fisik. apakah Anda menggunakan kabel cat6?


0

jika Anda telah mengkonfigurasi frame jumbo pada nics Anda yang pada tampilan Anda memastikan Anda telah mengkonfigurasi switch Anda untuk mendukung MTU yang tinggi juga.

Frame Jumbo adalah kinerja hebat pada jaringan gigabit tetapi Anda harus memastikan bahwa Anda telah mengonfigurasinya dari ujung ke ujung (server sumber dan tujuan dan switch jaringan yang mereka gunakan).


Tidak ada perangkat jaringan yang terlibat dalam kasus khusus ini. (garis crossover langsung). Ini juga merupakan satu-satunya kasus (nyata) di mana Anda dapat menggunakan algoritma RR untuk mendapatkan beban yang dibagi di semua lini untuk satu sesi.
Nils 5'11
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.