बढ़ी हुई विलंबता के स्रोत को कैसे खोजें?

14

मुझे हमारे कार्यालय में कई उपकरणों पर निगरानी सेटअप मिला है। छोटे अभिगम स्विच के लिए पिंग प्रतिक्रिया समय आमतौर पर 1-4ms है ... आज सुबह 3AM के रूप में, इसने औसतन 300ms तक आसमान छू लिया है।

इस तरह की स्थिति में कोई कहां देखना शुरू करता है? विलंबता के स्रोत को खोजने के लिए मैं किन चीजों को स्विच में देख सकता हूं?

नोट: यह लोड से संबंधित नहीं है .. सभी लिंक बैंडविड्थ का उपयोग सामान्य और अप्रभावित है, अधिकांश लिंक बहुत उपयोग में हैं। इसके अलावा - निगरानी विलंबता की रिपोर्ट करने वाले उपकरणों के लिए स्थानीय है, इसलिए यहां कोई वैन कारक नहीं है।

latency

— AL
स्रोत

3

यह एक सिस्को IOS स्विच है मान लें ... कृपया show proc cpu historyउच्च पिंग-बार के साथ स्विच के लिए पोस्ट करें । यदि वह सीपीयू लगातार उच्च है, या नियमित रूप से उच्च स्पाइकिंग है, तो चलाएंshow proc cpu sort

— माइक पेनिंगटन

क्या स्विच कंट्रोल-प्लेन की ओर केवल विलंबता है या स्विच के पीछे कुछ पिंग करने पर आपको वही विलंबता मिलती है?

— यति

@MikePennington - imgur.com/a/gfX9q#0 - यह बहुत अच्छा है! ऐसा लग रहा है कि यह लगातार उच्च ऊपर उठता है, हालांकि औसतन कम है ..

— AL

@ यति - इसका मतलब यह नहीं था कि इसे एक अलग लाइन पर पोस्ट किया जाए .. वैसे भी - इसलिए मैंने इसमें गहराई तक खोद डाला। cp <-> cp प्रतिक्रिया वास्तव में वितरण से एक्सेस तक कम है, या कम से कम उस समय जब मैंने परीक्षण किया था। एक एक्सेस लेवल पोर्ट से लेकर एक्सेस लेयर स्विच तक के डिवाइस हैं, जहाँ हम चरम विलंबता देख रहे हैं।

— AL

@ user1353, धन्यवाद ... उस imgur जिसे आपने पोस्ट किया है वह लगातार इतना अधिक नहीं है कि उस स्विच पर सीपीयू से लगातार बढ़े हुए पिंग बार

— माइक पेनिंगटन

6

सबसे पहले, विलंबता सीधे बैंडविड्थ से बंधा नहीं है। कई कारण हैं कि एक डिवाइस एक भीड़भाड़ वाले लिंक के अलावा एक पैकेट में देरी क्यों करेगा।

क्या आपने ट्रेसरआउट का प्रयास किया है? यदि आप एक संदिग्ध के रूप में एक L3 सीमा की तलाश कर रहे हैं, तो यह आपको हॉप्स के बीच विलंबता दिखाएगा।

आप यह देखने के लिए भी जांच कर सकते हैं कि क्या पथ के किसी भी उपकरण में CPU / RAM का महत्वपूर्ण उपयोग है या नहीं।

— Mierdin
स्रोत

मैं Mierdin के साथ सहमत होगा और इस तरह की स्थिति में लगातार एक अनुरेखक चलाने के लिए MTR की सिफारिश भी करता है। विकिपीडिया लिंक: en.m.wikipedia.org/wiki/MTR_(software)

— ब्रेट लिकिंस

@ मायएर्डिन - आपकी प्रतिक्रिया के लिए धन्यवाद, इसलिए यहां कोई एल 3 कारक नहीं है, ट्रेसरआउट ने शुरू में लगभग 500ms की उच्च प्रतिक्रिया दिखाई है, फिर 260ms, फिर 76ms डिवाइस पर आ रहे हैं - ये एक ही हॉप पर प्रत्येक प्रयास के लिए हैं, एकाधिक के लिए नहीं हॉप्स। सीपीयू संबंधित जानकारी के लिए माइकपेनिंगटन को मेरी टिप्पणी देखें।

— AL

3

यदि यह सिर्फ LAN पर आधारित है, तो कुछ चीजें हैं जिन्हें आप शुरू करने की कोशिश कर सकते हैं और पता लगा सकते हैं कि यह क्या कारण है:

शो प्रक्रिया सीपीयू इतिहास कमांड: यदि सीपीयू का उपयोग बहुत अधिक है, तो आपको यह देखने की आवश्यकता है कि कौन सी प्रक्रिया यह पैदा कर रही है और शायद आक्रामक प्रक्रिया के साथ Google को मारा।
डिबग कमांड दिखाएँ : एक सामान्य कारण जो मैंने पाया है कि स्विच पर चल रहे डिबग कमांड को लोग छोड़ रहे हैं। एक आम पसंदीदा आईपी लेखांकन उन उपकरणों पर छोड़ा जा रहा था जो पहले से ही उपयोग में थे। डिबग से छुटकारा पाने के लिए "सभी को अंडरबग करें" का उपयोग करें।
इसे एक रिबूट दें : संभवतः दिन के दौरान नहीं, लेकिन रात में या सप्ताहांत में "रीलोड" कमांड का उपयोग करें। आपको आश्चर्य होगा कि एक त्वरित रिबूट कितने मुद्दों को ठीक कर सकता है।
शटडाउन पोर्ट्स - यदि इसका L3 स्विच है, तो एक और सामान्य समस्या जो मैंने देखी है वह है VLANs के बीच रूटिंग के लिए इस डिवाइस का उपयोग करके बहुत अधिक ट्रैफ़िक। यदि संभव हो, तो यह देखने के लिए अस्थायी रूप से कुछ ट्रंक पोर्ट बंद करें कि क्या यह विलंबता को कम करता है।

यह अच्छा है कि अपने पिंग कम प्राथमिकता है, विलंबता के संबंध में और सीपीयू द्वारा संसाधित होने पर भी। अपनी QoS सेटिंग को दोबारा जांचने और यह सुनिश्चित करने के लिए एक अच्छा विचार हो सकता है कि इसके कारण कोई मूर्खतापूर्ण गलती नहीं है, जितना कि यह संभावना नहीं है।

— Artanix
स्रोत

शानदार प्रतिक्रिया, मैंने पहले ही शो डिबग की जाँच कर ली थी, और इस समय रिबूट संभव नहीं है।

— AL

2

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

जैसा कि ऊपर उल्लेख किया गया है, एमटीआर या नीओट्रेस भी स्थिति पर नज़र रखने के लिए उपयोगी होते हैं और आप देख सकते हैं कि विलंबता कहाँ से शुरू होती है, जो शायद यह स्विच नहीं है।

— ब्लेक
स्रोत

0

यदि यह LAN पर नहीं हो रहा है, तो आप "wan port" को थ्रौथपुट सीमित कर सकते हैं, यह एक बेहतर TDM को बल देगा। अपने मैक्सिमम थ्रूपुट के 80% के आसपास कुछ करने की कोशिश करें और देखें कि क्या यह मदद करता है। टर्मिनलों की मात्रा के आधार पर आपको ट्विक करने की आवश्यकता हो सकती है।

— user41897
स्रोत

जैसा कि मैं समझता हूं कि ओपी ने नोट में स्पष्ट रूप से कहा है कि यह लोड से संबंधित नहीं है।