मेरा गीगाबिट बांड कम से कम 150 एमबी / एस थ्रूपुट वितरित क्यों नहीं करता है?


17

मैंने सीधे दो अलग-अलग PCIe-एडाप्टर पर दो PowerEdge 6950 क्रॉसओवर (सीधी रेखाओं का उपयोग करके) को कनेक्ट किया।

मुझे इनमें से प्रत्येक पंक्ति (1000 MBit, पूर्ण द्वैध, दोनों दिशाओं में प्रवाह प्रतिरूप) पर एक गीगाबिट लिंक मिलता है।

अब मैं दोनों पक्षों पर आर-एल्गोरिथ्म का उपयोग करके इन इंटरफेस को बंधन 0 में बाँधने की कोशिश कर रहा हूँ (मैं एक एकल आईपी सत्र के लिए 2000 एमबीटी प्राप्त करना चाहता हूं)।

जब मैंने dd bs = 1M और netcat का tcp मोड का उपयोग करके / dev / शून्य / / dev / null में स्थानांतरित करके थ्रूपुट का परीक्षण किया तो मुझे 70 एमबी / एस का एक थ्रूपुट मिलता है - जैसा कि 150MB / s से अधिक अपेक्षित नहीं है।

जब मैं प्रत्येक लाइन पर लगभग 98 एमबी / एस प्राप्त करता हूं, अगर मैं प्रत्येक लाइन के लिए एक अलग दिशा का उपयोग करता हूं। जब मैं सिंगल लाइन का उपयोग करता हूं तो मुझे 70 एमबी / एस और 90 एमबी / एस लाइन पर मिलता है, अगर ट्रैफिक "उसी" दिशा में जाता है।

बॉन्डिंग-रीडमे (/usr/src/linux/Documentation/networking/bonding.txt) के माध्यम से पढ़ने के बाद, मुझे निम्न अनुभाग उपयोगी लगा: (13.1.1 MT बॉन्डिंग मोड चयन सिंगल स्विच टोपोलॉजी के लिए)

बैलेंस-आरआर: यह मोड एकमात्र ऐसा मोड है जो एकल टीसीपी / आईपी कनेक्शन को कई इंटरफेसों पर यातायात को रोकने की अनुमति देगा। इसलिए यह एकमात्र मोड है जो एकल टीसीपी / आईपी स्ट्रीम को एक से अधिक इंटरफ़ेस के थ्रूपुट के उपयोग की अनुमति देगा। यह एक लागत पर आता है, हालांकि: स्ट्रिपिंग अक्सर पीयर सिस्टम को पैकेट को ऑर्डर से प्राप्त करता है, जिससे टीसीपी / आईपी के कंजेशन कंट्रोल सिस्टम को किक करना पड़ता है, अक्सर सेगमेंट्स को रीट्रांसमिट करके।

    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.

अब मैंने 3 से 127 तक सभी लाइनों (4) पर दोनों जुड़े सर्वरों पर उस पैरामीटर को बदल दिया।

फिर से बॉन्डिंग के बाद मुझे लगभग 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 और low-level-driver विकल्प बदले। इसमें नेटवर्क बफ़र्स का इज़ाफ़ा शामिल है। यही कारण है कि ddअब 200 एमबी / एस से अधिक संख्या दिखाता है: डी डी समाप्त हो जाता है, जबकि अभी भी आउटपुट स्थानांतरित होने की प्रतीक्षा में है (भेजें बफ़र्स में)।

अद्यतन 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'

ध्यान दें कि सबसे बड़ा संभव एमटीयू स्थापित करना समाधान की कुंजी थी।

शामिल नेटवर्क कार्ड के आरएक्स / टीएक्स बफ़र्स की ट्यूनिंग:

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

क्या आपने /proc/net/bonding/bond0यह सत्यापित करने के लिए जाँच की है कि आप वास्तव में बैलेंस-आरआर में सेट हो रहे हैं ? क्या आपने नोट एन को देखा है कि आपने एक 4 इंटरफेस बॉन्ड के बारे में चिपकाया है, जो आपको केवल थ्रूपुट के 2.3 इंटरफेस दे रहा है? उस नोट को देखते हुए, यह अत्यधिक संभावना नहीं है कि आप 2000mb / s के करीब पाएंगे जो आप चाहते हैं।
ज़ोराडेक

मुझे यकीन नहीं है कि एलएसीपी / बॉन्डिंग एकल टीसीपी सत्र को कई भौतिक लिंक पर विभाजित कर सकती है।
केडेयर जुएल

