지연 시간이 증가한 원인을 찾는 방법은 무엇입니까?

사무실의 여러 장치에 모니터링 설정이 있습니다. 소형 액세스 스위치에 대한 핑 응답 시간은 일반적으로 1-4ms입니다 ... 오늘 오전 3시 현재, 평균 300ms로 급등했습니다.

이런 상황에서 어디를 살펴보기 시작합니까? 대기 시간의 원인을 찾기 위해 스위치에서 무엇을 관찰 할 수 있습니까?

참고 :로드와 관련이 없습니다. 모든 링크 대역폭 사용량은 정상이며 영향을받지 않으며 대부분의 링크는 많이 사용되지 않습니다. 또한 모니터링은 대기 시간을보고하는 장치에 대해 로컬이므로 WAN 요소는 없습니다.

첫째, 대기 시간은 대역폭과 직접 관련이 없습니다. 장치가 혼잡 한 링크 이외의 패킷을 지연시키는 데는 여러 가지 이유가 있습니다.

당신은 traceroute를 시도 했습니까? L3 경계를 용의자로 찾고 있다면 홉 간의 대기 시간이 표시됩니다.

경로에있는 장치 중 CPU / RAM의 사용량이 많은 장치가 있는지 확인할 수도 있습니다.

이것이 LAN을 기반으로하는 것이라면,이 문제의 원인을 찾기 위해 시작할 수있는 몇 가지 방법이 있습니다.

• process cpu history 명령 표시 : CPU 사용량이 매우 높은 경우 어떤 프로세스가이 프로세스를 일으키는 지 확인하고 문제가있는 프로세스로 google을 누르십시오.

• show debug command : 내가 찾은 일반적인 원인은 스위치에서 디버그 명령을 실행하는 사람들입니다. 가장 많이 사용되는 방법은 이미 과도하게 사용 된 장치에 IP 계정이 남아 있다는 것입니다. 디버그를 제거하려면 "undebug all"을 사용하십시오.

• 다시 부팅하십시오 . 아마도 낮에는 가능하지 않지만 "reload in"명령을 사용하여 밤이나 주말에 시간을 정하십시오. 빠른 재부팅으로 해결할 수있는 문제의 수에 놀랄 것입니다.

• 트렁크 포트 종료 -L3 스위치 인 경우, 내가 본 또 다른 일반적인 문제는 VLAN간에 라우팅하기 위해이 장치를 사용하는 트래픽이 너무 많다는 것입니다. 가능하면 일부 트렁크 포트를 일시적으로 종료하여 대기 시간이 감소하는지 확인하십시오.

대기 시간과 CPU에 의해 처리 될 때 핑의 우선 순위가 낮다는 점에 유의하십시오. QoS 설정을 다시 확인하고 이로 인해 발생 가능한 어리석은 실수가 없는지 확인하는 것이 좋습니다.

선인장을 사용하여 대역폭을 모니터링하고 openNMS를 사용하여 대기 시간을 모니터링합니다. 이 스위치에 연결된 모든 장치를 모니터링하는 경우 사용량과 대기 시간이 일치 할 수 있습니다. (대역폭 문제는 아니라고 말했지만 지금은 결코 본 적이 없습니다.) 사용량이 많을 때 로우 엔드 스위치가 처지는 것을 보았으므로 대기 시간이 많이 발생합니다. 이 스위치가 많은 트래픽을 전달하지 않더라도이 스위치를 공급하는 "멍청한"장치가 처짐의 원인이 될 수 있습니다. 또한 cacti를 사용하면 CPU 사용량을 폴링 할 수 있으며 대기 시간에 급증 할 수 있습니다.

위에서 언급했듯이 MTR 또는 neotrace는 상황을 주시하는 데 유용하며 대기 시간이 시작되는 위치를 확인할 수 있습니다.이 스위치 자체가 아닐 수도 있습니다.

LAN에서 이러한 상황이 발생하지 않으면 "wan port"처리량을 제한 할 수 있으므로 더 나은 TDM이 적용됩니다. 최대 처리량의 80 % 정도를 시도해보고 도움이되는지 확인하십시오. 터미널 수에 따라 tweek가 필요할 수 있습니다.