ルータのCPUやメモリを確認するとき、まず何が分かればいいのか
ルータのリソース使用状況を確認したい人が本当に知りたいのは、単に「CPU使用率を見るコマンド」ではありません。知りたいのは、今の機器が本当に重いのか、重いなら何が原因らしいのか、放置でよいのか、いますぐ対応すべきなのかです。
そこでこの記事では、Cisco IOS/IOS-XE系ルータとFortiGateを中心に、CPU・メモリ・セッション・プロセスの見方を、コマンド例、見るべきポイント、異常の切り分け順まで含めて整理します。単なるコマンド一覧ではなく、現場で実際にどう読むかに寄せて解説します。
先に結論を言うと、CPUやメモリは1つの数値だけ見ても判断を誤りやすいです。重要なのは次の4点です。
- 瞬間値ではなく継続して高いか
- どのプロセス・機能が食っているか
- セッション増加やトラフィック増加と一致しているか
- 通信断、遅延、管理画面遅延など実害があるか
逆に、CLIでCPU 90%と出た瞬間だけ見て「故障だ」と決めつけるのは危険です。高負荷には、正常な一時負荷と、明らかに危険な継続負荷の両方があります。
最初に見るべき確認順序｜いきなり詳細コマンドを打たない
現場でありがちなのが、いきなり細かいプロセス一覧を見て迷子になることです。まず全体像をつかみ、その後に深掘りした方が速く、判断も外しにくいです。
| 確認順序 | 何を見るか | 主なコマンド例 | 目的 |
|---|---|---|---|
| 1 | CPU全体使用率 | Cisco: show processes cpu sorted FortiGate: get system performance status |
本当に機器全体が重いか確認する |
| 2 | メモリ全体 | Cisco: show memory statistics FortiGate: diagnose hardware sysinfo memory |
不足や枯渇傾向がないか確認する |
| 3 | プロセス別使用状況 | Cisco: show processes cpu sorted / show processes memory sorted FortiGate: diagnose sys top |
どの処理が負荷を出しているか絞る |
| 4 | トラフィック・セッション | Cisco: show interfaces / show ip traffic FortiGate: get system session status |
負荷の背景に通信増加があるか見る |
| 5 | ログ・イベント | show logging / FortiGate event log | 異常動作、再起動、エラー多発の有無を確認する |
この順序にすると、単なる一時的な高負荷なのか、継続的に危険な状態なのかを見分けやすくなります。逆に、CPUが高いという一点だけで「回線障害」「機器故障」「帯域不足」と決めるのは早計です。
まず押さえるべき判断基準｜CPUとメモリは何%なら危険か
「CPU何%なら危険ですか」とよく聞かれますが、これは機種、役割、機能、平常時の負荷で変わります。とはいえ、現場の目安がないと判断しづらいので、最低限の見方を表にします。
| 項目 | よくある見え方 | 判断の目安 | 次に見ること |
|---|---|---|---|
| CPU 5秒だけ高い | 5秒 80〜99%、1分/5分は低い | 即異常とは限らない。一時処理の可能性 | 30秒〜1分おきに再確認 |
| CPUが継続して高い | 1分/5分も高い | 要調査。継続負荷の可能性が高い | 上位プロセス、トラフィック、セッション |
| メモリ使用率が高い | 70〜90%以上 | 高いだけでは断定不可。減少傾向と実害で判断 | Freeの推移、ログ、プロセス別消費 |
| セッション急増 | 平常時比で大幅増 | 攻撃、スキャン、通信集中の疑い | 送信元/宛先、ポリシー、NAT、ログ |
| 実害あり | CLIが重い、通信遅延、切断 | 緊急度高い。数値より症状優先 | 制御系負荷、エラー、ログ、直前変更 |
重要なのは、CPU・メモリ単体ではなく、症状と推移で判断することです。CPU 90%でも安定しているケースはありますし、CPU 60%でも制御系処理が詰まり実害が出るケースもあります。
CiscoルータでCPU使用率を確認するコマンドと見方
まずは全体のCPU使用率を見る
Cisco IOS系で最初に打つことが多いのは次のコマンドです。
show processes cpu sortedこのコマンドでは、CPUの全体使用率と、CPUを使っているプロセスを確認できます。最初に見る場所は先頭行です。代表的な出力イメージは次のようなものです。
CPU utilization for five seconds: 82%/24%; one minute: 76%; five minutes: 68%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
83 18523920 4938201 3751 31.5% 29.8% 25.2% IP Input
91 5321980 1293001 4115 8.1% 7.4% 6.9% ARP Input
177 1241000 723901 1714 5.8% 4.9% 4.1% SNMP ENGINEここで見るべきポイントは次の4つです。
| 見る場所 | 意味 | 見るポイント | 現場での読み方 |
|---|---|---|---|
| five seconds | 直近の瞬間CPU | 一瞬だけ高いか | 高くても1回だけなら保留 |
| one minute | 1分平均 | 短時間の高負荷が続いているか | ここも高いなら要注意 |
| five minutes | 5分平均 | 継続的に重いか | 恒常負荷の判断材料になる |
| 82%/24% の後ろ | 割り込みCPU | interrupt比率が高いか | パケット処理・IF周りの負荷を疑う |
特に重要なのは、5秒だけ高いのか、1分や5分も高いのかです。5秒だけ高いなら、ルーティング更新や管理処理の一時増加かもしれません。1分・5分も高ければ、継続的な負荷と考えるべきです。
また、「82%/24%」のように2つ数値が出る場合、後ろの値は割り込み処理です。ここが高い場合、単純なプロセス高負荷ではなく、インターフェース関連のパケット処理やCPU転送が多い可能性があります。
どのプロセスがCPUを使っているかを見る
同じ show processes cpu sorted の下部一覧で、CPU使用率が高いプロセスを確認します。
ここで大事なのは、名前を知っているかどうかより、同じプロセスが継続して上位かどうかです。1回だけでは判断しづらいため、30秒おき、1分おきなど複数回見るのが基本です。
| プロセス名の例 | よくある意味 | 疑うべきこと | 次に打つ候補 |
|---|---|---|---|
| IP Input | CPUでのIPパケット処理 | CPU転送、ACL、NAT、特殊トラフィック | show ip traffic / show interfaces |
| ARP Input | ARP関連処理 | ARPストーム、L2接続先の異常 | show arp / show interfaces counters errors |
| SNMP ENGINE | SNMP応答処理 | 監視取得過多、ポーリング間隔過密 | 監視サーバ設定確認 |
| Check heaps | 内部管理処理 | 瞬間値なら正常範囲のことも多い | 継続性を確認 |
| BGP Router / OSPF / EIGRP | ルーティング制御 | 経路変動、隣接不安定、経路数増加 | show ip bgp summary / show ip ospf neighbor |
| Crypto / IPsec系 | 暗号処理 | VPNトラフィック急増、HW支援未使用 | show crypto session / show crypto engine brief |
ただし、プロセス名だけで原因を断定してはいけません。たとえばIP Inputが高くても、原因はACL、NAT、トンネル、制御パケット、DoS気味の通信など複数あります。必ずその次に、トラフィックや該当機能の統計へ進んでください。
CiscoでCPU高騰時に追加で見るべきコマンド
CPUが高いと分かった後、次に何を見るかが切り分けの差になります。代表的な追加確認コマンドは次の通りです。
show interfaces
show interfaces counters errors
show ip traffic
show logging
show platform hardware qfp active statistics drop| コマンド | 見る場所 | 分かること |
|---|---|---|
| show interfaces | input rate/output rate, drops, overruns, errors | トラフィック急増、IF異常、ドロップ |
| show interfaces counters errors | CRC, frame, input errors, output errors | L1/L2起因の異常を疑える |
| show ip traffic | input, forwarded, dropped, ICMP, fragments | 特定種類のパケット急増 |
| show logging | 再起動、フラップ、エラー | 異常イベントの裏取り |
| show platform hardware qfp active statistics drop | ドロップ理由別カウンタ | CPU以外の詰まりや転送面の問題 |
特にshow interfacesは、単純ですが非常に重要です。インターフェースの入力レートが急に上がっていれば、CPU高騰の背景に通信増加があるかもしれません。CRCやinput errorsが増えていれば、物理・L2側の問題がCPU使用率悪化の間接原因になっていることもあります。
QFP系プラットフォームで見るべきポイント
ISR4KやASR1KなどIOS-XEの一部機種では、従来のCPU表示だけでは実態を読み切れないことがあります。そこで役立つのがQFP関連です。
show platform hardware qfp active datapath utilization
show platform hardware qfp active statistics drop見るべきポイントは、データプレーン側が詰まっていないか、ドロップ理由が特定方向に増えていないかです。一般的なCPU表示がそこまで高くなくても、QFP側で詰まりが出ていることがあります。
現場でよくある誤解は、CPUが高い＝帯域不足と考えることです。帯域は余っていても、CPU転送や制御プレーン負荷で重くなることはあります。逆に、帯域が高くてもハードウェア転送されていればCPUはそこまで上がらない場合もあります。
Ciscoルータでメモリ使用率を確認するコマンドと見方
全体のメモリ状況を見る基本コマンド
Ciscoでメモリ確認の基本は次です。
show memory statistics機種やOSによっては次もよく使います。
show processes memory sortedどこを見るべきかというと、まずは全体のFree memoryが十分あるかです。ただし、空きが少ないだけで即障害とは限りません。問題なのは、空きがずっと減り続ける、極端に少ない状態が続く、ログに確保失敗やプロセス再起動が出る場合です。
メモリはCPUより判断が難しいです。CPUは高い低いが直感的ですが、メモリは「使っている＝悪い」ではありません。OSは空きメモリを効率利用することがあるため、使用率だけで異常と断定できません。
| 確認項目 | 見るポイント | 危険度の考え方 |
|---|---|---|
| Free memory | 極端に少ないか | 少ないだけでは断定不可。推移重視 |
| 最小空きメモリ | 一時的に底を打っていないか | 急落していれば要注意 |
| 数時間〜数日の推移 | 右肩下がりか | リークやセッション蓄積を疑う |
| ログ | malloc failure、restart、traceback | 実害が出ていれば優先度高い |
プロセス別メモリを見るときの注意
show processes memory sortedこの出力では、どのプロセスが多くメモリを使っているかを確認できます。見る場所は、上位にいるプロセスが異常に大きいか、前回確認時より増えているかです。
ここでの勘違いは、上位にいるだけで悪者扱いすることです。ルーティング、VPN、ログ、管理用プロセスなど、役割上メモリを多く使うものはあります。大事なのは、その機器の平常時と比べて増えているかです。
もし普段の値が分からないなら、その場で断定せず、監視値や過去ログを確認してください。単発のCLI結果だけで「メモリリークだ」と言い切るのは危険です。
Ciscoでメモリ異常を疑うときの具体例
| 状況 | CLI上の見え方 | 考えられること | 対応の方向性 |
|---|---|---|---|
| 緩やかに空きが減り続ける | 数時間〜数日でFreeが右肩下がり | リーク、セッション蓄積、ログ蓄積 | 監視比較、バグ情報確認、再起動計画 |
| 急激に空きが減る | 直前に大きく悪化 | 経路大量受信、トラフィック急増、機能有効化 | 直前変更確認、経路/ログ確認 |
| 空きは少ないが安定 | 高使用率だが変動小さい | 正常利用範囲の可能性 | 実害有無を確認し、経過監視 |
| 応答不安定を伴う | CLI遅い、保存失敗、プロセス再起動 | 実害レベルの逼迫 | 早期保守、退避、再起動判断 |
FortiGateでCPUとメモリを確認するコマンドと見方
最初に使いやすい基本コマンド
FortiGateでは、まず次のコマンドが使いやすいです。
get system performance statusこのコマンドでは、CPU states、Memory、Session数など、全体の健康状態をまとめて確認できます。出力イメージは次のような形です。
CPU states: 12% user 3% system 0% nice 84% idle
Memory: 68%
Average network usage: 1200 kbps in 950 kbps out
Average sessions: 18500
NPU sessions: 14600どこを見るべきかは、主に次の項目です。
| 項目 | 見るポイント | 意味 | 注意点 |
|---|---|---|---|
| CPU states | idleが十分あるか | idleが少ないほど忙しい | 一時的な低下か継続かを見る |
| Memory | 高止まりしていないか | 高いだけでなく継続性が重要 | 使用率単体で断定しない |
| Average sessions | 普段より急増していないか | 通信増加が負荷の背景かを見る | 平常時との差分が重要 |
| NPU sessions | オフロード状況の参考 | CPU処理偏りのヒント | 機種・機能により見え方が変わる |
FortiGateでは、CPU使用率そのものより、idleがどれくらい残っているかを見ると判断しやすいです。idleがかなり少ない状態が続くなら、CPU余力が小さいと考えられます。
プロセスごとの負荷を確認する
diagnose sys topLinuxのtopに近いイメージで、CPUやメモリを使っているプロセスを見られます。必要に応じて更新間隔を指定することもあります。
diagnose sys top 1 20これは1秒間隔で20回表示する例です。どこを見るべきかは、上位プロセスのCPU%、MEM%、そして同じプロセスが継続して高いかです。
| 見え方 | 疑う方向 | 補足 |
|---|---|---|
| ipsengine が高い | IPSや検査負荷が高い | UTM機能の影響を疑う |
| wad が高い | Web/Proxy/SSL関連負荷 | SSL深度検査の影響もありうる |
| miglogd が高い | ログ出力負荷 | 外部ログ転送や大量ログを確認 |
| httpsd / gui系が高い | 管理GUIアクセス負荷 | 管理操作集中や不具合も疑う |
FortiGateは有効化している機能で負荷が大きく変わります。UTM機能、SSL復号、アプリ制御、Webフィルタ、IPS、アンチウイルスを多く使っていれば、その分CPUやメモリは増えます。したがって、数値だけでなく、その機器で何を有効にしているかと合わせて読む必要があります。
メモリの詳細確認で使うコマンド
diagnose hardware sysinfo memoryこのコマンドではメモリの詳細を確認できます。見るべきポイントは、空きメモリ、バッファやキャッシュの状況、そして明らかな不足傾向があるかです。
FortiGateもCiscoと同じで、メモリ使用率が高いだけで即異常とは限りません。問題なのは、セッション数が増え続けるのにメモリ余裕が減り続ける、管理画面やCLIの反応が鈍い、プロセス再起動やログ異常が出るといった実害があるケースです。
FortiGateで追加確認したいコマンド
get system session status
diagnose npu np6 session-stats
get system performance firewall statistics| コマンド | 見る場所 | 分かること |
|---|---|---|
| get system session status | 現在セッション数、上限、TCP/UDP内訳 | セッション枯渇や急増の有無 |
| diagnose npu np6 session-stats | NPUオフロード状況 | CPU処理偏重かどうかの参考 |
| get system performance firewall statistics | トラフィック・処理統計 | 負荷背景の把握 |
対応機種では、NPUへ十分オフロードされているかが大きな判断ポイントになります。CPUが高いのにNPUオフロードが少ない場合、ポリシーや機能によりCPU処理へ寄っている可能性があります。機種差が大きいため、使えるコマンド名は実機で確認してください。
CPU高騰時の原因を絞る実践フロー｜Cisco/FortiGate共通
CPUが高いと分かった後に重要なのは、原因候補を漫然と並べることではなく、順番に消していくことです。以下のフローで見ると外しにくいです。
- 瞬間値か継続値かを確認する
- 実害があるかを確認する。通信断、遅延、GUI/CLI遅延など
- 上位プロセスを確認する
- トラフィック量、セッション数、インターフェースエラーを見る
- 直前変更を確認する。ポリシー追加、監視強化、VPN増設など
- ログで再起動、フラップ、ドロップ、メモリエラーを確認する
- 平常時と比較する。監視グラフがあれば必ず見る
特に見落としやすいのが、直前変更です。高負荷の直前にACL追加、SNMPポーリング増加、デバッグ有効化、UTMプロファイル変更、SSL検査有効化などがあれば、原因候補はかなり絞れます。
現場でよくある原因別の見分け方
1. トラフィック急増・セッション急増
特徴は、CPU上昇と同時にインターフェースレートやセッション数も増えることです。
| 症状 | Ciscoで見る場所 | FortiGateで見る場所 | 疑うこと |
|---|---|---|---|
| 通信量が急に増えた | show interfaces の rate | get system performance status | 利用増加、バックアップ、異常通信 |
| セッションが急増した | 機種依存のセッション確認 | get system session status | スキャン、攻撃、アプリ暴走 |
| 特定方向で多い | NetFlow/ACL hit数など | ポリシー統計、ログ | 特定サーバ向け集中 |
2. 管理系トラフィックが重い
SNMP、Syslog、GUIアクセス、設定バックアップ、デバッグなど、業務通信以外が原因のことがあります。
たとえばCiscoでSNMP ENGINEが上位なら、監視ポーリング間隔が短すぎないか、監視対象OIDが多すぎないかを確認します。FortiGateでmiglogdが高いなら、ログ転送先停止や大量ログ発生を疑います。
3. 制御プレーンやルーティング処理が重い
BGPやOSPFが不安定だと、CPU高騰の原因になります。隣接断続、経路大量変動、再計算の多発などが典型です。
show ip bgp summary
show ip ospf neighbor
show ip route summary
show logging見るべきポイントは、neighbor flap、経路数急増、再計算や隣接再確立ログです。通信量は多くなくても、制御プレーンが不安定ならCPUは上がります。
4. ACL、NAT、トンネル、暗号化処理が重い
CPU転送されやすい処理や、暗号支援が効いていない処理は、帯域自体は大きくなくてもCPUを食います。
| 機能 | 高負荷時のヒント | 追加確認 |
|---|---|---|
| ACL | IP Input高騰、特定通信集中 | ACL hit数、対象通信量 |
| NAT | セッション増加と同時にCPU上昇 | 変換数、セッション統計 |
| GRE/IPsec | Crypto系プロセス高騰 | トンネルセッション、暗号エンジン |
| SSL深度検査 | FortiGateでwad/ipsengineが高い | 対象ポリシー、証明書、対象通信量 |
正常か異常かを判断するときの実務的な目安
数値だけでなく、次の4条件で判断すると現場で使いやすいです。
| 観点 | 見る内容 | 異常寄りのサイン |
|---|---|---|
| 継続性 | 1分・5分・監視グラフ | 高負荷が継続する |
| 偏り | 特定プロセスや機能 | 同じものが上位固定 |
| 影響 | 通信遅延、切断、管理遅延 | 利用者影響が出ている |
| 変化点 | 直前変更、通信増加、監視変更 | 発生時刻と一致する変化がある |
つまり、継続して高い、特定処理に偏る、実害がある、何かの変化点と一致する、この4つがそろうほど「対応すべき異常」に近づきます。
現場でよくある勘違いと見落とし
CPU使用率だけ見て結論を出す
CPUが高いのは結果であって原因ではありません。高いという事実の次に、どのプロセスか、通信増加か、設定変更直後か、監視取得過多かを見ないと切り分けになりません。
メモリ使用率が高いだけで異常と決める
前述のとおり、メモリは使っていても正常なことがあります。危ないのは、空きが減り続ける、特定プロセスが増え続ける、保存や応答が不安定になるケースです。
瞬間値だけで判断する
1回のCLI出力だけでは、たまたま高かっただけかもしれません。最低でも複数回確認し、できれば監視グラフも見てください。継続性が分からないと誤判定しやすいです。
管理系トラフィックの影響を見落とす
SNMP、Syslog、GUIアクセス、バックアップ、デバッグなど、管理のための処理が負荷要因になることがあります。業務通信だけを疑うと外します。
平常時の値を持っていない
本当はこれが最大の問題です。平常時のCPU、メモリ、セッション数、インターフェースレートが分からないと、異常かどうかの判断精度が落ちます。監視がない環境でも、繁忙時間帯と通常時間帯のCLI出力を採取しておくと後で効きます。
障害対応で使いやすい確認フロー｜迷ったらこの順番
実際の一次切り分けで使いやすい流れを、機器共通で整理すると次の通りです。
- 利用者症状を確認する。遅いのか、切れるのか、管理画面が重いのかを切り分ける
- CPU全体使用率を見る。瞬間値と平均値の両方を見る
- メモリ全体使用率と空き状況を見る
- プロセス別CPU・メモリを確認する
- セッション数、トラフィック量、インターフェースエラーを見る
- 設定変更直後か、監視やログ取得が増えていないか確認する
- 過去監視と比較して、いつから上がったかを確認する
- 必要に応じてベンダードキュメントや既知不具合を確認する
この流れにすると、「CPUが高い」から始まっても、単なる数値確認で終わらず、原因の方向性まで見えてきます。
すぐ使える確認コマンド一覧
| 機器 | 目的 | コマンド | 見るべきポイント | 次のアクション |
|---|---|---|---|---|
| Cisco | CPU全体・プロセス | show processes cpu sorted | 5秒/1分/5分、上位プロセス、interrupt | show ip traffic / show interfaces |
| Cisco | メモリ全体 | show memory statistics | Free memory、減少傾向 | 過去値比較、ログ確認 |
| Cisco | プロセス別メモリ | show processes memory sorted | 特定プロセスの増加 | 平常時比較 |
| Cisco | 通信量・エラー | show interfaces | rate、drops、errors | IF異常、通信増加の確認 |
| Cisco | IP統計 | show ip traffic | input、drop、ICMP、fragment | 異常パケット傾向の把握 |
| Cisco | QFPドロップ | show platform hardware qfp active statistics drop | ドロップ理由別増加 | 転送面の詰まり確認 |
| FortiGate | 全体状況 | get system performance status | CPU states、Memory、Sessions、NPU sessions | 継続性と平常時比較 |
| FortiGate | プロセス負荷 | diagnose sys top | CPU%、MEM%、継続性 | 高い機能の洗い出し |
| FortiGate | メモリ詳細 | diagnose hardware sysinfo memory | 空き状況、不足傾向 | 推移確認、ログ確認 |
| FortiGate | セッション状況 | get system session status | 現在数、上限に対する余裕 | 増加要因の特定 |
| FortiGate | NPU状況 | diagnose npu np6 session-stats | オフロード状況 | CPU偏重か確認 |
監視がある場合に見るべきグラフ
CLIだけでも切り分けはできますが、監視があるなら必ず次のグラフも見てください。CLI単発確認の弱点は「いつから」「どれくらい続いているか」が見えにくいことです。
| 監視項目 | 見る理由 | 読み方 |
|---|---|---|
| CPU使用率 | 継続負荷か瞬間負荷か分かる | 発生時刻と症状時刻が一致するか |
| メモリ使用率 | 減少傾向が分かる | 右肩下がりなら要注意 |
| 帯域使用率 | 負荷背景を把握できる | CPU上昇と同時に増えているか |
| セッション数 | 通信集中や異常通信の判断材料 | 平常時比の急増を見る |
| エラーカウンタ | L1/L2問題の切り分け | CRCやdropの増加有無 |
監視グラフとCLIが一致して初めて、自信を持って「継続高負荷」「一時負荷」「セッション増加起因」などと言えます。
まとめ｜コマンドを知るだけでは足りない
CPUやメモリ確認は、コマンドを知っているだけでは足りません。どこを見るか、瞬間値と平均値をどう分けるか、次にどのコマンドで深掘りするか、症状とどう結びつけるかまで分かって初めて、実務で使える知識になります。
特に重要なのは次の3点です。
- CPUは5秒だけで判断しない。1分・5分も見る
- メモリは使用率だけでなく、空きの推移と実害を見る
- 高い数値の次に、プロセス・セッション・トラフィック・ログへ進む
もし機器が重いと感じたら、この記事の順序で見ていけば、少なくとも「何を見ればよいか分からない」という状態は避けられます。現場で本当に役立つのは、コマンド暗記ではなく、確認順序と読み方です。
