बहुत सारे कनेक्शन और छोटे पैकेट के उच्च यातायात के साथ एक गीगाबिट नेटवर्क पर टीसीपी प्रदर्शन में सुधार

37

मैं अपने टीसीपी थ्रूपूट को "गीगाबिट नेटवर्क पर बहुत सारे कनेक्शन और छोटे पैकेट के उच्च ट्रैफ़िक" के साथ बेहतर बनाने की कोशिश कर रहा हूं। मेरा सर्वर OS उबंटू 11.10 सर्वर 64 बिट है।

टीसीपी सॉकेट (एक ही पोर्ट पर) के माध्यम से मेरे सर्वर से जुड़े लगभग 50.000 (और बढ़ते) ग्राहक हैं।

मेरे पैकेट के 95% में 1-150 बाइट्स (टीसीपी हेडर और पेलोड) का आकार है। बाकी 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

[जोड़ा ३]

 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 को कब बंद करें?

— मज़दूर
स्रोत

1

यह मदद कर सकता है: datatag.web.cern.ch/datatag/howto/tcp.html

— yrk

सीमित कारक क्या है? क्या आपका सीपीयू अधिकतम है? यदि हां, तो आप गलत पेड़ को भौंक रहे हैं। आपको यह देखने की जरूरत है कि सीपीयू क्या कर रहा है।

— डेविड श्वार्ट्ज

आपके पास क्या एनआईसी है?

— Save TheRbtz

1

BTW: तुम क्यों बंद करते हो?

— निल्स

1

आपको ब्रॉडकॉम एनआईसी का उपयोग करके पुनर्विचार करना चाहिए ...

— ह्यूबर्ट करियो

21

समस्या यह हो सकती है कि आपको अपने नेटवर्क कार्ड पर बहुत अधिक व्यवधान हो रहे हों। यदि बैंडविड्थ समस्या नहीं है, तो आवृत्ति समस्या है:

नेटवर्क कार्ड पर बफ़र्स भेजें / प्राप्त करें
```
ethtool -g eth0
```

आपको वर्तमान सेटिंग्स (256 या 512 प्रविष्टियाँ) दिखाएंगे। आप संभवत: इन्हें 1024, 2048 या 3172 तक बढ़ा सकते हैं। अधिक शायद इसका कोई मतलब नहीं है। यह केवल एक रिंग बफ़र है जो केवल तभी भरता है जब सर्वर आने वाले पैकेट को तेज़ी से संसाधित करने में सक्षम नहीं होता है।

यदि बफर भरना शुरू हो जाता है, तो राउटर नियंत्रण राउटर को बताने या धीमा करने के लिए स्विच करने का एक अतिरिक्त साधन है:

सर्वर पर / आउटबाउंड में प्रवाह नियंत्रण चालू करें और इसके साथ स्विच / राउटर-पोर्ट संलग्न हैं।
```
ethtool -a eth0
```

शायद दिखाएंगे:

Pause parameters for eth0:
Autonegotiate:  on
RX:             on
TX:             on

Eth0 की वर्तमान सेटिंग के लिए / var / log / संदेश देखें। कुछ इस तरह की जाँच करें:

eth0: लिंक 1000 एमबीपीएस, फुल डुप्लेक्स, फ्लो कंट्रोल टीएक्स और आरएक्स पर है

यदि आप tx और rx नहीं देखते हैं, तो आपके नेटवर्क के प्रवेशकों को स्विच / राउटर पर मूल्यों को समायोजित करना होगा। सिस्को पर प्राप्त / प्रवाह प्रवाह नियंत्रण पर है।

खबरदार: इन मूल्यों को बदलने से आपका लिंक बहुत कम समय (1s से कम) के लिए नीचे और ऊपर आएगा।

यदि यह सब मदद नहीं करता है - तो आप नेटवर्क कार्ड की गति को 100 एमबीटिट तक भी कम कर सकते हैं (स्विच / रूटर-पोर्ट पर भी ऐसा ही करें)
```
ethtool -s eth0 autoneg off && ethtool -s eth0 speed 100
```

लेकिन आपके मामले में मैं कहूंगा - एनआईसी रिंग बफर में प्राप्त बफ़र्स बढ़ाएं।