@Kedare, यह LACP नहीं है, यह लिनक्स बॉन्डिंग मॉड्यूल का राउंड-रॉबिन पैकेट शेड्यूलर है जो एकल टीसीपी सत्र के लिए कई लिंक का उपयोग कर सकता है।
लार्क्स

1
एक लिंक पर थ्रूपुट के परीक्षण का एक बेहतर तरीका उपयोग करना है nuttcp। एकल कनेक्शन या एकाधिक कनेक्शन का आसानी से परीक्षण करें।
मिकीबी जूल

जवाबों:


8

मुझे कुछ समय पहले दो गीगाबिट लिंक पर एक drdd तुल्यकालन की गति बढ़ाने की कोशिश करने में इसी तरह की समस्या थी। अंत में मैं लगभग 150MB / सेकंड सिंक स्पीड पाने में कामयाब रहा। ये वे सेटिंग्स थीं जो मैंने दोनों नोड्स पर लागू की थीं:

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

यदि आप पहले से ही अपने नेटवर्क कार्ड ( ethtool --coalesce के साथ ) के लिए नहीं है, तो आप इंटरलेस कोलेसिऐशन को सक्षम करने का प्रयास कर सकते हैं।


मुझे नहीं पता। मेरे मामले में इसकी जरूरत नहीं थी। उन मापदंडों को सेट करना पर्याप्त था। लेकिन मुझे लगता है कि अगर आप इसे सेट करते हैं तो यह चोट नहीं पहुंचेगी। क्या ट्रांसफर रेट में सुधार हुआ?
user842313

1
मैं वर्तमान में यह परीक्षण नहीं कर सकता, लेकिन यह सबसे अधिक संभव है। "कोलेसेंस" के बारे में आपका संकेत संकेत को हिट करता है। मुझे "हाई स्पीड ईथरनेट" सेटिंग्स के बारे में एक दिलचस्प लेख (जर्मन में) मिला। जंबो फ्रेम एक ही दिशा में जाते हैं - यह सभी कार्यभार को स्थानांतरित करने के लिए आवश्यक pci-interrupts की संख्या को कम करने के बारे में है।
निल्स

यदि आप कुछ hw अड़चन पर विचार कर रहे हैं जैसे कि इंटरप्ट सीमाएं, तो कलेक्ट जैसा टूल निश्चित रूप से मदद करेगा, हालांकि इसके लिए थोड़े सेटअप की आवश्यकता होगी। उदाहरण के लिए, इस ग्राफ को देखें
user842313

0

क्या आपने स्विच पर इस दो-तरफा ट्रंक को कॉन्फ़िगर किया है? यदि नहीं तो यह उस तरह काम नहीं करेगा, यह सिर्फ सक्रिय / निष्क्रिय मोड में काम करेगा और केवल 1Gbps लिंक का उपयोग करेगा।


इसमें कोई नेटवर्क डिवाइस शामिल नहीं है। ये सीधे क्रॉसओवर केबल हैं।
निल

5
आह, तो आप एक और पूरी तरह से अलग कारण के लिए भाग्य से बाहर हैं; LACP / Etherchannel चड्डी इस तरह से विचरण पर निर्भर करती है पहली (और जहां उपयुक्त दूसरी और तीसरी) कम से कम महत्वपूर्ण बिट मैक को परिभाषित करने के लिए कि ट्रंक सदस्य का उपयोग उस मैक पर संवाद करने के लिए किया जाता है। यह देखते हुए कि आपके पास ट्रंक के लिए केवल एक ही मैक होगा, वे कभी भी एक से अधिक लिंक का उपयोग नहीं करेंगे।
चॉपर 3

2
वह इथरांचेल / 802.3ad का उपयोग नहीं कर रहा है, वह बैलेंस-आरआर का उपयोग कर रहा है, जो सटीक होने के लिए, किसी स्विच समर्थन की भी आवश्यकता नहीं है।
वैबबिट

@ चॉपर 3: इसलिए मैक-इश्यू आपकी राय में आरआर में नहीं दिखना चाहिए?
निल्स

2
पता है कि अच्छी तरह से टिप्पणी करने के लिए पर्याप्त नहीं है, थोड़े आप चाहते हैं कि सामान पहले उल्लेख किया है, लेकिन कोई बात नहीं।
चॉपर ३

0

ऐसा लगता है कि PowerEdge 6950 संभवतः PCI स्लॉट्स तक ही सीमित है जो 133 MB / s पर पूरे बस में साझा किए गए हैं। आप सिस्टम बस वास्तुकला पर I / O सीमाएं देख रहे होंगे।

