Як знайти джерело підвищеної затримки?

У нас в офісі встановлено моніторинг на декількох пристроях. Час відгуку на пінг на невеликі комутатори доступу зазвичай становить 1-4 мс ... Станом на 3 ранку сьогодні вранці це зросло в середньому до 300 мс.

Звідки хтось починає шукати подібну ситуацію? Які речі я можу спостерігати в комутаторі, щоб знайти джерело затримки?

ПРИМІТКА. Це не пов’язано з навантаженням. Використання пропускної здатності посилань є нормальним і не впливає, більшість посилань дуже не використовуються. Також - моніторинг локальний для пристроїв, що повідомляють про затримку, тому тут немає фактора WAN.

По-перше, затримка не пов'язана безпосередньо з пропускною здатністю. Існує багато причин, чому пристрій затримує пакет, окрім перевантаженого зв'язку.

Чи намагалися ви простежити трасування? Це покаже вам затримку між хмелем, якщо ви шукаєте межу L3 як підозрюваний.

Ви також можете перевірити, чи який-небудь з пристроїв на шляху значно використовує процесор / оперативну пам’ять.

якщо це лише засновано на локальній мережі, є кілька речей, які ви можете зробити для початку, щоб спробувати і з'ясувати, що викликає це:

• Показати команду історії процесора процесора : якщо використання процесора дуже велике, вам потрібно побачити, який процес спричиняє це, і, можливо, вдарив google з порушенням процесу.

• показати команду налагодження : поширена причина, яку я знайшов - це люди, які залишають команди налагодження, що працюють на комутаторі. Поширеним фаворитом було облік ІР на пристроях, які вже надто використовувались. Використовуйте "undebug all", щоб позбутися від налагоджень.

• Дайте йому перезавантаження : можливо, не вдень, але використовуйте команду "reload in", щоб розмістити її вночі або у вихідні. Ви здивуєтеся, скільки проблем може виправити швидке перезавантаження.

• закриті магістральні порти - якщо це перемикач L3, ще одна поширена проблема, яку я бачив, - це занадто великий трафік, що використовує цей пристрій для маршрутизації між VLAN. Якщо можливо, тимчасово закрийте деякі порти магістралі, щоб перевірити, чи зменшує це затримка.

Добре знати, що ваші пінг-класи мають низький пріоритет, що стосується затримки, а також під час обробки процесором. Можливо, також буде хорошою ідеєю перевірити свої налаштування QoS і переконатися, що немає дурних помилок, що викликають це, наскільки це малоймовірно.

Я використовую кактуси для контролю пропускної здатності, а openNMS - для контролю затримки. Якщо ви контролюєте всі пристрої, підключені до цього комутатора, ви можете побачити наслідки між використанням та затримкою. (я знаю, ви сказали, що це не проблема пропускної здатності, але ви ніколи не буваєте) Я бачив, як комутатори нижнього класу провисають при великому використанні, що спричиняє багато затримок. Чи є у вас якісь "німі" пристрої, що живлять цей перемикач, які можуть бути джерелом провисання, навіть якщо цей комутатор не пропускає багато трафіку. Також з кактусами ви зможете опитати використання процесора, а під час затримки ви можете побачити шип.

Як згадувалося вище, MTR або неотрицання також корисні для спостереження за ситуацією, і ви можете побачити, звідки починається затримка, що може не бути саме цим перемикачем.

Якщо цього не відбувається в локальній мережі, ви можете обмежити потужність "wan port", це призведе до кращого TDM. Спробуйте щось приблизно на 80% від максимальної пропускної здатності і подивіться, чи це допомагає. Можливо, вам доведеться налаштувати в залежності від кількості клем.