เพราะเหตุใดกิกะบิตของฉันจึงไม่ส่งผ่านข้อมูลอย่างน้อย 150 MB / s

ฉันเชื่อมต่อ CrossEdge PowerEdge 6950 สองตัวโดยตรง (โดยใช้เส้นตรง) บนสองอะแด็ปเตอร์ PCIe ที่ต่างกัน

ฉันได้รับลิงค์กิกะบิตในแต่ละบรรทัด (1,000 MBit, full duplex, flow contol ทั้งสองทิศทาง)

ตอนนี้ฉันกำลังพยายามที่จะเชื่อมต่ออินเทอร์เฟซเหล่านี้ใน bond0 โดยใช้ rr-algorithm ทั้งสองด้าน (ฉันต้องการรับ 2,000 MBit สำหรับเซสชัน IP เดียว)

เมื่อฉันทดสอบทรูพุตโดยการถ่ายโอน / dev / ศูนย์ถึง / dev / null โดยใช้ dd bs = 1M และ netcat ในโหมด tcp ฉันได้รับปริมาณงานที่ 70 MB / s - ไม่ใช่ - ตามที่คาดไว้มากกว่า 150MB / s

เมื่อฉันใช้บรรทัดเดียวฉันจะได้รับประมาณ 98 MB / s ในแต่ละบรรทัดถ้าฉันใช้ทิศทางที่แตกต่างกันสำหรับแต่ละบรรทัด เมื่อฉันใช้บรรทัดเดียวฉันจะได้รับ 70 MB / s และ 90 MB / s ในบรรทัดถ้าปริมาณการใช้งานไปในทิศทาง "เดียวกัน"

หลังจากอ่านผ่าน 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 MB / s แต่ก็ยังไม่มากกว่านั้น

ความคิดใด ๆ

อัปเดต: รายละเอียดฮาร์ดแวร์จาก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 GB), 35.8489 วินาที, 240 MB / s

ฉันเปลี่ยนตัวเลือก tcp / ip และไดรเวอร์ระดับต่ำจำนวนมาก รวมถึงการขยายบัฟเฟอร์เครือข่าย นี่คือสาเหตุที่ddตอนนี้แสดงจำนวนที่มากกว่า 200 MB / s: 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

การตั้งค่าพิเศษสำหรับอุปกรณ์บอนด์ (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

ฉันมีปัญหาคล้ายกันที่พยายามเพิ่มความเร็วของการซิงโครไนซ์ drbd ผ่านลิงก์กิกะบิตสองอันในช่วงเวลาที่ผ่านมา ในที่สุดฉันจัดการเพื่อรับความเร็วซิงค์ประมาณ 150MB / วินาที นี่เป็นการตั้งค่าที่ฉันใช้กับทั้งสองโหนด:

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

คุณสามารถลองเปิดใช้งานการเชื่อมต่อระหว่างกันถ้าคุณยังไม่มีการ์ดเครือข่าย (ด้วยethtool --coalesce )

คุณได้กำหนดค่าลำตัวแบบสองทางนี้บนสวิตช์หรือไม่ ถ้าไม่เช่นนั้นมันจะไม่ทำงานอย่างนั้นมันจะทำงานในโหมดแอคทีฟ / พาสซีฟและใช้ลิงค์ 1 จาก 1Gbps เท่านั้น

ดูเหมือนว่า PowerEdge 6950 นั้น จำกัด อยู่ที่สล็อต PCI ซึ่งอาจมีการแบ่งออกสูงสุดที่ 133 MB / s ทั่วทั้งบัส คุณอาจเห็นข้อ จำกัด ของ I / O ในสถาปัตยกรรมบัสของระบบเอง

นอกเหนือจากการมีระบบอื่นที่มีฮาร์ดแวร์และสถาปัตยกรรม I / O ที่แตกต่างกันเพื่อทดสอบแล้วการเดินสายเคเบิลก็อาจเข้ามามีบทบาทด้วยเช่นกัน ชุดค่าผสมที่เป็นไปได้บางอย่างอาจอยู่ในบรรทัดของการให้คะแนนที่แตกต่างกัน (5e กับ 6) รวมถึงความยาว (สั้นกว่าไม่ดีกว่าเสมอไป)

เฟรมจัมโบ้?

ifconfig <interface> mtu 9000

การทำเฟรมจัมโบ้นั้นเป็นความช่วยเหลือที่ยิ่งใหญ่ตราบใดที่สวิตช์ของคุณและตัวรองรับของมัน หากคุณมี siwtch ที่ไม่มีการจัดการเป็นไปได้ว่าคุณจะไม่ได้รับทุกที่ที่คุณต้องการแบนด์วิดท์ แต่นั่นไม่ใช่กรณีหากคุณเชื่อมพอร์ตเข้าด้วยกันบนสวิตช์ นี่คือสิ่งที่ ive เรียนรู้เมื่อนานมาแล้ว 65% เป็นปัญหาทางกายภาพ คุณใช้สายเคเบิล cat6 หรือไม่

หากคุณได้กำหนดค่าเฟรมจัมโบ้บน nics ของคุณซึ่งคุณต้องแน่ใจว่าคุณได้ตั้งค่าสวิตช์ของคุณให้รองรับ MTU สูงเช่นกัน

เฟรมจัมโบ้มีประสิทธิภาพที่ยอดเยี่ยมในเครือข่ายกิกะบิต แต่คุณต้องมั่นใจว่าคุณได้กำหนดค่าไว้ตั้งแต่ต้นจนจบ (ทั้งเซิร์ฟเวอร์ต้นทางและปลายทางและสวิตช์เครือข่ายที่ใช้)