昨日のRTX1200のNATの数をSystemAnswerG2の統計グラフに取り込んで表示する方法をやりましたが、早速おいしいグラフ描画になりました。
判りやすくするためにCPUとNATマスカレードカウントとそのインターフェースのトラフィックLAN2を並べてみました。
まずAのポイントですが、トラフィックとCPUの動きと、NATカウントに注目です。こういった波形は大きなファイルをダウンロードまたはアップロードした時に現れます。ただしこの傾向はRTX1200まででRTX1210ではここまでハッキリとは判らないかと思います。CPU性能の兼ね合いと、どうやらYAMAHAルーターは「特定の挙動に対して弱い（負荷があがる）」ようなんですね。RTX系と纏めちゃってはいますが仕様がボチボチ違ったりするので、RTX1000からRTX1210まで、全て同じ条件での負荷を掛けても結果は違ってくると思います。ただ、全般的に今回のグラフの結果は特有の癖が出ている感じです。
Bの区域も同様にパッと見はCPUとNATカウントのグラフが似た感じで推移していますが、実際にはちょっち違いますね。トラフィックとの波形とも噛み合いません。でもCPUの盛り上がりの原因はとりあえずNATセッション数に近い形で推移しているのが判りました。
このグラフから言いたいのは、CPUとトラフィックだけしか見えない場合に、トラフィックの状況からしてCPUの波形は理解に苦しむと思います。巷ではRTXはショー○パケッ○に弱いとか言われていたりしますが・・・ま、それは置いておいて、CPUが仮に６０％を超えてきた場合に、トラフィックが上図のような波形では説明が出来ないと思うんですよね。何が原因でCPU負荷が上がっているのかをCPUとトラフィックだけでは表現が出来ないのです。
またデータの形態によってCPUが瞬間上昇している訳ですから、このデータ特性が大量に飛び込んで来たらCPUは悲鳴を上げるでしょう。でもそのデータ特性をどうやって見抜くかはやはりNATセッション情報があると初期判断材料としては少しだけ読みやすくなりますね。
しかし酷いっすねぇ～。１５００セッションありながらトラフィックが１０M超えてないんですよｗ これはまた別の角度のデータが必要なのですが、DNSクエリーの増加がまずあります。とあるクラウド製品を使うと1台あたりのセッション数が3倍から5倍になるというぐらいですからね～。昔なら間違いなくウィルスが発病した時の傾向グラフでしたね[E:coldsweats02]。
あとですね、インターネット回線側によってのセッション数ってのもはあったりしますんで・・・そこの話はいずれ。。。
で、グラフを見てもふんづまりが判らないなぁ・・・となってくると・・・RTXで見なくちゃならないのが、以下のコマンドです。
RTX1200>show status packet-buffer
small group: 152 bytes length（割愛）
middle group: 600 bytes length（割愛）
large group: 2048 bytes length
parameters: max-buffer=10000 max-free=5312 min-free=62
buffer-in-chunk=625 init-chunk=8
4423 buffers in free list
577 buffers are allocated, req/succ/fail/rel = XXXX616955/XXXX614963/1992/XXX
X614386
8 chunks are allocated, req/succ/fail/rel = 8/8/0/0
huge group: 65664 bytes length（割愛）
あらーら・・・パケロスしてますね。。。いつパケロスしたんだろ（激汗）。
量的には大した数ではないと言いたいけど、気になるよねぇ～。
ここの値もSNMPで見られないのかなぁ・・・。
と、いうことで今回はちょっとコッテリした内容かもしれませんがご参考になれば。