— निल्स
स्रोत

आपके नंबर को देखकर ethtoolमैं कहूंगा - RX कार्ड से बचने के लिए नेटवर्क कार्ड के प्राप्त बफ़र्स को अधिकतम पर सेट करें। मुझे उम्मीद है कि आपके ब्रॉडकॉम के पास इनमें से काफी हैं।

— निल्स

1

टीसीपी के साथ बढ़ती बफरिंग लगभग एक अच्छा विचार नहीं है। हमारे पास पहले से ही बहुत अधिक बफरिंग है: बफरब्लैट.नेट

— प्रोजेक्ट्स

3

यह बफर एनआईसी पर सीधे हार्डवेयर बफर है। मैं अधिक विवरण के साथ अपने उत्तर को अपडेट करूंगा। जब से आप आने वाले पैकेट खो रहे हैं आपको उस बफर की आवश्यकता है। मेरे पास एक समान सर्वर है जहां मुझे इन बफ़र्स को बढ़ाने में सक्षम होने के लिए एक अलग एनआईसी (ऑनबोर्ड ब्रॉडकॉम से पीसीआई इंटेल) पर स्विच करना पड़ा। उसके बाद मैंने कभी भी खोए हुए आरएक्स-पैकेट का सामना नहीं किया।

— निल्स

@malayter: यह परत 2 पर रिंग-बफर है। मेरा अद्यतन उत्तर देखें।

— निल्स

1

अंत में हमारे पास 1GB है। अलग-अलग जगहों पर बहुत सारे ट्यूनिंग थे, इसलिए वास्तव में यह नहीं कह सकते कि एकल समस्या थी।

— वर्कर

5

निम्नलिखित निश्चित उत्तर नहीं हो सकते हैं, लेकिन यह निश्चित रूप से कुछ विचारों को सामने रखेगा

इन्हें 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 विकल्प के रूप में: डिफ़ॉल्ट रूप से, टीसीपी कनेक्शन बंद होने पर मार्ग कैश में विभिन्न कनेक्शन मेट्रिक्स को बचाता है, ताकि निकट भविष्य में स्थापित कनेक्शन प्रारंभिक शर्तों को सेट करने के लिए इनका उपयोग कर सकें। आमतौर पर, यह समग्र प्रदर्शन को बढ़ाता है, लेकिन कभी-कभी प्रदर्शन में गिरावट का कारण बन सकता है। यदि सेट किया गया है, तो टीसीपी कनेक्शन बंद करने पर मैट्रिक्स को कैश नहीं करेगा।

इससे जाँच करें

ethtool -k ethX

यह देखने के लिए कि ऑफ़लोडिंग सक्षम है या नहीं। टीसीपी चेकसम ऑफलोड और बड़े सेगमेंट के लोड को आज के ईथरनेट एनआईसी के बहुमत से समर्थन मिलता है और जाहिर तौर पर ब्रॉडकॉम भी इसका समर्थन करता है।

उपकरण का उपयोग करके देखें

powertop

जबकि नेटवर्क निष्क्रिय है और जब नेटवर्क संतृप्ति तक पहुँच जाता है। यह निश्चित रूप से दिखाएगा कि एनआईसी बाधित होने वाला अपराधी है। डिवाइस पोलिंग ऐसी स्थिति का जवाब है। FreeBsd ifconfig के ठीक अंदर पोलिंग स्विच का समर्थन करता है लेकिन linux के पास ऐसा कोई विकल्प नहीं है। मतदान सक्षम करने के लिए यह परामर्श करें । यह कह रहा है ब्रॉडकॉम मतदान का भी समर्थन करता है जो आपके लिए अच्छी खबर है।

जंबो पैकेट ट्विक शायद आपके लिए इसे काट नहीं सकता क्योंकि आपने ज्यादातर छोटे पैकेटों में अपने ट्रैफ़िक कॉन्ट्रेट का उल्लेख किया था। लेकिन हे इसे वैसे भी बाहर की कोशिश करो!

— काजी
स्रोत

2kaji, मैं कल आपको सुझाव देने की कोशिश करूंगा। PowerTop के बारे में - यदि मेरा लक्ष्य प्रदर्शन है तो क्या मुझे बिजली की बचत करनी चाहिए?

