Bagaimana menemukan sumber latensi yang meningkat?


14

Saya punya pengaturan pemantauan pada beberapa perangkat di kantor kami. Waktu respons ping ke sakelar akses kecil biasanya 1-4ms ... Pada pukul 3 pagi ini, ini meroket hingga 300 ms.

Di mana orang mulai mencari dalam situasi seperti ini? Hal-hal apa yang dapat saya amati dalam sakelar untuk menemukan sumber latensi?

CATATAN: Ini tidak terkait dengan beban .. semua penggunaan bandwidth tautan normal dan tidak terpengaruh, sebagian besar tautan sangat kurang dimanfaatkan. Juga - pemantauan bersifat lokal untuk perangkat yang melaporkan latensi sehingga tidak ada faktor WAN di sini.


3
Dengan asumsi ini adalah switch Cisco IOS ... Silakan posting show proc cpu historyuntuk switch dengan ping-kali yang tinggi. Jika CPU itu secara konsisten tinggi, atau melonjak tinggi secara teratur, jalankanshow proc cpu sort
Mike Pennington

Apakah latensi hanya mengarah ke bidang kontrol sakelar atau apakah Anda mendapatkan latensi yang sama saat Anda melakukan ping sesuatu di belakang sakelar?
ytti

@MikePennington - imgur.com/a/gfX9q#0 - ini sangat keren! Sepertinya itu melonjak cukup tinggi secara konsisten meskipun rata-rata rendah ..
AL

@ Ytti - tidak bermaksud memposting ini pada baris terpisah .. pokoknya - Jadi saya menggali lebih dalam tentang ini. cp <-> respon cp sebenarnya rendah dari distribusi hingga akses, atau setidaknya pada saat saya diuji. Dari port level akses ke perangkat pada switch lapisan akses adalah tempat kita melihat latensi ekstrem.
AL

@ user1353, terima kasih ... imgur yang Anda posting tidak secara konsisten cukup tinggi untuk menyebabkan waktu ping yang meningkat secara konsisten dari CPU pada sakelar itu
Mike Pennington

Jawaban:


6

Pertama, latensi tidak terkait langsung dengan bandwidth. Ada banyak alasan mengapa perangkat akan menunda paket selain tautan yang macet.

Sudahkah Anda mencoba traceroute? Ini akan menunjukkan kepada Anda latensi antar hop, jika Anda mencari batas L3 sebagai tersangka.

Anda mungkin juga memeriksa untuk melihat apakah ada perangkat di jalur memiliki penggunaan CPU / RAM yang signifikan.


Saya setuju dengan Mierdin dan juga merekomendasikan MTR untuk terus menjalankan traceroute dalam situasi seperti ini. Tautan Wikipedia: en.m.wikipedia.org/wiki/MTR_(software)
Brett Lykins

@Mierdin - Terima kasih atas umpan balik Anda, jadi tidak ada faktor L3 di sini, traceroute menunjukkan respons awalnya tinggi sekitar 500ms, kemudian 260ms, kemudian 76ms tiba di perangkat - ini untuk setiap percobaan pada satu hop yang sama, bukan untuk beberapa hop Lihat komentar saya untuk MikePennington untuk info terkait CPU.
AL

3

jika ini hanya berdasarkan pada LAN, ada beberapa hal yang dapat Anda lakukan untuk memulai untuk mencoba dan mencari tahu apa penyebabnya:

  • Tampilkan perintah proses cpu history : jika penggunaan CPU sangat tinggi, maka Anda perlu melihat proses yang menyebabkan ini dan mungkin menekan google dengan proses yang menyinggung.

  • tampilkan perintah debug : penyebab umum yang saya temukan adalah orang-orang meninggalkan perintah debug yang berjalan di sakelar. Favorit umum adalah akuntansi IP yang dibiarkan di perangkat yang sudah digunakan secara berlebihan. Gunakan "undebug all" untuk menyingkirkan debug.

  • Berikan reboot : mungkin tidak mungkin di siang hari, tetapi gunakan perintah "reload in" untuk mengatur waktu di malam hari atau akhir pekan. Anda akan terkejut betapa banyak masalah yang bisa diperbaiki dengan reboot cepat.

  • shut trunk ports - Jika ini merupakan L3 switch, masalah umum lain yang saya lihat adalah terlalu banyak lalu lintas menggunakan perangkat ini untuk routing antara VLAN. Jika memungkinkan, matikan sementara beberapa port trunk untuk melihat apakah ini mengurangi latensi.

Sangat baik untuk menyadari bahwa ping Anda adalah prioritas rendah, dalam hal latensi dan juga ketika sedang diproses oleh CPU. Mungkin juga merupakan ide bagus untuk memeriksa ulang pengaturan QoS Anda dan memastikan tidak ada kesalahan konyol yang menyebabkan hal ini, sebanyak itu tidak mungkin.


Umpan balik yang bagus, saya sudah memeriksa acara debug, dan reboot tidak mungkin saat ini.
AL

2

Saya menggunakan kaktus untuk memonitor bandwidth, dan openNMS untuk memantau latensi. Jika Anda memantau semua perangkat yang terhubung ke sakelar ini, Anda mungkin melihat konsekuensi wajar antara penggunaan dan latensi. (saya tahu Anda mengatakan itu bukan masalah bandwidth, tetapi Anda tidak pernah sekarang) Saya telah melihat switch low-end melorot di bawah penggunaan yang berat, yang menyebabkan banyak latensi. Apakah Anda memiliki perangkat "bisu" yang memberi makan sakelar ini yang mungkin menjadi sumber penurunan meskipun sakelar ini tidak melewati banyak lalu lintas. Juga dengan kaktus Anda mungkin dapat polling penggunaan CPU, dan Anda mungkin melihat lonjakan pada saat latensi.

Seperti disebutkan di atas, MTR atau neotrace juga berguna untuk mengawasi situasi dan Anda dapat melihat di mana latensi dimulai, yang mungkin bukan saklar ini sendiri.


0

Jika ini tidak terjadi pada LAN, Anda dapat membatasi "wan port" throghtput, ini akan memaksa TDM yang lebih baik. Cobalah sesuatu di sekitar 80% dari throughput maximun Anda dan lihat apakah itu membantu. Anda mungkin perlu tweek tergantung jumlah terminal.


Seperti yang saya pahami OP telah dengan jelas dinyatakan dalam catatan, bahwa ini tidak terkait beban.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.