วิธีการค้นหาแหล่งที่มาของความล่าช้าที่เพิ่มขึ้น?

14

ฉันได้รับการตรวจสอบการตั้งค่าบนอุปกรณ์หลายเครื่องในสำนักงานของเรา เวลาตอบสนองการปิงไปยังสวิตช์การเข้าถึงขนาดเล็กโดยทั่วไปแล้วจะอยู่ที่ 1-4ms ... เมื่อเวลา 3 โมงเช้าวันนี้สิ่งนี้มีค่าเฉลี่ยสูงถึง 300 มิลลิวินาที

ใครจะเริ่มมองในสถานการณ์เช่นนี้? ฉันสามารถสังเกตสิ่งใดบ้างในสวิตช์เพื่อค้นหาแหล่งที่มาของความล่าช้า

หมายเหตุ: มันไม่เกี่ยวข้องกับการโหลด .. การใช้แบนด์วิธลิงก์ทั้งหมดเป็นเรื่องปกติและไม่ได้รับผลกระทบลิงค์ส่วนใหญ่จะใช้งานน้อยมาก นอกจากนี้ - การตรวจสอบอยู่ในอุปกรณ์ที่รายงานความล่าช้าดังนั้นจึงไม่มีปัจจัย WAN ที่นี่

latency

— อลาบาม่า
แหล่งที่มา

3

สมมติว่านี่เป็นสวิตช์ Cisco IOS ... โปรดโพสต์show proc cpu historyสำหรับสวิตช์ที่มีค่า ping สูง หาก CPU นั้นสูงอย่างต่อเนื่องหรือเร็วสูงเป็นประจำให้รันshow proc cpu sort

— Mike Pennington

เวลาในการตอบสนองต่อสวิตช์ควบคุมเครื่องบินหรือคุณมีเวลาแฝงเท่ากันเมื่อคุณ ping บางสิ่งที่อยู่ด้านหลังสวิตช์หรือไม่

— ytti

@MikePennington - imgur.com/a/gfX9q#0 - มันเจ๋งมาก! ดูเหมือนว่ามันจะสูงขึ้นอย่างต่อเนื่อง แต่โดยเฉลี่ยแล้วมันต่ำ ..

— อัล

@Ytti - ไม่ได้ตั้งใจที่จะโพสต์สิ่งนี้ในบรรทัดที่แยกต่างหาก .. อย่างไรก็ตาม - ดังนั้นฉันจึงขุดลึกลงไปในนี้ cp <-> การตอบสนอง cp ต่ำจริง ๆ จากการกระจายการเข้าถึงหรืออย่างน้อยก็ในเวลาที่ฉันทดสอบ จากพอร์ตระดับการเข้าถึงไปยังอุปกรณ์บนสวิตช์เลเยอร์การเข้าถึงเป็นจุดที่เราเห็นว่าเวลาแฝงที่รุนแรง

— อัล

@ user1353 ขอขอบคุณ ... ว่า imgur ที่คุณโพสต์ไม่สูงพอที่จะทำให้เวลา ping เพิ่มขึ้นอย่างต่อเนื่องจาก CPU บนสวิตช์นั้น

— Mike Pennington

6

อย่างแรกเวลาแฝงไม่ได้เชื่อมโยงกับแบนด์วิดท์โดยตรง มีสาเหตุหลายประการที่ทำให้อุปกรณ์ล่าช้าแพ็คเก็ตอื่นที่ไม่ใช่ลิงค์ที่แออัด

คุณเคยลองใช้ traceroute หรือไม่? นี่จะแสดงเวลาแฝงระหว่างฮ็อปถ้าคุณกำลังมองหาขอบเขต L3 ในฐานะผู้ต้องสงสัย

คุณอาจตรวจสอบเพื่อดูว่าอุปกรณ์ใดในพา ธ มีการใช้งาน CPU / RAM อย่างมีนัยสำคัญ

— Mierdin
แหล่งที่มา

ฉันจะเห็นด้วยกับ Mierdin และยังแนะนำให้ใช้ MTR สำหรับติดตาม traceroute ในสถานการณ์เช่นนี้ ลิงค์ Wikipedia: en.m.wikipedia.org/wiki/MTR_(software)

— Brett Lykins

@Mierdin - ขอบคุณสำหรับความคิดเห็นของคุณดังนั้นจึงไม่มีปัจจัย L3 ที่นี่ traceroute แสดงการตอบสนองที่สูงในขั้นต้นประมาณ 500ms จากนั้น 260ms จากนั้น 76ms มาถึงอุปกรณ์ - เหล่านี้สำหรับการลองเดี่ยว hop เดียวไม่ใช่สำหรับหลาย ๆ ฮ็อพ ดูความคิดเห็นของฉันที่ MikePennington สำหรับข้อมูลที่เกี่ยวข้องกับ CPU