अलग-अलग हार्डवेयर और I / O आर्किटेक्चर के परीक्षण के लिए अन्य प्रणालियों के बाहर, केबलिंग भी खेल में आ सकती है। कुछ संभावित संयोजन विभिन्न रेटिंग्स (5e बनाम 6) के साथ-साथ लंबाई के साथ हो सकते हैं (छोटी हमेशा बेहतर नहीं होती है)।


मुझे पहले से ही 160 एमबी / एस - समवर्ती एकल लाइनों का उपयोग करके मिला है। लेकिन यह बॉन्डिंग पर 100 एमबी / एस तक गिर जाता है। प्रत्येक सिंगल लाइन पर मुझे लगभग 100 एमबी / एस मिलता है इसलिए केबल को समस्या नहीं लगती है।
निल्स

PowerEdge 6950 के लिए कोई PCIe समर्थन प्रतीत नहीं होता है। इसकी PCI बस के साथ "अलग" कुछ भी? इसके बावजूद, आप PowerEdge 6950 के लिए IO बस विनिर्देशों देख सकते हैं।
user48838

मैंने lspci के आउटपुट के साथ प्रश्न को अपडेट किया। यह अड़चन नहीं थी। मुझे अब अपना 200 एमबी / एस मिलता है।
निल्स

0

जंबो फ्रेम?

ifconfig <interface> mtu 9000

यह सीपीयू लोड को कम करना चाहिए? मुझे आश्चर्य है कि इन परीक्षणों के दौरान सीपीयू क्या कर रहा है।
SpacemanSpiff

1
1500 के बजाय 9000 के MTU के साथ, आप tcp डेटा पैकेट की संख्या को कम कर देते हैं, जिसे आपको समान डेटा (पेलोड बड़ा है) को ट्रांसफर करने की आवश्यकता होती है। इसलिए आप पैकेट प्रोसेसिंग कम, दोनों तरफ और दोनों तरीकों से करते हैं, और अधिक डेटा भेजते हैं।
जुलिएन वाहन

ऐसा लगता है कि यह एक कोशिश के काबिल है। स्थानांतरण के दौरान सीपीयू बहुत निष्क्रिय हैं। लेकिन मुझे अभी भी यह महसूस हो रहा है कि एक भौतिक लिंक एक एसीके का इंतजार कर रहा है इससे पहले कि कर्नेल दूसरे भौतिक लिंक पर अगला पैकेट भेजता है।
निल्स

मैं परिणाम को लेकर उत्सुक हूं। इसके अलावा, प्रत्येक एनआईसी को सीपीयू कोर से बांधने का प्रयास करें। हाल ही में एक कर्नेल को ठीक से संभालना चाहिए, लेकिन मुझे यकीन नहीं है कि यह बॉन्डिंग के साथ कैसे काम करेगा। हर पैकेट के लिए एक एल 2 कैश से दूसरे पर स्विच करने से बचने का विचार है।
जुलिएन वाहन

सीपीयू लोड कोई समस्या नहीं है। सभी ऑफलोड विकल्प को चालू किया जाता है ...
निल्स

0

जंबो फ्रेम करना एक विशाल मदद है, जब तक कि आपका स्विच और निक इसे सपोर्ट करता है। यदि आपके पास एक अनवांटेड sivtch है, तो सबसे अधिक संभावना है कि आप बैंडविड्थ के लिए कहीं भी नहीं जाना चाहते हैं, लेकिन यदि आप स्विच पर पोर्ट को एक साथ बांध रहे हैं तो ऐसा नहीं है। यहाँ कुछ ive एक लंबे समय से पहले सीखा, 65% समय, इसका भौतिक मुद्दा। क्या आप cat6 केबल का उपयोग कर रहे हैं?


0

यदि आपने अपने nics पर जंबो फ्रेम कॉन्फ़िगर किया है, जिसके द्वारा यह सुनिश्चित किया जाता है कि आपने उच्च MTU के साथ-साथ समर्थन करने के लिए अपने स्विच कॉन्फ़िगर किए हैं।

जंबो फ्रेम, गिगाबिट नेटवर्क पर एक शानदार प्रदर्शन है, लेकिन आपको यह सुनिश्चित करने की आवश्यकता है कि आपके एंड टू एंड (दोनों स्रोत और गंतव्य सर्वर और उनके द्वारा उपयोग किए जाने वाले नेटवर्क स्विच) को कॉन्फ़िगर कर दिया है।


इस विशेष मामले में कोई नेटवर्क उपकरण शामिल नहीं हैं। (डायरेक्ट क्रॉसओवर लाइनें)। यह एकमात्र (वास्तविक) मामला भी है जहां आप एक ही सत्र के लिए सभी लाइनों में साझा किए गए लोड को प्राप्त करने के लिए आरआर एल्गोरिथ्म का उपयोग कर सकते हैं।
निल्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.