遅延の増加の原因を見つける方法は？

私たちのオフィスのいくつかのデバイスで監視設定をしました。小さなアクセススイッチに対するpingの応答時間は通常1〜4ミリ秒です。午前3時の時点で、これは平均で300ミリ秒に急上昇しています。

このような状況でどこから探し始めますか？遅延の原因を見つけるために、スイッチで何を観察できますか？

注：これは負荷関連ではありません。すべてのリンク帯域幅の使用量は通常で影響を受けず、ほとんどのリンクは非常に活用されていません。また、監視は遅延を報告するデバイスに対してローカルであるため、ここにはWANの要因はありません。

まず、待ち時間は帯域幅に直接結び付けられていません。デバイスが輻輳したリンク以外のパケットを遅延させる理由はたくさんあります。

tracerouteを試みましたか？疑わしいとしてL3境界を探している場合、これはホップ間の待ち時間を示します。

また、パス内のデバイスのいずれかがCPU / RAMを大量に使用しているかどうかを確認することもできます。

これがLANだけに基づいている場合、何が原因でこれを引き起こしているのかを調べるために始めることができるいくつかのことがあります。

• show process cpu historyコマンド：CPU使用率が非常に高い場合、どのプロセスがこれを引き起こしているかを確認する必要があります。

• show debugコマンド：私が見つけた一般的な原因は、デバッグコマンドをスイッチで実行したままにしておく人々です。よく使用されるのは、すでに過剰に使用されているデバイスにIPアカウンティングが残っていることです。「undebug all」を使用して、デバッグを取り除きます。

• 再起動してください：おそらく日中はないかもしれませんが、「reload in」コマンドを使用して夜間または週末に時間を計ってください。クイックリブートで修正できる問題の数に驚くことでしょう。

• トランクポートのシャットダウン -L3スイッチの場合、私が見たもう1つの一般的な問題は、VLAN間のルーティングにこのデバイスを使用するトラフィックが多すぎることです。可能であれば、トランクポートの一部を一時的に閉じて、遅延が減少するかどうかを確認します。

レイテンシーに関して、またCPUによって処理されている場合、pingの優先度は低いことに注意してください。また、QoS設定を再確認し、これを引き起こす愚かな間違いがないことを確認することをお勧めします。

cactiを使用して帯域幅を監視し、openNMSを使用して遅延を監視します。このスイッチにリンクされているすべてのデバイスを監視している場合、使用量と遅延の間に結果が生じる場合があります。（帯域幅の問題ではないとおっしゃったことは知っていますが、今は決してありません）使用量が多いとローエンドスイッチが低下し、多くの遅延が発生することがあります。このスイッチが多くのトラフィックを通過させていなくても、このスイッチに電力を供給する「ダム」デバイスがありますか。また、cactiを使用すると、CPU使用率をポーリングできる場合があり、レイテンシー時にスパイクが発生する場合があります。

前述のように、MTRまたはneotraceは状況を監視するのにも役立ち、このスイッチ自体ではない可能性があるレイテンシーの開始点を確認できます。

これがLAN上で発生しない場合は、「WANポート」スループットを制限できます。これにより、より良いTDMが強制されます。最大スループットの約80％を試して、それが役立つかどうかを確認してください。端末の量に応じてtweekする必要があるかもしれません。