— AL

3

หากสิ่งนี้ขึ้นอยู่กับ LAN มีบางสิ่งที่คุณสามารถทำได้เพื่อเริ่มและลองค้นหาสิ่งที่ทำให้เกิดสิ่งนี้:

แสดงคำสั่งประวัติซีพียูกระบวนการ : หากการใช้งาน CPU สูงมากคุณต้องดูว่ากระบวนการใดที่ทำให้เกิดปัญหานี้และอาจกระทบ google ด้วยกระบวนการที่ขัดข้อง
show debug command: สาเหตุที่พบโดยทั่วไปคือผู้ที่ออกจากคำสั่ง debug ที่ทำงานบนสวิตช์ รายการโปรดที่พบบ่อยคือการบัญชี IP ที่ถูกทิ้งไว้ในอุปกรณ์ที่ใช้งานเกินความจำเป็น ใช้ "undebug all" เพื่อกำจัด debugs
ให้มันรีบูต : อาจไม่ได้ในระหว่างวัน แต่ใช้คำสั่ง "โหลดใน" เพื่อเวลามันในเวลากลางคืนหรือวันหยุดสุดสัปดาห์ คุณจะประหลาดใจที่มีปัญหามากมายที่การรีบูตอย่างรวดเร็วสามารถแก้ไขได้
ปิดช่องพอร์ต - ถ้าเป็นสวิตช์ L3 ปัญหาทั่วไปอีกอย่างที่ฉันเคยเห็นคือทราฟฟิกมากเกินไปโดยใช้อุปกรณ์นี้สำหรับการกำหนดเส้นทางระหว่าง VLAN ถ้าเป็นไปได้ให้ปิดพอร์ต trunk บางพอร์ตชั่วคราวเพื่อดูว่าจะช่วยลดเวลาในการตอบสนองหรือไม่

มันเป็นเรื่องดีที่จะทราบว่าการปิงของคุณมีลำดับความสำคัญต่ำในแง่ของเวลาแฝงและเมื่อประมวลผลโดยซีพียู อาจเป็นความคิดที่ดีที่จะตรวจสอบการตั้งค่า QoS ของคุณอีกครั้งและตรวจสอบให้แน่ใจว่าไม่มีข้อผิดพลาดใด ๆ ที่ทำให้เกิดความผิดพลาด

— Artanix
แหล่งที่มา

ข้อเสนอแนะที่ยอดเยี่ยมฉันได้ตรวจสอบการแสดงข้อบกพร่องแล้วและไม่สามารถรีบูตได้ในขณะนี้

— อัล

2

ฉันใช้ cacti เพื่อตรวจสอบแบนด์วิดธ์และ openNMS เพื่อตรวจสอบเวลาแฝง หากคุณกำลังตรวจสอบอุปกรณ์ทั้งหมดที่เชื่อมโยงกับสวิตช์นี้คุณอาจเห็นข้อพิสูจน์ระหว่างการใช้งานและเวลาแฝง (ฉันรู้ว่าคุณบอกว่ามันไม่ใช่ปัญหาแบนด์วิดธ์ แต่คุณไม่เคยตอนนี้) ฉันได้เห็นสวิทช์ลดลงต่ำกว่าการใช้งานหนักซึ่งทำให้เกิดความล่าช้ามาก คุณมีอุปกรณ์ "ใบ้" ใด ๆ ที่ส่งสวิตช์นี้ซึ่งอาจเป็นแหล่งที่มาของการลดลงแม้ว่าสวิตช์นี้จะไม่ผ่านการรับส่งข้อมูลจำนวนมาก นอกจากนี้สำหรับ cacti คุณสามารถสำรวจการใช้งาน CPU และคุณอาจเห็นขัดขวางในเวลาแฝง

ดังกล่าวข้างต้น MTR หรือ neotrace ยังมีประโยชน์ในการจับตาดูสถานการณ์และคุณอาจเห็นว่าเวลาแฝงเริ่มต้นซึ่งอาจไม่ใช่สวิตช์นี้เอง

— เบลค
แหล่งที่มา

0

หากสิ่งนี้ไม่ได้เกิดขึ้นบน LAN คุณสามารถ จำกัด "พอร์ต wan" ผ่าน throghtput สิ่งนี้จะบังคับ TDM ที่ดีกว่า ลองใช้สิ่งต่าง ๆ 80% ของปริมาณงานสูงสุดของคุณและดูว่าช่วย คุณอาจจำเป็นต้อง tweek ขึ้นอยู่กับจำนวนของอาคาร

— user41897
แหล่งที่มา

ตามที่ฉันเข้าใจ OP ได้ระบุไว้อย่างชัดเจนในหมายเหตุว่านี่ไม่เกี่ยวข้องกับการโหลด