— वर्कर

हां, यह भी मदद कर सकता है। मैंने पॉवरटॉप का उल्लेख सिर्फ यह सुनिश्चित करने के लिए किया कि अगर बीच में बुराई हो। इंटरप्ट की आवृत्ति को अन्य उपकरणों से भी काटा जा सकता है

— काजी

मैं उच्च "पुनर्निर्धारित व्यवधान" देखता हूं - क्या यह एक कारण हो सकता है? "पुनर्निर्धारित व्यवधान" क्या है?

— कार्यकर्ता

इस का पालन करने की कोशिश करें ---> help.ubuntu.com/community/ReschedulingInterrupts

— काजी

हाँ .. मैंने उस ट्यूटोरियल को देखा, लेकिन यह लैपटॉप के लिए है जबकि मुझे सर्वर में उच्च व्यवधान दिखाई देता है। इसे सर्वर पर लागू करने का प्रयास करेंगे।

— कार्यकर्ता

2

आपको सभी सीपीयू कोर पर लोड वितरित करने की आवश्यकता है। 'असंबद्धता' शुरू करें।

— user175978
स्रोत

1

यह मदद नहीं करेगा अगर एक एकल IRQ में बहुत अधिक फ्रीयूेंसी हो। IRQBalance एकल आईआरक्यू को तार्किक प्रोसेसर को वितरित करने की कोशिश करता है - लेकिन एक आईआरक्यू की सेवा करने वाले एक से अधिक प्रोसेसर कभी नहीं होंगे।

— निल्स

2

मैंने ट्वीक की सूची में देखा कि टाइमस्टैम्प बंद है, कृपया ऐसा न करें। यह योर के दिनों का एक पुराना कमबैक है जब बैंडविड्थ वास्तव में महंगा था और लोग कुछ बाइट्स / पैकेट बचाना चाहते थे। इसका उपयोग उदाहरण के लिए, टीसीपी स्टैक द्वारा इन दिनों यह बताने के लिए किया जाता है कि "CLOSE_WAIT" में सॉकेट के लिए आने वाला पैकेट कनेक्शन के लिए पुराना पैकेट है या यदि यह नए कनेक्शन के लिए नया पैकेट है और RTT गणना में मदद करता है। और एक टाइमस्टैम्प के लिए कुछ बाइट्स को सहेजना IPv6 पतों को जोड़ने की तुलना में कुछ भी नहीं है। टाइमस्टैम्प बंद करने से अच्छे से अधिक नुकसान होता है।

टाइमस्टैम्प को बंद करने के लिए यह सिफारिश सिर्फ एक फेंक है जो कि एक पीढ़ी से दूसरी पीढ़ी तक जाती रहती है। एक "शहरी किंवदंती" की तरह की चीज।

— GeorgeB
स्रोत

2

मैं यह प्रस्ताव करता हूं:

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

आरएचईएल और बैकअप सॉफ्टवेयर में ओरेकल डीबी सर्वरों में परीक्षण किया गया।

— कोनराड पुचला
स्रोत

5

ये संख्याएँ कॉन्फ़िगर करने योग्य हैं क्योंकि कोई एक आकार-फिट-सभी नहीं है। इसका मतलब है कि संख्याएँ स्वयं मूल्यवान नहीं हैं। क्या मूल्यवान हो सकता है वह विधि है जिस पर आप निर्णय लेते हैं कि किस संख्या का उपयोग करना है।

— कैस्परल्ड

2

मेरे मामले में केवल एक ही सुरंग:

net.ipv4.tcp_timestamps = 0

एक बहुत बड़ा और उपयोगी परिवर्तन किया, साइट लोडिंग समय 50% तक घट गया।

— avz2012
स्रोत

ऐसा करने के लिए आपके सेटअप में कुछ गंभीर रूप से टूटा होना चाहिए। सामान्य परिस्थितियों में टाइमस्टैम्प 1% से भी कम बैंडविड्थ का उपयोग करता है और टीसीपी को अन्यथा की तुलना में बहुत अधिक समय तक पुन: प्रसारण करने की अनुमति देगा।

— कैस्परल्ड